Loading
Technology · 14 questions
This page covers the conversation rounds of a software engineering interview — the hiring-manager screen, the behavioural round, and the "walk me through a system you built" discussion — not the live-coding test. In those rounds the panel is usually an engineering manager and one or two senior engineers, and they are scoring three things: whether you can explain a technical decision and its trade-offs, whether you own outcomes rather than tickets, and whether they would want you on their on-call rotation.
Every answer should contain one concrete system, one number (requests per second, latency, a bug count, a deadline) and one trade-off you consciously made. Panels have heard "I'm passionate about clean code" a thousand times; they remember "we chose Postgres over Dynamo because our access pattern was join-heavy and we were three engineers."
If English isn’t your first language
Non-native engineers rarely lack technical vocabulary — "idempotent," "race condition" and "consistency" come out fine. What runs thin is the connective English between them: the "because," "so that," "which meant" that turns a list of facts into a reasoned decision. Two other patterns cost points: saying "we" for everything, which hides what you personally did, and hedging design choices ("maybe we could have used Kafka") when the panel wants to hear the choice you made and why. Practise saying "I chose X because Y, and the cost was Z" out loud until it is automatic.
See the full guides for Arabic speakers and Hindi speakers.
1 · Role-specific
What a strong answer includes
Start with the problem and the constraints (traffic, team size, deadline, budget), then the shape of the solution in two or three sentences, then the one or two decisions that mattered and what you gave up — consistency for availability, simplicity for scale, build time for runtime. Name the technologies but do not list them; explain why each was chosen over the obvious alternative. End with what you would change now.
Common mistake
Describing the architecture as a tour of boxes and arrows with no "because." The panel is scoring judgment, not inventory.
2 · Behavioural
What a strong answer includes
Give the symptom, how you narrowed it (logs, bisecting, reproducing locally), the root cause in one sentence, the fix, and — crucially — what you did to stop it recurring: a test, an alert, a lint rule. Include the time pressure honestly (three hours before release, a customer waiting) and how you decided between a quick patch and a proper fix.
Common mistake
Telling it as a heroic all-nighter. Panels hear "no process"; they want to hear the diagnosis method and the regression test.
3 · Behavioural
What a strong answer includes
Say what the disagreement was technically (naming, error handling, an abstraction), how you argued your side with evidence rather than preference, and how it ended — you changed your mind, they did, or you agreed on a smaller change and revisited later. Show that you separated the code from the person and kept the PR moving.
Common mistake
A story where you were simply right and the other engineer gave in. It reads as inflexibility, even if it is true.
4 · Situational
What a strong answer includes
Show that you quantify debt in terms product understands — "this module causes one incident a month and every change takes twice as long" — and that you attach paydown to feature work rather than asking for a separate month. Give an example where you negotiated a specific refactor into a sprint and what it unlocked. Mention that some debt is fine to carry.
Common mistake
Framing product managers as the enemy of quality. The panel includes people who work with those PMs every day.
5 · Behavioural
What a strong answer includes
Timeline in minutes: the page, what you checked first, how you mitigated (rollback, feature flag, scaling) before you understood the root cause, who you communicated with and when, and what the post-mortem changed. Blameless language throughout. If you were not the incident lead, say what your role was precisely.
Common mistake
Spending the whole answer on the root cause and skipping mitigation and communication. Incident handling is mostly the latter two.
6 · Role-specific
What a strong answer includes
Describe breaking work into pieces small enough that each is a day or two, identifying the unknown that dominates the risk and spiking it first, and giving ranges rather than points. Give an example where your estimate was badly wrong, what you learned, and how you communicate slippage early rather than at the deadline.
Common mistake
Saying you are "usually pretty accurate." Nobody is; the panel wants to see how you handle being wrong.
7 · Behavioural
What a strong answer includes
Name the stack, why you had to learn it, and your method: reading the existing codebase before the docs, building one small end-to-end thing, pairing with someone who knew it, and shipping something real within a defined time. Include what confused you and how long it actually took to be productive.
Common mistake
Claiming you were fully productive in a week. Say "useful in two weeks, comfortable in two months" — it is more credible.
8 · Situational
What a strong answer includes
Lead with the consequence for them (cost, time, risk to customers), then the choice in one plain-English analogy, then what you need from them. Give one real example — explaining why a migration needs a freeze week, or why "just add a field" takes a sprint — and how the stakeholder reacted.
Common mistake
Simplifying by leaving out the trade-off. Stakeholders can handle "this is faster but costs more"; they cannot handle surprises later.
9 · Behavioural
What a strong answer includes
Show the collaboration mechanics: how requirements were clarified, how you pushed back on scope with data, how you surfaced technical constraints early. Be honest about one thing that went badly — a late requirement, a misunderstanding — and what you both changed after.
Common mistake
An answer that is all "went well." The question explicitly asks for both, and panels score candour.
10 · Role-specific
What a strong answer includes
Concrete mechanisms: review standards, CI gates (tests, lint, type checks), small PRs, a definition of done, and pairing on the tricky parts. Give an example of a quality problem the team had and the one mechanism that fixed it. Mention that quality tooling has to be cheap enough that people do not route around it.
Common mistake
Answering only about your own habits. The question is about influencing other people's code.
11 · Behavioural
What a strong answer includes
Own it plainly: what broke, the blast radius (users, revenue, minutes), how it was caught, how fast you rolled back, and the specific gap in testing or deployment that let it through. Then the fix to the process — canary deploys, a missing integration test, a feature flag. Panels are checking that you have a healthy relationship with failure.
Common mistake
Choosing a trivial example to look safe. A real incident with a real lesson is far more impressive than a typo.
12 · Situational
What a strong answer includes
A short framework: is it core to the product, how well is the alternative maintained, what does the operational burden look like at 3 a.m., and what does lock-in cost later. Then one real decision you made each way and whether it was right in hindsight.
Common mistake
A blanket rule ("never reinvent the wheel" or "I prefer to own everything"). The panel wants to see judgment applied to context.
13 · Behavioural
What a strong answer includes
What they were stuck on, how you diagnosed whether it was a knowledge gap or a confidence gap, what you did (pairing, a worked example, asking questions rather than giving answers), and what they could do afterwards that they could not before. Keep it about their progress, not your generosity.
Common mistake
Describing how you fixed their problem for them. That is unblocking a ticket, not developing a person.
14 · Motivation
What a strong answer includes
Two specific reasons that show research — the product, the scale, a technical problem they have written about, the team's stack — and a three-year direction that fits what they actually offer (staff engineer, tech lead, a domain you want depth in). Then one sentence on what you bring on day one.
Common mistake
A generic "I want to grow and learn." Every candidate says it; it tells the panel nothing about fit.
When we add questions to this bank, or a model answer set, you’ll hear first.