How To Face An Interview

The Interview Is Just A Technical Screening With Better Lighting

Most people walk into a technical interview thinking they need to perform. That's backwards. You're not being asked to be impressive. You're being asked to figure out whether you can work alongside their engineers without constant supervision. Everything else is noise.

I've sat on both sides of these tables. Candidates who could recite dynamic programming solutions blindfolded but couldn't explain why they chose their approach. And candidates who got stuck on a simple hash map problem but left because they were too busy performing to listen to what was actually being asked. The second category gets hired more often than you'd think.

How To Face An Interview Without Making It Worse Than It Already Is

The framework is straightforward but most people skip the first step. Before you solve anything, restate the problem in your own words and confirm you understand it. Write out the inputs, outputs, and any constraints you can see. This takes about two minutes and it prevents three separate failure modes: solving the wrong problem, solving a harder version than necessary, and looking like you don't read carefully.

Here's a specific situation I ran into last year. A candidate was given a question about finding duplicates in an array. They immediately started writing code that assumed the array was sorted. When I pointed out the input wasn't sorted, they froze for about forty seconds, then tried to sort it first anyway before solving. That extra O(n log n) step wasn't asked for. I didn't mark them down for missing the edge case—I marked them down for not catching it when it was right there in the problem statement. That's a pattern I see maybe once every ten candidates, but it's the pattern that matters.

What actually helps in these situations is thinking out loud as you parse the problem. Not rambling, just narrating your comprehension process. "Okay, so the input is an unsorted array of integers, output should be the duplicate values, no modification to the input array allowed. That rules out sorting first." This tells the interviewer exactly how you think, which is usually worth more than the correct answer on the first try.

What Happens When You Get Stuck

You will get stuck. It happens in every interview at some point, even for senior engineers. The difference between a pass and a fail isn't whether you solve everything. It's what you do when you can't.

When I hit a wall, I do three things in order. First, I state the blocker clearly instead of going silent. "I'm drawing a blank on the optimal approach here. What I know is that brute force would be O(n squared) because of the nested iteration, but I feel like there's a linear time solution using a hash set." This signals that I understand the complexity landscape even if I can't produce the clean solution immediately.

Second, I offer a partial solution or a related concept. Even if the exact algorithm escapes me, talking through what I do know gives the interviewer something to build on. Sometimes they'll give a hint that unlocks the whole thing. Other times they'll just note that I have the right intuition even without the precise implementation. Third, and this is where most candidates lose points, I don't apologize repeatedly or start second-guessing myself out loud. Every "sorry, I'm probably overthinking this" costs you credibility. You're not overthinking. You're working through a problem that doesn't have a clean path. That's the job.

The Coding Portion: How It Actually Works

Technical coding interviews typically run 45 minutes to an hour. They usually contain one or two problems. The first is generally easier—something that tests whether you can write correct code under mild pressure. The second might be harder, or it might be the same difficulty with additional constraints introduced partway through.

I want to highlight something most guides don't mention: they rarely grade you on whether your code compiles on the first try. They're watching how you debug. If you write something that breaks and then systematically find and fix the issue while explaining your reasoning, that's often a stronger signal than getting it right cold. I've seen candidates lose points for perfect code that was written without any visible thinking process. No comments, no discussion of tradeoffs, just typing. That reads as memorized, not understood. Also worth knowing: if the interviewer says "what if we added this constraint," they're not testing whether you'll produce perfect code on the spot. They're testing whether you can adjust your thinking when requirements change. This happens constantly on the job. The way you handle it in the interview predicts exactly how you'll handle it in production when a spec changes mid-sprint.

System Design Interviews Are Different

If you're applying for a senior or staff role, you'll likely face a system design round. This is where most people panic because they think they need a perfect architecture. You don't. You need a reasonable one that you can defend under questions.

Start with requirements. Ask how many users, what the read-to-write ratio looks like, what the latency targets are, what happens when things break. A candidate who asks good questions before drawing a single box will almost always outperform a candidate who immediately starts sketching a distributed system with Redis, Kafka, and five microservices. The latter is a red flag. It shows you're reaching for complexity without understanding the actual problem. I once interviewed someone who designed a caching layer for a system that had exactly two million requests per day and a single regional deployment. Two million requests per day is roughly thirty requests per second. They'd brought in sharded databases, load balancers, and an event-driven architecture. That's not overengineering. It's a complete misunderstanding of the scale involved. I told them directly, and they laughed and said they'd been told that by previous interviewers but didn't quite internalize it until that moment. They still got the offer because the rest of their design was sound. But it was a clear signal that they needed to work on calibrating their solutions to the actual requirements.

Behavioral Questions You Shouldn't Skip

These are usually the most unfairly discounted part of the process. Candidates treat them like a formality and rush through. That's a mistake. Behavioral questions are where hiring managers decide whether you'll actually fit into the team. Technical skills can be taught. Personality mismatches can't.

Use the STAR format—Situation, Task, Action, Result—but don't read it like a script. The result part is where most people fail. They describe what happened without quantifying it. "We improved performance" means nothing. "We reduced p99 latency from 800 milliseconds to 120 milliseconds by adding a caching layer" means something. Prepare three to five stories that can be adapted to different questions. A conflict with a coworker. A time you made a mistake in production. A project where requirements changed unexpectedly. A time you had to say no to a feature request. A story about mentoring someone or leading a technical decision. Each should have a clear problem, your specific contribution, and a measurable outcome.

What Interviewers Actually Remember

After a long hiring cycle, interviewers don't remember every detail of your solution. They remember how you handled uncertainty, whether you asked clarifying questions, and if you were pleasant to spend an hour with. These are real data points. Collaboration is the entire job. If you're technically brilliant but make every interaction tense or frustrating, you're a net negative for the team.

I've passed candidates who were mediocre technically but excellent communicators. I've rejected candidates who could solve hard problems but treated the interview like an adversarial competition instead of a collaborative problem-solving session. The competitive framing is wrong. You're not fighting the interviewer. You're solving a problem together and they're evaluating how well that collaboration works. Also, don't pretend to know something you don't. If you're asked about a technology or concept you've never encountered, say so. "I haven't worked with that directly, but from what I understand it's similar to X in that..." is infinitely better than bluffing your way through and getting exposed three minutes later. Interviewers can spot a bluff in about ten seconds, and once they do, everything you say after that is discounted.

The Aftermath

Send a brief thank-you email within 24 hours. Two or three sentences. Reference something specific from the conversation if you can. Don't gush. Don't re-pitch yourself. Just a polite note that acknowledges the time they spent with you.

You will not get feedback immediately, and in many companies you won't get feedback at all. This isn't personal. It's usually policy. If you don't hear back within two weeks, a short follow-up email is appropriate. After that, move on. The market is large enough that one rejection is rarely indicative of your actual capability. And one more thing that nobody talks about enough: practice matters, but not in the way most people think. Solving 500 LeetCode problems won't help if you can't explain your reasoning out loud. Do practice interviews with a friend or recorded session. Listen back to yourself. You'll notice places where you went silent for too long, where you jumped to solutions without exploring alternatives, where your explanations became unclear under pressure. That self-awareness is worth more than any number of algorithm drills.