Question 1

Design a shopping cart system for an e-commerce platform similar to Shopee handling 5 million concurrent users during a flash sale. How would you handle overselling and race conditions?

Accepted Answer

Clarify requirements & scale -> Design overall architecture (cache, queue, DB) -> Handle race conditions (Redis SETNX / Lua script / Optimistic locking) -> Load reduction strategies (rate limiting, circuit breaker) -> Observability & rollback The interviewer wants to see layered thinking - not just solving the technical problem but understanding trade-offs. A strong answer covers: (1) Redis atomic operations (SETNX or Lua script) to keep inventory non-negative, (2) Message queue (Kafka/RabbitMQ) to decouple inventory deduction from the main request path, (3) Optimistic locking at the DB layer to avoid dirty reads, (4) Graceful degradation when Redis fails. Bonus points for sharing real metrics from past projects or asking clarifying questions about SLA and RTO/RPO.

Question 2

Describe the code review process you used in your previous team. When you find code that works correctly but has maintainability issues, how do you write your comment to avoid conflict with the author?

Accepted Answer

Describe the concrete process (checklist, tooling, review SLA) -> Real example of a maintainability issue -> How to ask questions instead of judging -> Outcome and lesson learned The interviewer is assessing your technical communication skills and EQ. A strong answer clarifies: (1) What tools the team used (GitHub PR, GitLab MR) and whether there was a review SLA, (2) How you categorize comments by severity (nitpick, suggestion, blocker), (3) How to use constructive language - asking 'What do you think about...' instead of 'This is wrong', (4) Prioritizing logic review over style (let linters handle style). Concrete examples of a PR that improved the codebase are a big plus.

Question 3

Tell me about a time you handled a critical production incident (service down or data corruption). How did you identify the root cause and restore the system? What was your post-mortem process?

Accepted Answer

Describe the situation and impact -> Triage steps (logs, metrics, tracing) -> Short-term fix (hotfix/rollback) -> Root cause -> Post-mortem and long-term improvements This is a STAR-format question requiring technical depth. Key strengths to show: (1) Staying calm under pressure and prioritizing service restoration before investigation, (2) Knowing how to use observability tools (logs, APM, distributed tracing), (3) A blameless post-mortem process - focusing on process, not individual blame, (4) Specific action items that were actually implemented afterward. Mention on-call experience and runbooks/playbooks if applicable. Avoid telling a story without metrics (how many minutes of downtime, how many users impacted).

Question 4

Your team has a monolith service running stably but feature development velocity is slowing due to accumulated tech debt. The PM keeps prioritizing new features. How would you convince stakeholders and plan to pay down tech debt?

Accepted Answer

Measure and quantify tech debt (cycle time, bug rate, DORA metrics) -> Translate technical language into business impact -> Propose strategy (Boy Scout Rule, 20% capacity, strangler fig) -> Prioritize tech debt backlog -> Track and report progress The interviewer wants to see you can bridge technical and business concerns. Key points: (1) Don't say 'we need to refactor' - say 'this tech debt increases feature delivery time by 40%, costing X extra days per sprint', (2) Propose specific models like '20% sprint capacity for tech debt' or a dedicated sprint each quarter, (3) Know how to prioritize: tech debt that blocks the critical path of the feature roadmap comes first, (4) Use DORA metrics (deployment frequency, lead time) to prove improvements. This is also a question about professional maturity.

Question 5

Tell me about a project where you worked closely with a Product Manager and Designer. Was there ever a time you disagreed with a technical requirement from the PM? How did you resolve it?

Accepted Answer

Describe the project and your role -> Present the specific disagreement (requirement vs. feasibility) -> How you communicated (data, prototype, trade-off) -> Outcome -> Lesson learned about collaboration This question tests cross-functional teamwork skills and professional maturity. A good answer shows: (1) You don't just say 'no' to the PM but offer alternatives with clear trade-offs, (2) Using prototypes or spikes to demonstrate rather than just theorizing, (3) Respecting the PM's final decision once they have enough information, (4) How you document decisions so the team can review later. Avoid stories where the engineer is always right and the PM always wrong - this shows lack of empathy.

Question 6

You are building an API for a mobile app with many screens having different data needs (overfetching/underfetching). Would you choose REST or GraphQL? Analyze the specific trade-offs and propose an endpoint design for a product listing screen.

Accepted Answer

Analyze requirements (team size, client diversity, performance SLA) -> Compare REST vs. GraphQL (caching, complexity, tooling) -> Decision and rationale -> Concrete endpoint design (fields, pagination, filtering) -> Versioning strategy The interviewer isn't looking for one absolute right answer but for structured reasoning ability. Key strengths: (1) No technology bias - REST is still a good choice for most small/medium teams, (2) Knowing to mention the BFF (Backend for Frontend) pattern as a middle ground, (3) GraphQL has real trade-offs: more complex caching, N+1 problem, team learning curve, (4) REST with sparse fieldsets or JSON:API also solves overfetching. If you choose REST, design a concrete endpoint with clear query params.

Question 7

You receive an alert that a SQL query is taking 8 seconds on an orders table with 50 million rows, causing timeouts for the entire order history feature. Describe step by step how you would investigate and optimize this query.

Accepted Answer

Run EXPLAIN/EXPLAIN ANALYZE to view query plan -> Check existing indexes and missing indexes -> Analyze N+1, full table scan, lock contention -> Apply fixes (composite index, covering index, query rewrite, pagination) -> Measure results and monitor A practical question most engineers face when scaling. Key points: (1) Start with EXPLAIN ANALYZE - don't guess before reading the query plan, (2) Know the difference between Seq Scan and Index Scan and when the DB optimizer chooses wrong, (3) Composite indexes need correct column order (equality first, range last), (4) Covering indexes eliminate heap fetches, (5) For large datasets, propose table partitioning or archiving old data. Bonus points for mentioning testing the query plan on staging before deploying new indexes to production (CREATE INDEX CONCURRENTLY).

Question 8

In the next 2-3 years, do you want to grow as a deep technical specialist (individual contributor - Staff/Principal Engineer) or move into management (Engineering Manager)? What skills do you think the Vietnamese tech market currently needs most in engineers?

Accepted Answer

Self-assess current strengths and preferences -> Specific reasons for the chosen direction -> Concrete development plan (what to learn, what to do) -> View on VN market (AI, fintech, e-commerce) -> Connect to the role being applied for This is a question about self-awareness and culture fit. There's no wrong answer, but a strong response needs: (1) An honest answer - don't say 'it depends on the company' as it shows no direction, (2) Demonstrating you've seriously thought about your career path, (3) On the VN market: bonus points for mentioning demand for AI/ML integration, cloud-native skills, system design for emerging markets, technical English, (4) Connecting your answer to why you're applying to this company - shows you've researched them. In the VN market, the IC path (Staff/Principal) is still less recognized than in the US, making this a chance to show forward-looking thinking.