Software Engineer / Developer Interview Questions

What they’re assessing: The screener is mapping you to the open requisition in the first 90 seconds — role fit, stack fit, and years of relevant experience.

How to answer: Give a 60-90 second answer structured as present-past-future: current role and stack, one quantified achievement, and why this role is the logical next step. Name your primary stack explicitly (for example, Java + Spring Boot + AWS or React + Node) because screeners often keyword-match against the JD. End with a hook the interviewer can dig into, like a project you scaled or migrated.

What they’re assessing: They are screening for flight risk and for candidates who badmouth employers.

How to answer: Frame it as running toward something, not away: growth ceiling, wanting deeper ownership, or a specific tech exposure the new role offers. Never mention appraisal disputes or manager conflicts even if true. One safe, honest pattern: 'I have shipped X and Y here; the next level of scale/complexity I want is exactly what this role does.'

What they’re assessing: HR is checking budget fit before investing panel time; your answer anchors the final offer.

How to answer: State your current fixed-plus-variable split honestly (offer letters get verified during BGV in India). For expectations, quote a range anchored to market data for your experience band rather than a percentage hike — for example, 'Based on my skills and current market benchmarks, I am looking at 18-22 LPA' — and add that the role and learning matter alongside compensation.

What they’re assessing: In India, 60-90 day notice periods kill offers; HR needs to know your real joining timeline.

How to answer: State your official notice period and your realistic earliest joining date. If your company allows buyout or leave adjustment, say so proactively — it makes you a lower-friction hire. If you are serving notice already, lead with your last working day; candidates on notice get prioritised.

What they’re assessing: They are gauging urgency and the risk of you shopping their offer.

How to answer: Be truthful but strategic: 'I am in advanced stages at two other companies, but this role is my top preference because of X.' Having parallel processes signals demand, not disloyalty. Never fabricate an offer — Indian HR teams increasingly ask for offer letters before matching.

What they’re assessing: They want evidence you have thought about IC-versus-management direction and will stay long enough to justify hiring cost.

How to answer: Tie your ambition to a track the company actually offers: 'growing into a senior/staff engineer who owns a service end to end' or 'leading a small team after establishing technical credibility.' Avoid vague answers like 'in a good position' and avoid saying you plan to do an MBA or move abroad.

What they’re assessing: Debugging stories reveal your actual depth better than any resume line — panels probe them hard.

How to answer: Pick a bug with a genuinely non-obvious root cause: a race condition, a timezone/DST issue, a memory leak, or an off-by-one in pagination. Narrate your hypothesis-driven process — what you suspected, how you isolated it (logs, bisecting commits, reproducing locally) — and end with the prevention you added, like a regression test or an alert. The prevention step is what separates senior answers.

What they’re assessing: They are testing whether you can push back with data instead of either capitulating or escalating emotionally.

How to answer: Use STAR with a real technical disagreement — say, SQL versus NoSQL for a feature, or sync versus event-driven. Show that you argued with benchmarks or a small proof of concept, not opinions, and state clearly who turned out to be right. Being wrong gracefully ('their approach handled a failure mode I had not considered') often lands better than always winning.

What they’re assessing: Interviewers know sprints slip; they want to see early communication and scope negotiation, not heroics.

How to answer: Choose an example where you flagged the risk early, proposed a de-scoped v1, and communicated the revised plan to stakeholders before the date. Quantify: 'We shipped the core flow on time and moved two edge cases to the next sprint.' Never blame QA, requirements, or teammates — own the estimation miss.

What they’re assessing: This tests ego management — a daily requirement in any engineering team.

How to answer: Give a specific comment you received (naming pattern, missing error handling, an untested path), what you initially felt, and what you changed in your process afterwards — for example, self-reviewing the diff before requesting review. Mentioning that you later thanked the reviewer or adopted their standard shows maturity without sounding rehearsed.

What they’re assessing: Stack churn is constant; they want proof you can go from zero to shipping, not zero to tutorial.

How to answer: Structure it as: business trigger, your learning plan (official docs plus one small spike, not three online courses), and the shipped outcome with a timeline — 'picked up Kafka basics in a week and had the consumer in staging by week two.' Admit what you deliberately skipped learning; scoping what NOT to learn is the senior signal.

What they’re assessing: They are assessing composure, on-call ownership, and whether you think about blast radius and rollback.

How to answer: Narrate the timeline: detection (alert or user report), triage, mitigation (rollback or feature flag first, root cause later), and the post-mortem action items you personally drove. Emphasise that you communicated status to stakeholders during the incident. If you have never handled one, say so honestly and describe how you would run the same sequence.

What they’re assessing: Indian product companies and GCCs still gate on DSA; the interviewer is watching your process — clarify, brute force, optimise — more than the final code.

