Software developer interview questions and how to answer them

Common questions for programmer / software developer

1. 01

   Tell me about the hardest bug you've ever debugged. How did you find it, and why was it so tough?

   Don't describe the bug, describe your method: how you reproduced it, which hypotheses you ruled out, and how you isolated the cause. What they're assessing is your debugging process, not the anecdote.

   "We had a payments error that only showed up in production, about one transaction in a thousand. First I managed to reproduce it: I captured the real payloads from the failing cases and built a test that replayed them locally. I ruled out the gateway by comparing its logs against ours, and ruled out corrupt data by validating the schema. In the end it was a race condition: two webhooks for the same payment arrived milliseconds apart and the second one overwrote the first. It took me a week because the aggregated log hid the real arrival order. I fixed it with a lock per payment id and added a concurrency test so it wouldn't come back."

2. 02

   You're in a code review and a teammate points out that your solution won't scale. What do you do?

   Show that you keep your ego out of the code. Explain how you ask for the specific case that breaks your approach, what you ask to understand the real limit, and when you concede versus when you defend your position with data.

   "The first thing is to ask for the concrete case: at what volume does my approach stop working? If they tell me my loop blows up at 10,000 items per request, I check it against real production data. That happened to us with a listing I'd solved in memory: they were right for the 5% of large accounts, so I paginated the query. But if the case they raise doesn't exist in our data or on the roadmap, I say so with numbers: we prefer the simple option today and note the limit in writing. I concede when there's evidence, I defend when the evidence is on my side, and I never make it personal."

3. 03

   Sketch me a rough design for a system that shortens URLs (or a feed, a shopping cart...). Where do you start?

   Start with questions, not the solution: volume, reads vs. writes, acceptable latency. Reason through the trade-offs out loud (consistency vs. availability, where to cache) instead of reciting a closed architecture from memory.

   "Before drawing anything I'd ask three things: how many new URLs per day and how many redirects, can they expire, and does click analytics matter? Say a thousand writes and a million reads a day: it's a read-heavy system, so that's where I optimize. I'd generate 7-character codes in base 62 from a counter with blocks pre-reserved per instance, to avoid collisions without coordinating on every request. I'd store the mapping in a key-value store and put a cache in front for the 20% of URLs that take 80% of the traffic. The redirect can be eventually consistent: if a link takes a second to propagate, no harm done, and that lets me replicate without blocking writes."

4. 04

   Why did you choose [your main language/framework] on your last project, and when would it have been a bad idea?

   Talk about real criteria: ecosystem, performance, the team that will maintain it. Recognizing when it was NOT the right choice counts for more than defending it as if it were perfect for everything.

   "On my last project I chose TypeScript with Node because the team already knew JavaScript, the product was an API with a lot of third-party integration, and the typing saved us the silly contract errors between services. It wasn't a trend-chasing decision: I weighed that hiring would be easy and that the ecosystem had mature libraries for what we needed. When would it have been a bad idea? If the core had been CPU-intensive computation, image processing, or something with hard memory requirements: that's where Node chokes and I'd have gone to Go or Python with native extensions. In fact we ended up pulling a PDF-generation job out to a separate worker because it was blocking the event loop."

5. 05

   You have to add a feature to a part of the codebase you don't understand and nobody documented. How do you proceed?

   Show a strategy for legacy code: read the tests, trace the inputs and outputs, make small, verifiable changes. Mention what you'd refuse to touch without a safety net.

   "First I read the tests, if there are any: they're the only documentation that doesn't lie. If there aren't, I trace the flow with a real case: I add logs or a debugger at the entry point and follow the data to the output, and from that I draw myself a map of what touches what. Before adding my feature, I write two or three characterization tests that pin down the current behavior, even if it looks strange to me: that behavior might be a contract someone relies on. Then I make the smallest possible change and check the tests are still green. What I wouldn't do is refactor at the same time as adding the feature, or touch something that moves money or user data without a net: there, tests first, changes after."

6. 06

   Tell me about a time you took a technical shortcut (technical debt) on purpose. How did you justify it?

   Make it clear it was a conscious decision with a known cost, not carelessness. Explain what you gained (a deadline, validating a hypothesis), how you documented it, and what the plan was to pay it back.

   "To validate an integration with a big client, I hardcoded their configuration instead of building the proper per-client config system. I decided it with my manager in the room: building the generic version was three weeks and the client was deciding within one. I flagged the shortcut: a comment explaining why, a ticket in the backlog with the real solution estimated, and an alert if another client hit that code. The client signed, and the following quarter we paid off the debt with the generic system. For me the difference between good and bad debt is exactly that: good debt has a date, an owner, and a cost someone accepted out loud; bad debt is the kind you discover six months later by surprise."

7. 07

   Difference between two things that look similar in your stack (e.g. list vs. dictionary, SQL vs. NoSQL, synchronous vs. asynchronous): when do you use each?

   Answer with the when, not the textbook definition. Anchor each option to a use case and to the cost you take on (memory, latency, complexity). If you can, cite a time you chose wrong and changed it.

   "SQL versus NoSQL, for example: it's not a holy war, it's a question about your data. If it has relationships that matter (orders, customers, invoices) and you need transactions, then SQL, because the database gives you the guarantees and you don't have to reinvent them in code. I use NoSQL when the schema is volatile or the volume of simple reads is huge: sessions, denormalized catalogs, events. The cost you take on with NoSQL is that the questions you didn't anticipate become expensive. It happened to me: we built analytics on top of a document store, and six months in every new report was painful; we migrated that part to Postgres and the queries went from hours of work to a single JOIN."

8. 08

   Your code passes locally but fails in production. What do you check first?

   List the suspects by likelihood: environment variables, dependency versions, real vs. test data, concurrency, time zone. What matters is the order of your reasoning, not nailing the exact cause.

   "I go in order of likelihood. First, configuration: missing environment variables or ones pointing somewhere else, it's the most common cause and the cheapest to check. Second, data: locally I test with clean data and production has the weird cases (nulls, accents, records from 2015). Third, versions: was the lockfile respected on deploy, is the Node or database version the same? Fourth, everything that doesn't exist locally: real concurrency, network latency, permissions, the server's time zone. And while I'm checking, I look at the logs of the real error in production instead of guessing: half the time the stack trace already tells you which of those four families you're in."

Many of these questions are the “tell me about a time when…” type. To structure those answers around a clear story, use the STAR method.

Tips to stand out

• Think out loud while you code. Silence hurts you more than a mistake: the interviewer needs to see your reasoning, not just the result.
• Before you code, restate the problem and ask about the edge cases. Diving into typing without clarifying requirements is the number one red flag.
• When you defend a technical decision, name the trade-off you accepted. "I chose X even knowing Y" sounds senior; "X is better" sounds junior.
• Have two or three projects ready to describe in detail: what problem they solved, your hardest decision, and what you'd do differently. That's the material half the follow-up questions come from.

Questions for other roles

• Interview for marketing specialist
• Interview for administrative assistant
• Interview for accountant