Something I find genuinely interesting about software developer interviews: the questions that trip people up are often not the hardest technical ones. They’re the ones where the candidate knows the answer but can’t explain their reasoning while they work through it. The technical knowledge is there. The communication isn’t. And in most interviews, communication is what separates people at the same technical level.
Here’s a ground-level look at what’s actually being asked across the main interview categories, and what interviewers are paying attention to when they listen to your answers.
The coding questions
Most coding rounds for software developer roles are still algorithm and data structure problems, though there’s been a noticeable shift toward more practical implementation questions at mid-stage and later-stage companies. The 2024 Stack Overflow Developer Survey found that a majority of developers find their day-to-day work bears little resemblance to typical interview questions. That’s still mostly true, which means you have to train specifically for the interview format, not just for the job.
The questions you’ll see most often at the coding stage:
- Array and string manipulation (two-pointer, sliding window problems)
- Tree traversal (BFS, DFS, lowest common ancestor variants)
- Dynamic programming (coin change, longest common subsequence, knapsack variants)
- Graph problems (usually BFS for shortest path, DFS for connected components)
- Hash map usage (two-sum style, frequency counting, grouping)
What interviewers actually watch for: whether you clarify the problem before coding, whether you talk through your approach before you implement it, and whether you test your code with a small example when you’re done. Many candidates who get rejected weren’t wrong. They just silently wrote code and submitted it, which tells the interviewer almost nothing about how they work.
Language-specific questions that come up
If your resume lists a particular language prominently, expect questions specific to it. For JavaScript roles:
- Closures and scope (can you explain what a closure actually captures, and write an example where it matters?)
- The event loop (what is the difference between microtasks and macrotasks?)
- Promises vs. async/await (these do the same thing differently, and interviewers want to know if you understand why)
- Prototypal inheritance (less common at senior level but still appears)
For Python roles, decorators show up a lot, as do questions about the GIL (Global Interpreter Lock) for roles that involve concurrency, and generator vs. list comprehension tradeoffs for roles doing data processing.
A useful self-test: can you explain the thing to someone who programs in a different language? If you can, you understand it well enough to answer the interview question. If you can only explain it in terms of the language itself, you might be pattern-matching rather than understanding.
System design questions
For mid-level and senior roles, system design is usually a separate round or a significant chunk of a round. Common questions:
- Design a URL shortener
- Design a rate limiter
- Design a notification service
- Design a distributed job queue
The question itself is usually deliberately open-ended. Interviewers want to see how you scope the problem, what clarifying questions you ask (scale matters enormously, and the right architecture for 1,000 requests per second is different from 1 million), and whether you can reason about tradeoffs without a fixed answer in mind.
The mistake I see most often in system design rounds is jumping to implementation too fast. Candidates start talking about specific databases or frameworks before they’ve established what the system actually needs to do. Start with requirements. What are the read/write ratios? What’s the latency requirement? Is consistency more important than availability in failure cases? Then pick components. Not before.
Behavioral questions at engineering interviews
These show up at almost every company and get ignored in almost every developer’s prep plan. They matter more than most technical candidates want to believe.
The questions you’ll likely face:
- “Tell me about a time you disagreed with a technical decision.”
- “Describe a bug that took you unexpectedly long to fix. What did you learn?”
- “Tell me about a project where requirements changed significantly mid-way.”
- “How do you handle it when you’re asked to deliver something you think is technically wrong?”
What interviewers are really looking for: whether you can work in a team, whether you’re someone who surfaces problems or buries them, and whether you’ve actually reflected on past work rather than just completed it. The STAR format (Situation, Task, Action, Result) is a decent scaffold, but don’t be mechanical about it. The result often matters less to interviewers than the reasoning in the middle.
Questions you should ask
Near the end of most developer interviews, there’s time for your questions. Don’t waste it with “what does the culture look like?” (too vague) or “what are the biggest challenges?” (too generic). Specific questions get specific, useful answers.
- “What does the deployment process look like, and how often does the team ship?”
- “What’s the ratio of greenfield work to maintenance in this role?”
- “How does the team handle technical debt? Is there dedicated time for it or does it compete with features?”
These questions also signal to the interviewer that you’ve thought about what the day-to-day job actually involves, which tends to read well.
The preparation mistake that affects technical candidates most
Most developers who prepare for interviews focus almost entirely on LeetCode problems. They grind 73 or 80 problems before an interview and feel prepared. Then they bomb the system design or the behavioral round because they spent nothing on those.
I’d suggest roughly this allocation for a two-week prep sprint: 40% coding problems, 30% system design concepts, 30% behavioral story preparation. The exact percentages depend on the role and seniority, but the principle holds. You are being evaluated on all three dimensions. Preparing on only one of them and hoping the other two will go fine is a bet that usually doesn’t pay off.
That said, I don’t have data on how this allocation changes at very senior or staff+ levels. My intuition is that system design and behavioral rounds weight more heavily there, but the right answer probably depends on the specific company and the specific team.