Software Developer Interview Questions That Actually Show Up in Loops

Tech interviews are getting harder. Not because the questions changed much, but because the bar to clear them has shifted. Gergely Orosz reported in May 2025 that interviewers now expect proper error handling, full input validation, and clean code within the same 45-minute window where a candidate in 2021 only needed to solve the problem at all. One mid-career engineer completed eleven full interview loops before landing a single offer.

The BLS projects about 129,200 software developer openings per year through 2034 – a 15% growth rate. What changed is the competition for each one.

What follows are 14 questions that show up repeatedly in real loops, with the kind of answer that clears the screen.

The coding round questions that matter

Most coding screens start from the same short list of problem patterns. Solve these four categories well and you cover roughly 70% of what you’ll see. (I don’t have data on the other 30% – it varies too much by company.)

1. Sliding window

“Given an array of integers, find the maximum sum subarray of size k.”

What they’re checking: can you recognize that a nested loop is O(n²) and reduce it. Say “brute force recomputes the sum every iteration, but we can slide a window in one pass” before writing anything. Interviewers note who thinks out loud and who types silently and hopes for the best.

2. Tree traversal

“Serialize and deserialize a binary tree.”

This trips people up because it sounds like two problems. It isn’t – the serialization format determines your deserialization approach. Pick BFS level-order, walk through a three-node example in comments before implementing. If you get stuck on queue indexing, say so explicitly. Silence is worse than uncertainty.

3. Hash map edge cases

“Find all pairs in an array that sum to a target.”

Everyone gets the hash map. Interviewers at Google and Meta still use this for junior roles because they’re watching edge case handling, not the solution. Empty array. Duplicate values. Target equaling two copies of the same element. Mention at least two before coding.

4. Dynamic programming

“Given a rod of length n and prices for each length, find the maximum revenue.”

DP is where candidates freeze most. The fix: define the subproblem in one sentence as a code comment first. “dp[i] is the max revenue for a rod of length i.” Then the recurrence. Then the code. Don’t hold all three in your head simultaneously.

System design – what the question is actually asking

System design questions look open-ended but they’re not. Every interviewer is checking three things regardless of prompt:

• Scope definition. Ask clarifying questions before drawing boxes. If someone asks “design Twitter” and you immediately start on the database schema, you’ve already flagged poor communication.
• Trade-off articulation. Not “SQL vs NoSQL” as a binary – but “for this read-heavy workload I’d start with Postgres and add Redis for session caching; at 10M daily actives I’d revisit.” Concrete thresholds, not abstract principles.
• Knowing what you don’t know. Gergely’s reporting found senior candidates are now expected to know “distributed systems concepts that previously might have only been expected at staff levels.” If you haven’t worked with geohashing or Kafka in production, say that and explain how you’d get there.

5. “Design a URL shortener like bit.ly”

Start with scale: “1 million URLs or 1 billion?” Then cover hashing approach (base62 encoding of a random ID), collision handling, database choice, CDN for redirect latency. What candidates miss most is read/write ratio. A URL shortener is read-heavy by roughly 100:1 – that ratio drives your caching and replication decisions, and mentioning it unprompted signals systems-level thinking.

6. “Design a notification system”

The interesting part isn’t push notification mechanics (everyone knows APNs and FCM). It’s delivery guarantees: at-least-once, at-most-once, or exactly-once? At-least-once is simpler but risks duplicates. Exactly-once is expensive. Pick one, justify it, name the trade-off. That’s what separates a mid-level answer from a senior one.

Behavioral questions, and why most prep for them is wrong

The STAR format is fine as a memory scaffold. The problem is over-scripting it. If someone asks “tell me about a time you disagreed with a technical decision,” they don’t want a four-act play. They want to hear your actual reasoning, including where you might have been wrong.

7. “Tell me about a technically complex project you owned.”

Bad answer: three minutes of architecture with no conflict and a clean success. Good answer: what was hard, one specific mistake, what you’d do differently. Interviewers doing behavioral screens know all projects have failures. If yours sounds perfect, they don’t believe you.

8. “How do you handle disagreement with a senior engineer?”

This is actually about self-awareness. They want to know if you can hold your opinion firmly while updating it when new information arrives. Include a specific example where you changed your mind. If you’ve never changed your mind in a technical disagreement, you’re either describing an environment where no real debate happened, or you’re not being straight with them.

9. “Tell me about a failure.”

Pick something with visible consequences – a production incident, a feature that got cut, a project that slipped a quarter. Walk through what you’d do differently. Interviewers have heard every sanitized “I worked too hard” version. They want actual reflection.

10. “Where do you want to be in five years?”

Honestly, I think this question is mostly a waste of interview time. But when it comes up, answer with a problem space rather than a title. “Working on infrastructure-scale distributed systems, IC or TL” lands better than “senior engineer or manager.” The specificity signals you’ve thought about the work, not just the rank.

JavaScript and Python specifics

The 2025 Stack Overflow Developer Survey found JavaScript used by 66% of respondents and Python by 57.9%, up 7 points from 2024. If your role is full-stack or backend, expect language-specific questions in one or both.

11. “Explain the JavaScript event loop.”

The complete answer covers three things: the call stack, the callback queue, and the microtask queue. Candidates most often miss that Promises go to the microtask queue, which runs before the macro-task queue, so a resolved Promise always executes before a setTimeout(0). If you can walk through that ordering without hesitation, you’ll stand out.

12. “What’s the difference between == and === in JavaScript?”

Everyone knows === checks type. The answer that signals real experience includes the edge cases: null == undefined is true with ==, NaN === NaN is false even with ===, object comparisons with either operator check reference not value. Three edge cases, cited unprompted, show you’ve hit these bugs rather than just read about them.

13. “How does Python’s GIL affect multi-threading?”

CPython only executes one thread at a time for Python bytecode. CPU-bound tasks won’t benefit from threading – use multiprocessing. I/O-bound tasks (network calls, file reads) are fine because the GIL releases during I/O waits. The follow-up is usually about asyncio vs threading: asyncio wins when you control the event loop and want to avoid thread overhead at high concurrency.

Four questions worth asking them

Every loop ends with “do you have questions?” Candidates who ask nothing leave a flat impression. Four that work well:

• “What’s the on-call rotation like, and how often does it page at night?”
• “What’s the biggest technical debt the team is carrying right now?”
• “Walk me through a recent technical decision you reversed.”
• “How does the team handle a failed deploy on a Friday?”

They’re not gotcha questions. They signal you think about production and process. Interviewers remember candidates who ask them.

What most prep guides miss

Most prep content treats the coding screen as the only filter. Gergely’s 2025 reporting found many candidates who code well still fail system design or behavioral rounds. The actual bar is the combination: algorithm fluency, systems thinking, and communication, all three across a two-to-four hour loop.

Eleven loops before an offer is an outlier. Most engineers who prepared methodically – 40-47 problems solved deeply, two real systems built end-to-end, decisions practiced out loud – got offers within four to six loops. Knowing what to expect gets you halfway there. The other half is repetition under pressure.

Go deeper: how to prepare for technical interviews and system design interview questions. For full timed mock loops, LastRoundAI’s mock interview tool runs sessions with AI feedback.