For a while now, I’ve had the unique chance to interview candidates for senior engineering roles at a company I work for. After speaking with dozens of people, I started noticing the same patterns coming up again and again - the ones that make interviews go sideways. And knowing that I’ll be on the other side of the table one day, I decided to write these down for future me. Some of them are obvious. Which is exactly why people keep forgetting them. And odds are, I will too.

And so there a few:

don’t be late

Sounds obvious, but I’m still shocked how often people break this rule. Life happens, and most interviewers will understand - they’re human after all (at least most of them). But whatever kept you, please reach out to the interviewer or whoever scheduled the meeting and let them know. It’s basic professional courtesy. The worst thing you can do is join 10 minutes late without a word, acting as if nothing happened.

know your weapon

As a full-stack developer, you’re likely switching languages several times a week - implementing a backend in Clojure, a frontend in TypeScript, throwing in some Python scripts here and there or implementing Tetris in Brainf*ck at lunch time. It usually takes a few hours to fully context-switch to the point where you’re not stopping to think about how a for-loop works (Clojure, I’m looking at you) or how to define an Enum in Java. The problem is, you don’t have those few hours in a coding interview. Switch the context at least a day before - open your Emacs, dive deep into the language of your choice, do some katas. And let your muscle memory do the work next day.

choose your weapon wisely

If you have a choice, lean toward dynamically typed languages (unless the role specifically calls for a statically typed one). Getting something up and running in Java requires significantly more effort and boilerplate than in Python. Ideally, have a REPL at your hand - you can quickly validate syntax, inspect the output of a function, or check a docstring. Stress makes people forget basic constructs. Assume you will blank on how to write a loop or how a switch statement works, and be ready for it.

it’s not about coding

With all the LLMs available today, you’ve probably already realized that this kind of exercise isn’t really about coding. Machines write code better than most of us - though they still don’t think (or so I keep telling myself). That’s exactly why we meet. We need a thinking human being, not just another coding machine. And this is your chance to show your human side - not superpowers, we’re not ClosedAI. Chances are, we’ll end up working together, and that’s why I care how you approach a problem: do you break it down into smaller pieces? How do you ask questions, even the ones that feel obvious? How do you talk through your thinking out loud? Imagine you’re already talking to a future teammate - because that’s precisely what the interviewer is imagining too. Radio silence, incoherent mumbling, chaotic jumping between ideas - all of that is far worse than code that doesn’t compile. The most brilliant people I’ve interviewed weren’t the best coders. They were thinkers who could clearly articulate what they were going to do next.

read and listen

One of the biggest red flags: diving straight into implementation without reading all the instructions. Or without fully understanding them. Or worse - not listening to the interviewer and ignoring what they’re trying to tell you. Make sure you have the full picture, just like an LLM building its context window. If anything is unclear or missing - for God’s sake, ask. Some instructions intentionally leave gaps to test your understanding. And more often than not, your assumption will be wrong.

timebox yourself

It’s interviewer’s part to keep the schedule but it’s your responsibility to split the work so, that you won’t surprisingly discover 5 minutes before the end that you still need to handle some edge cases or add a couple of tests. This is the turning point where the panic mode switches on. We all went through this at least once.

for f*ck’s sake, don’t cheat

Do you really think the senior engineer on the other side can’t tell? There are far more subtle signals that betrey you than you might think. Sure, you might suppress a few of them - but you’d need to be a KGB-trained spy with nerves of steel to control your entire body language. Your voice shifts in tone and pace, you stop blinking for a solid minute while your eyes dart compulsively side to side - and then you deliver a perfect answer, only to go completely silent the moment they dig deeper. It’s not a fun.

interview the interviewer

An interview isn’t a one-way street - or at least it shouldn’t be. This is your chance to ask about things that matter to you. Prepare those questions in advance. Seriously, prepare them. Showing up and asking “what do you like about working here?” or “so what does the company actually do?” leaves a bad taste, even if everything else went reasonably well.

practice interviewing

Like everything else in life, the more you practice the better you get and interviews are no different. Seek out companies you’re not desperate to join, and use them to get to the coding interview stage. The key is to learn from your mistakes. Ask for feedback, write down your own reflections. Treat it like a post-mortem: what went wrong? What could I do better? How could I have avoided this and that? Be grateful for every critical point you receive. That’s what helps you grow and boost your chances in the next round.