Software Engineer Interview

What Actually Happens When You Walk Into a Software Engineer Interview

I used to think coding interviews were just about solving LeetCode problems under pressure. That's wrong. The real test isn't whether you can reverse a linked list on a whiteboard. It's whether you can think out loud, admit when you're stuck, and debug a problem you've never seen before while someone watches you sweat. I learned that the hard way after bombing my first round at a mid-size fintech company because I tried to brute-force a hash-map problem instead of thinking through the constraints. A typical interview loop for a mid-level position runs about 4 hours split across three to five sessions. There's usually a screening round (30 minutes, phone or video), two or three technical deep-dives (45 to 60 minutes each), and a cultural or system-design round. Some companies throw in a take-home assignment, but that's becoming less common for senior roles because the signal-to-noise ratio is garbage. You spend 8 hours on a project, submit it, and the interviewer spends 20 minutes glancing at your code before asking if you know how to optimize your database query. It's a waste of everyone's time. The technical rounds are where most people fall apart. Not because they can't code, but because they stay silent. I remember one interviewer literally tapping his pen and saying "are you alive over there?" when I went 90 seconds without speaking during a graph traversal problem. He wasn't being mean. He was trying to assess whether I'd hit a wall or just thinking. Those are very different things and he couldn't tell the difference because I was being quiet about both.

What They're Actually Testing

Here's the part nobody tells you: interviewers often don't care about the optimal solution in the first pass. They care about your process. Can you ask clarifying questions? Do you consider edge cases before writing code? Do you recover when you make a mistake? I once nailed a question by turning around and saying "wait, I just realized I'm assuming the input is sorted, but what if it isn't?" The interviewer smiled and said "okay, walk me through that." That was the actual question. The sorted-array version was just the warm-up. System design rounds for senior positions follow a similar pattern but with bigger moving pieces. You'll get something like "design a URL shortener" or "how would you build a notification system for 10 million users?" The trick isn't memorizing every caching strategy. It's understanding tradeoffs. I spent two years working on a distributed logging system before I realized that the interview answer they want isn't the most technically correct one. It's the one where you explain why you'd pick an off-the-shelf solution over building it yourself. Most candidates get this backwards. They go full-custom-architecture because they want to look impressive. Interviewers see right through it.

Code Patterns That Actually Show Up

Two weeks before my Google interview I went through a curated list of about 60 problems, not the full 300 on LeetCode. The patterns repeat. Sliding window. Two pointers. BFS/DFS. Dynamic programming with memoization. Hash map lookups. Tree traversals. That's roughly 80 percent of what you'll see at any tier-one company. The remaining 20 percent is usually some variation of "implement this data structure from scratch" or a concurrency question that most backend engineers haven't thought about since college. Here's a specific example that tripped me up. I was asked to implement a thread-safe cache with a TTL (time-to-live) eviction policy. Not the whole thing, just the core put and get operations. I wrote something that used a dictionary with timestamps and a background thread for cleanup. The interviewer asked about race conditions. I said "add a lock." He asked what happens when two threads try to evict at the same time. I realized I hadn't thought about the interaction between the read path and the eviction thread. I fumbled through it and ended up with a solution that was theoretically correct but would have deadlocked under load. Later I learned that the cleaner approach is to use a concurrent dictionary with lazy evaluation on get, checking the timestamp at access time rather than running a separate eviction loop. This pattern keeps coming up in real code too. The interview version just strips away the noise so you can see whether you understand the core tradeoff.

What to Bring to the Whiteboard

Bring questions. Real ones. When the interviewer presents a problem, ask about input size, whether the data fits in memory, if the input is sorted, what the error handling requirements are. I had one round where the interviewer gave me a seemingly simple array deduplication problem. I asked if duplicates should be preserved in order and he said "no preference." I asked about the size constraint and he said up to 10^9 elements. I asked whether we could modify the input array. Only then did he reveal the actual challenge: O(1) space, O(n) time, no hash set allowed. That changed everything. Without those clarifying questions I would have written a hash-based solution and missed the point entirely. For system design, bring assumptions. State them out loud. "I'm assuming we need eventual consistency here because strong consistency would kill our write latency." "I'm assuming we have 100,000 concurrent users based on the requirements you gave me." These aren't filler words. They're the difference between a coherent design and a random architecture dump. I've sat through panels where candidates described building a microservices mesh with Kubernetes and service mesh routing for a app that had maybe 500 daily users. The interviewer didn't correct them until the end, and by then it was too late. The assumption was obvious from the start. Just say it.

The Parts That Go Wrong

Take-home assignments are the worst part of the process by far. They're designed to simulate real work but they never work that way. You're given 48 hours to build a feature that would take a team two weeks. The code you submit gets reviewed by someone who's already seen 30 other submissions and is actively looking for reasons to reject you. I had a take-home where I used a particularORM that the company didn't use internally. The feedback was "we prefer raw SQL in this codebase." Raw SQL. After I spent six hours abstracting queries into a clean repository layer. It wasn't about correctness. It was about whether I'd fit their existing code style, which they never mentioned in the brief. Phone screens are another failure point. Recruiters will often read from a script and ask standardized questions that have nothing to do with the actual job. I once spent 25 minutes of a 30-minute screen explaining binary search to someone who clearly just needed to check a box. The rest of the interview loop was fine, but that first interaction sets the tone. If you come across as rushed or dismissive during the screen, it colors how the technical interviewers approach you. It's unfair but it's real.

How to Prepare Without Losing Your Mind

Three weeks of focused preparation is more than enough. Start with the top 60 pattern-based problems on LeetCode, do them in order of frequency, and time yourself. 20 minutes per medium problem. If you can't solve it in 20 minutes, look at the solution, understand it, and write it out yourself. Don't just read it. The act of writing it is what matters. Then spend a week on system design. Read through a few real designs from engineering blogs. Understand why companies chose what they chose. The "what" is easy. The "why" is what separates junior answers from senior ones. Mock interviews are worth more than any problem set. Find someone who's done this recently and has a critical eye. Practicing alone teaches you to code. Practicing with a partner teaches you to communicate. I did three mock interviews before my final round and each one exposed a different weakness. First one: I talked too fast and skipped steps. Second one: I couldn't handle a follow-up question that shifted the problem halfway through. Third one: I wasted 15 minutes on an edge case that wasn't relevant. By the real interview I was calm, deliberate, and adaptable. That's not confidence. That's preparation. There's also the practical stuff that people forget. Make sure your development environment works before a virtual interview. I've seen candidates lose 10 minutes trying to install dependencies on a shared coding platform while the interviewer waits. Have a backup plan. A second device. A local environment you can share via screen share. Know which editor you're comfortable using without looking at the keyboard. These seem minor but they compound. A 10-minute setup delay eats into your thinking time and raises your stress level for the rest of the session.

One more thing that surprised me: the reverse question at the end. When the interviewer asks "do you have any questions for me?" that's not a formality. That's the last data point they have about you. I used to ask generic questions about team culture. Now I ask about the biggest technical debt in the current codebase or how they handle production incidents. The answers tell you more about the company than any blog post or Glassdoor review. And they show the interviewer that you're thinking like an engineer, not just a candidate.