I've been on both sides of the technical interview table. Sometimes I'm the one sweating through a coding challenge, other times I'm the one deciding how to evaluate a candidate. Along the way, I've seen a few clear patterns in what works (and what doesn't).
Here's what that looks like from both perspectives.
As an Interviewer
When I've run interviews, I've leaned heavily on technical conversations rather than puzzles or trick questions.
That means sitting down with someone and asking them to talk through what they know, what they don't know, and what they actually like doing. I'll often dig into past projects:
- What trade-offs did you make?
- What would you do differently if you had twice the time?
- What parts of the system frustrated you?
I'm not looking for “perfect” answers. I'm looking for signals:
- Can you clearly explain your reasoning?
- Do you know your own limits?
- Do you light up when talking about certain problems, and shrink away from others?
The job isn't about memorizing solutions-it's about how you think, communicate, and make trade-offs. These conversations often reveal more than any contrived exercise ever could.
And honestly, they're more enjoyable for both sides. Instead of watching someone struggle through a binary search tree implementation, we get to talk shop. That's a better predictor of whether I'd want to work with them every day.
As an Interviewee
I've had my fair share of experiences across the spectrum. Some good, some less so.
Esoteric algorithm challenges
These are the “can you do dynamic programming on a whiteboard in 20 minutes?” style questions. I'll be honest: I still bomb these. They're mostly about drilling patterns until you can regurgitate them under pressure.
I once got asked to implement Conway's Game of Life that, with time, I probably could've solved-but in the moment, I froze. Unless it's two-sum (which I've got memorized), I'm not your whiteboard hero.
I understand why these persist-they're standardized, and you can compare candidates on a consistent axis. But they rarely map to the day-to-day work of building software.
Real-world coding challenges
These are my favorite. I've been asked to build or fix a simple web app or API server, usually in TypeScript or Go.
Sometimes it's something as small as:
- Add an endpoint that calculates a running total.
- Debug why a POST route is returning the wrong status code.
- Wire up a simple front end to call the backend you just wrote.
These exercises feel much closer to reality. They show how you name variables, how you structure code, whether you remember to handle edge cases, and how you test. In short-they reveal how you actually work.
The best part? Even if you don't finish, the interviewer can still learn a ton by watching how you approach the problem.
Technical conversations
And then there are the conversational ones, just like I give when I'm the interviewer. Some of the best interviews I've had were simply about discussing trade-offs, high-level design, or walking through my past decisions.
For example:
- “If you were designing this feature, how would you balance speed vs reliability?”
- “What's an architecture decision you regret, and why?”
No IDE, no stopwatch-just talking through real engineering problems. These feel collaborative, like a design session you might have on the job. And they've consistently left me with the best impression of both the company and the role.
What This Means For You
Don't panic if you're not an algorithm wizard. Many real-world interviews weigh practical coding and conversation more heavily. Passing or failing a graph problem doesn't define your career.
Get comfortable narrating your thinking. Whether you're debugging code or sketching a system design, talking through your decisions is half the game. Interviewers want to see how you approach problems, not just whether you land on the “right” answer.
As an interviewer, think about fit, not filters. You'll learn far more by understanding someone's preferences and reasoning than by seeing if they can invert a binary tree under pressure. Hiring is about building teams, not grading exams.
Final Reflection
The truth is, there's no single “right” way to run a technical interview. Every format has trade-offs. But after being on both sides, I've learned that the best interviews aren't about tricking someone into an answer-they're about creating space to see how they think, what they value, and whether they'd thrive in your environment.
That's ultimately the point of an interview: not to test for perfection, but to test for fit.
Top comments (0)