You're crushing it: we were impressed by your beautiful LaTeX résumé (that was totally not from a common template), you aced our technical screen, and you charmed our Talent team, but now it's time for your biggest test yet—the live coding interview. Are you ready?

I've been interviewing backend engineers at $DAYJOB for over a year now, and in that time I've seen many candidates get tripped up by bad coding habits that are easy to avoid. I'll cover those in this article and try to set you up for career success. Bad news: this article won't give you the cheat code to pass every technical interview. Good news: it might give you some advice that will help you in all your technical interviews, and possibly your programming in general.

A couple disclaimers: first, I'm assuming that you'll be asked to produce actual working code that you can run in the interview (as opposed to a "whiteboard"-style interview where pseudocode is acceptable and the focus is mostly on pure algorithm design and analysis). Secondly, I started drafting this post a few months ago, which in our current AI landscape is approximately an eternity. Will all software engineering soon be subsumed into mere vibe-coding, thus rendering this article entirely worthless? Who knows! But on the off chance humans writing code remains relevant, let's dive in.

Practice the practical

Maybe you've been on that LeetCode grind, and their so-called "hard" problems pose as much challenge to you as reversing a string—that's awesome! But solving real-world problems requires practical skills in addition to theory, and where I work, we try to structure our interviews to reflect that: we're more likely to ask "can you build this?" than "can you invert a binary tree?". In that vein, here are a few common tasks that should be close to muscle memory:¹

• Open and process a file
  • What if it's CSV data? Bonus for Python users: can you do it without pandas, and why might you want to do so?
• Interact with an API over HTTP
• Parse & process HTML/XML
  • Can you articulate how this is different than the last point? (The answer is not "APIs are in JSON"…)
• Write a regular expression
• Add a simple CLI to your code
• Comfortably navigate the command line

In our interviews, you can use any programming language you like—use that to your advantage, and pick something that you'll be able to impress us with! If you're a Scala wizard, I'd rather see you flaunt that rather than have you guess at Python syntax.

Organize your code (for you, not us)

It's normal to feel pressured for time in coding interviews, and a common reaction is to abandon programming best practices and write one big script filled with globals.

We certainly don't expect interview code to match exactly what you'd push to prod, but here's my hot take: I think properly structuring your code can actually make you faster overall. Breaking down the overall problem into a series of subproblems means most functions you need to implement are simple, and testing them individually prevents silly bugs from tripping you up ten minutes later.

Furthermore, even if organizing your code does take a bit more time, it shows your interviewer that you can identify distinct subcomponents in the problem and build relevant interfaces to abstract them. Especially as you become more senior, this kind of design work is an important software development skill—why not take any opportunity to show off your chops?

Test like you mean it

I can't tell you how many times I've seen code like this:

print(my_func(5)) # should return 13

The candidate runs their code, sees the expected 13, and all is good… until they move on to the next part of the question, refactor my_func, and break the original behaviour. Usually that print "test" has been commented out or otherwise ignored, and now a time-sucking bugstorm is brewing—one that could have been entirely avoided by writing a "proper" test like:

assert my_func(5) == 13

(It's even shorter than the print + comment version!)

Keep a scientific mindset

Even with the greatest code organization and solid testing, something is bound to go wrong eventually. When that happens, we want to see how you solve it.

A common (but ineffective) debugging strategy is "guess-and-check:" glance at the code, randomly permute a line, then run again and see if it works. As an interviewer, that doesn't give me much confidence that you really understand your code or what went wrong.

Better yet is to approach it like a science experiment: examine all the evidence before you (yes, that means reading the whole error message—it's amazing how often people miss answers here), formulate a hypothesis, and test it. One of the joys of software is how easy it is to gather data. Don't guess when you can verify!

Also: print statements can get you a long way, but brushing up on your language's debugger support will often yield even greater dividends in the long run.

Know thyself

Using proper technical terminology—where appropriate—is great. But guessing isn't. If you've just finished that advanced algorithms class and can prove the amortized runtime of your data structure's operations, go for it! But if not, we'd rather see you honestly communicate the limits of your knowledge rather than confidently get something wrong.

Conclusion

I hope these tips help you write better software—in interviews, and elsewhere too.

Until next time, may the job offers be plentiful, and the commas abundant.