The developer interview is a strange ritual. You spend your job writing real code with documentation open and time to think, then get evaluated by solving puzzles on a whiteboard while someone watches. It is not a perfect system, but it is the one we have — and with the right preparation, you can walk in far calmer than the process deserves. Here is how.
Understand what they are really testing
Interviewers are rarely looking for a flawless answer. They want to see how you think: can you break a vague problem into pieces, communicate your reasoning, and recover when you get stuck? A candidate who talks through a messy-but-honest approach usually beats one who silently produces perfect code, because the job is collaborative and the interview is a proxy for that.
Have a method for coding problems
Do not start typing the moment you hear the question. Follow a repeatable process:
1. Restate the problem in your own words
2. Ask about edge cases and constraints
3. Talk through a naive approach first
4. Improve it, explaining the trade-offs
5. Code it, narrating as you go
6. Test it with a small exampleThis structure keeps you moving even when your mind blanks, and it shows the interviewer exactly the collaborative thinking they came to see.
Practice the fundamentals, not a thousand puzzles
You do not need to grind five hundred problems. You need to be genuinely comfortable with the building blocks: arrays and strings, hash maps, recursion, and basic sorting and searching. Most interview questions are variations on these. Know why a hash map turns an O(n^2) scan into O(n) and you have a tool that unlocks a huge share of problems.
Prepare your stories
Technical rounds are only half of it. Someone will ask about a hard bug you fixed, a disagreement with a teammate, or a project you are proud of. Have two or three real stories ready, framed simply: the situation, what you did, and how it turned out. Specifics beat platitudes — “I added an index and cut the query from 4s to 40ms” lands far better than “I care about performance.”
It is a conversation, not an interrogation
Ask clarifying questions. Think out loud. When you are stuck, say so and reason about why — that is data the interviewer wants, not a failure. And remember you are evaluating them too: how they treat you in that hour is a preview of what working there feels like.
What to do when you’re completely stuck
Every candidate fears the blank-mind moment, so rehearse the recovery instead of hoping it won’t happen. The escalation that works: first, solve a smaller version — if the problem is hard for an array of n, solve it out loud for an array of three and watch the pattern reveal itself. Second, reach for the standard tools by name: “Could a hash map help here? Sorting first? Two pointers?” — running through the short list aloud shows method, and one of them usually bites. Third, say precisely where you’re stuck: “I know I need to track the earliest timestamp per user, I’m unsure how to update it in one pass.” That sentence converts a stall into a collaboration, and interviewers respond to it — many will nudge you, and taking a hint gracefully is itself a signal they’re hired to look for. What kills candidacies isn’t being stuck; it’s five minutes of silence followed by an excuse.
The questions you ask are part of the interview
“Any questions for us?” is not a formality — it’s a free scoring opportunity and your best due-diligence window. Skip the salary-adjacent stuff (that’s for the recruiter) and ask things that show engineering maturity while revealing what working there is really like: “Walk me through what happens after a bug reaches production.” “How long does a typical change take from merged to deployed?” “What’s the on-call load actually like?” “What made the last person in this role successful?” The answers tell you about testing culture, deployment maturity, and whether the team is honest about its problems — and asking them tells the interviewer you’ve shipped enough software to know what matters. Prepare three; you’ll get time for two.
The week before: preparation that actually moves the needle
Cramming two hundred puzzles the week before doesn’t work, but targeted preparation does. Re-read the job posting and refresh the two or three technologies it emphasizes. Do a handful of problems in the interview format — speaking aloud, on a bare editor or shared doc without autocomplete, with a 25-minute timer — because the delivery medium is a skill separate from the solving. Reread your own résumé line by line; anything on it is fair game, and “tell me about this Kafka project” deserves better than a blank look at your own past. Finally, prepare your environment for remote interviews: camera, mic, quiet room, water. None of this is glamorous; all of it compounds into the calm that lets your actual ability show.
Frequently asked questions
Should I admit when I don’t know something? Yes, immediately and without drama — then show how you’d find out: “I haven’t used GraphQL in production; my understanding is it lets clients specify the shape of the response. I’d start with the official docs and a spike.” Bluffing gets probed, exposed, and remembered; honest-plus-curious gets respected.
How much does the language I choose matter? For algorithm rounds, use whichever language you’re most fluent in — fumbling syntax in an “impressive” language costs more than any points the choice earns. Exception: if the role is explicitly for one stack, expect at least one round in it.
What if I bomb one round? One weak round is rarely fatal — panels evaluate the aggregate, and everyone has an off hour. The classic mistake is letting round two’s disappointment poison rounds three and four. Between rounds: breathe, reset, treat each interviewer as a fresh start. They haven’t compared notes yet.
The takeaway
Prepare a repeatable problem-solving method, get fluent with the core data structures, ready a few honest stories, and treat the whole thing as a conversation. Do that and the developer interview becomes less an ordeal to survive and more a chance to show someone how you think.
