1) Technical Screen

Started with a proctored CodeSignal round.

2) Full Loop

AI-Assisted Round

This round included a simple codebase with:

• 2 unit tests
• multiple data files inside the src directory

The problem was around recommending random friends/connections.

Approach used:

• first used Claude Opus to generate a rough technical blueprint
• then used that plan to solve the first unit test
• followed a similar approach for the second unit test

A follow-up question was around how to score recommendations.
One possible approach discussed was:

• number of mutual connections
• sorting candidates by score
• returning the top recommendations

The interviewer also asked a few additional questions. The discussion felt a bit mixed and it was hard to tell whether the direction was fully aligned with expectations.

DSA Round

This round had 2 LeetCode-tagged problems.

• For the first problem, an optimal solution was written. The interviewer then asked for a code review, which led to spotting and fixing a logical bug.
• For the second problem, an optimal solution was also written. After that, the interviewer asked for a dry run and then slightly modified the input to ask for the output.

Overall, this felt like a standard but detail-focused DSA round.

Behavioral Round

Mostly experience-based questions.
Answers were based on prior work and projects. Hard to judge afterward whether the depth/detail was enough.

3) Product Architecture / System Design

The system design question was around designing a multi-client messaging platform.

The discussion started with:

• functional requirements
• non-functional requirements

Then moved into a high-level microservices-based design:

Client → Edge (DNS, WAF) → EKS → Services / Infra → Database

More specifically:

• Client
• Edge layer: DNS, WAF
• EKS cluster
  • Chat service
  • Kafka
• Database: DynamoDB

Basic flow:

• Router → Chat Service → DB
• Kafka used for async events such as:
  • heartbeat / active status
  • seen-message updates

Interviewer Follow-up Questions

Some of the follow-ups included:

1. REST/HTTP vs WebSockets Why choose one over the other for chat?
2. How to update whether a message was seen or not One explanation discussed was:
   • seen events pushed through Kafka
   • a consumer updates DynamoDB
   • background sync jobs periodically reconcile message metadata if needed
3. Database design Proposed something along the lines of:
   • PK: sender#receiver
   • SK: timestamp
   • attributes like seen, etc.

Note: took AI help for fixing grammar

1) Technical Screen

Started with a proctored CodeSignal round.

2) Full Loop

AI-Assisted Round

This round included a simple codebase with:

• 2 unit tests
• multiple data files inside the src directory

The problem was around recommending random friends/connections.

Approach used:

• first used Claude Opus to generate a rough technical blueprint
• then used that plan to solve the first unit test
• followed a similar approach for the second unit test

A follow-up question was around how to score recommendations.
One possible approach discussed was:

• number of mutual connections
• sorting candidates by score
• returning the top recommendations

The interviewer also asked a few additional questions. The discussion felt a bit mixed and it was hard to tell whether the direction was fully aligned with expectations.

DSA Round

This round had 2 LeetCode-tagged problems.

• For the first problem, an optimal solution was written. The interviewer then asked for a code review, which led to spotting and fixing a logical bug.
• For the second problem, an optimal solution was also written. After that, the interviewer asked for a dry run and then slightly modified the input to ask for the output.

Overall, this felt like a standard but detail-focused DSA round.

Behavioral Round

Mostly experience-based questions.
Answers were based on prior work and projects. Hard to judge afterward whether the depth/detail was enough.

3) Product Architecture / System Design

The system design question was around designing a multi-client messaging platform.

The discussion started with:

• functional requirements
• non-functional requirements

Then moved into a high-level microservices-based design:

Client → Edge (DNS, WAF) → EKS → Services / Infra → Database

More specifically:

• Client
• Edge layer: DNS, WAF
• EKS cluster
  • Chat service
  • Kafka
• Database: DynamoDB

Basic flow:

• Router → Chat Service → DB
• Kafka used for async events such as:
  • heartbeat / active status
  • seen-message updates

Interviewer Follow-up Questions

Some of the follow-ups included:

1. REST/HTTP vs WebSockets Why choose one over the other for chat?
2. How to update whether a message was seen or not One explanation discussed was:
   • seen events pushed through Kafka
   • a consumer updates DynamoDB
   • background sync jobs periodically reconcile message metadata if needed
3. Database design Proposed something along the lines of:
   • PK: sender#receiver
   • SK: timestamp
   • attributes like seen, etc.

Note: took AI help for fixing grammar