How to answer: Always restate the problem and confirm constraints and edge cases (empty input, all duplicates, Unicode) before coding. Say the brute-force complexity out loud, then improve it — here, a sliding window with a hashmap gets O(n). Dry-run your code on one example on the spot; candidates who test their own code before being asked stand out.

What they’re assessing: This classic tests whether you can decompose a system: API, data model, ID generation, and scale estimates.

How to answer: Start with requirements and scale assumptions (writes vs reads — reads dominate roughly 100:1), then cover the core: base62 encoding of an auto-increment or snowflake ID, a key-value store, and a cache like Redis for hot URLs. Mention one deliberate trade-off, such as counter-based IDs being predictable versus hash collisions. For 1-3 years of experience, clarity on the basics beats mentioning ten buzzwords.

What they’re assessing: This separates engineers who have operated real systems from those who have only built side projects.

How to answer: Show a funnel: check what changed (deploys, traffic, data growth), then measure where time goes using APM traces or logs — app code, DB, or downstream calls. Common culprits to name: a missing index after data grew, an N+1 query, connection pool exhaustion, or a noisy neighbour. Concluding with 'add an alert on p95 latency so we catch it next time' rounds it off well.

What they’re assessing: Code review quality signals your engineering standards and how you will lift the team's bar.

How to answer: Give a priority order: correctness and edge cases first, then readability and naming, then test coverage, then performance only where it matters. Mention checking that the change matches the ticket's intent — reviewers who catch 'this solves the wrong problem' are rare and valuable. Add how you phrase feedback: suggest, do not command, and separate blocking from nit comments.

What they’re assessing: Project deep-dives verify your resume — panels drill until they find the boundary of what you personally did.

How to answer: Draw or describe the request flow end to end: client, API layer, services, data stores, queues. For every component, be ready with a 'why this over the alternative' answer — why Postgres over Mongo, why REST over gRPC. Clearly separate 'I built' from 'my team built'; getting caught inflating ownership ends interviews in India faster than a wrong answer.

What they’re assessing: A fundamentals check — the interviewer wants trade-off reasoning, not a memorised table.

How to answer: Anchor on the real decision drivers: need for transactions and joins versus flexible schema and horizontal scale for write-heavy workloads. Give one concrete pairing from your work, like 'orders and payments in Postgres for ACID, session and cart data in Redis.' Mention that modern Postgres handles JSON well, so 'NoSQL because unstructured data' alone is a weak reason — that nuance impresses.

What they’re assessing: The hiring manager is calibrating your true level and checking for inflated ownership.

How to answer: Use a two-sentence project summary, then spend your time on the slice you owned: the module, the decisions you made, the numbers that moved. Proactively credit teammates for their parts — it paradoxically makes your own claims more believable. Keep one hard technical detail ready for the inevitable follow-up drill-down.

What they’re assessing: This tests judgment on tech debt versus delivery — the daily tension in every Indian services and product team.

How to answer: Avoid absolutist answers. A strong response: ship the feature with minimal targeted cleanup, log the debt visibly (ticket with cost estimate), and negotiate refactor time in the next sprint with data — 'this module caused 3 of our last 5 bugs.' Show you understand that business context decides, but that silent debt accumulation is your failure to communicate.

What they’re assessing: They want a self-starter with a realistic ramp-up plan, not someone waiting for spoon-fed onboarding.

How to answer: Offer a 30-60-90 sketch: first month — set up, read code, ship small bug fixes to learn the deploy pipeline; second — own a medium feature end to end; third — contribute to design discussions and identify one improvement. Ending with 'ship something small in week two' signals bias to action.

What they’re assessing: Managers are testing whether you cave silently, fight blindly, or negotiate scope like a professional.

How to answer: Walk through the negotiation: break the task down transparently, show where the time goes, and offer options — cut scope, add a person, or accept a quality/testing trade-off with named risks. The key line interviewers listen for: you commit to a plan you believe in, and you flag risk in writing rather than silently missing the date.

What they’re assessing: For 3+ years of experience, mentoring evidence is what justifies the next band in most Indian companies.

How to answer: Give one named example: what the junior struggled with, your specific intervention (pairing sessions, review checklists, breaking tasks smaller), and their measurable improvement — 'their PRs went from 4 review cycles to 1-2.' If you have not formally mentored, cite unofficial versions: onboarding a new joiner or writing internal docs the team still uses.

What they’re assessing: A weak 'no' signals low interest; your questions reveal what you actually optimise for.

How to answer: Ask two or three questions that show engineering seriousness: 'How does the team handle on-call and incident retros?', 'What does the path from SDE-2 to SDE-3 look like here?', or 'What is the biggest technical challenge this team faces this year?' Avoid leading with leave policy or hybrid rules — save those for the HR discussion after selection.