10 common mistakes in remote technical interviews

After five years of conducting technical interviews — first in person, then almost entirely remote — I've noticed something consistent: the mistakes candidates make in remote interviews are not the same ones they make in person. Some are obvious (the wrong lighting, the frozen screen). But most are subtler, rooted in misunderstandings about what remote interviews are actually testing and what interviewers are actually paying attention to.

I've conducted over 500 technical interviews at Lasting Dynamics. I've seen brilliant engineers torpedo their chances over things that had nothing to do with their technical ability. I've also seen candidates who, on paper, seemed borderline, absolutely nail the conversation because they understood something that others didn't: remote interviews are a communication challenge as much as a technical one. Here are the ten mistakes I see most often, and what to do instead.

Mistake 1: treating the setup as an afterthought

The first thing I see when a video call starts is not the candidate's face — it's their environment. A dark room, a distracting background, a laptop camera pointing up at the ceiling: these things create an immediate, unconscious impression before a single word has been spoken. I know this sounds superficial. But consider what it signals to an interviewer: if you haven't invested ten minutes in making sure your setup communicates "I take this seriously," what does that say about how you'll approach your work?

The fix is simple and costs nothing. Find a room with good natural light or position a lamp in front of you, not behind. Use a neutral background — a plain wall is perfect, a tidy bookshelf works too. Position your camera at eye level (a stack of books under your laptop does the job). Test your audio before the call. None of this requires equipment; it requires attention.

Mistake 2: not verifying your tech stack before the call

I've had candidates who couldn't share their screen because they hadn't enabled the permission. Candidates whose IDE wasn't installed, or was installed but had no relevant plugins. Candidates who had to spend the first five minutes of a live coding session setting up an environment that should have been ready in advance. Each of these situations creates a specific kind of stress — the visible, real-time stress of scrambling — and it's entirely avoidable.

The night before any technical interview, run through the entire technical setup as if the interview were happening now. Open your screen sharing, test your IDE, make sure your code runs. If the company has told you which tools they use, have them open and ready. If you're not sure, ask in advance — it's a completely reasonable question and shows preparation, not weakness.

Mistake 3: going silent during live coding

This is the most common and most costly mistake in remote technical interviews. In an in-person coding session, interviewers can see your body language, watch your eyes move across the screen, observe the physical signs of thinking. In a remote session, if you go silent, the interviewer has almost no signal. They can't tell if you're thinking deeply, completely stuck, or have simply forgotten they're there.

The solution is to narrate your thinking out loud — not performatively, but genuinely. "I'm thinking about the edge cases first before I write anything." "I'm going to start with a brute force approach and then optimise." "I'm not sure about this part — let me think through it." This running commentary does two things: it keeps the interviewer engaged and informed, and it often helps you think more clearly by forcing you to articulate what you're doing. The candidates who do this well don't feel like they're performing — they feel like they're having a conversation.

Mistake 4: pretending to know things you don't

Remote interviews create a particular temptation: the search engine is right there, the documentation is one tab away, and the silence of working alone can make it feel less risky to bluff. Don't. Experienced interviewers can tell when someone is bullshitting — the slight hesitation before a confident-sounding answer, the vagueness that appears when follow-up questions probe deeper, the inconsistency between what someone claims to know and how they reason about related problems.

More importantly, intellectual honesty is one of the qualities we value most. A candidate who says "I know the concept but I'd need to check the exact syntax" demonstrates self-awareness and honesty. A candidate who invents an answer demonstrates the opposite. We hire people who know what they know and are clear about what they don't — because those are the people who ask for help when they need it, who don't introduce bugs they don't understand, and who keep learning.

Mistake 5: not asking clarifying questions

When you're given a problem to solve in a remote technical interview, the most important thing you can do before writing a single line of code is ask questions. Not to stall, not to seem thorough, but because the problem as stated is almost always underspecified, and the way you respond to that underspecification tells the interviewer a great deal about how you work.

What are the constraints? What does "good performance" mean in this context — milliseconds, or just not O(n³)? Are there edge cases you should handle or can you assume clean input? What's the expected scale? These questions reveal that you think about problems in context, not in a vacuum. They're also often the difference between solving the right problem and solving a different, technically correct but practically useless one.

Mistake 6: optimising too early

A pattern I see constantly in live coding sessions: a candidate is given a problem, immediately starts thinking about the most efficient solution, and gets stuck trying to implement something complex before they've established that a simpler version works at all. This is the engineering equivalent of trying to run before you can walk — and it's particularly visible in remote sessions where I can watch the thought process in real time.

The better approach is almost always: get something working first, then make it better. A correct O(n²) solution that you can explain and verify is worth more than an incomplete O(n log n) solution that you can't finish. Once you have something working, you can discuss optimisation — and that conversation, where you demonstrate that you understand the trade-offs and can reason about complexity, is often more impressive than the optimised solution itself.

Mistake 7: ignoring the human on the other side

Remote interviews can feel oddly impersonal — you're talking to a face in a rectangle, and the feedback is harder to read than in a room. Some candidates respond to this by going into "performance mode": they stop having a conversation and start delivering a monologue. They stop checking whether the interviewer is following, stop inviting questions, stop treating the session as a dialogue.

This is a mistake on two levels. First, it makes for a worse interview experience — interviewers are human beings who want to feel engaged, not assessed. Second, it misrepresents how you actually work. Software development is a collaborative discipline. The interview is partly a test of whether you can work with the people you'd be working with. Candidates who treat it as a solo performance miss that entirely.

Mistake 8: not preparing questions about the role

The end of a technical interview — "do you have any questions for us?" — is not a formality. It's a genuine part of the conversation, and the quality of the questions you ask reveals how seriously you've thought about the role and the company. Candidates who say "no, I think you've covered everything" or ask something generic that could apply to any company signal that they're not particularly invested.

The questions that impress us are specific and show genuine curiosity: about the technical challenges the team is currently working on, about how decisions get made, about what the onboarding process looks like, about what success looks like in the first six months. These questions do two things: they give you real information to make a decision with, and they demonstrate that you're thinking about this as a mutual evaluation, not a one-way audition.

Mistake 9: underestimating the behavioural part

Technical interviews at most European software houses include a behavioural component — questions about how you've handled specific situations in the past. "Tell me about a time you disagreed with a technical decision." "Describe a project that didn't go as planned." "How have you handled a difficult relationship with a client or colleague?" Many candidates prepare extensively for the technical part and almost not at all for this.

This is a mistake, because the behavioural section often carries as much weight as the technical one. The answers reveal things that no coding challenge can: how you handle conflict, how you take responsibility, how you learn from failure, how you work with people who have different perspectives. Prepare specific stories — not abstractions, but real situations with real details — and think about what they reveal about how you work.

Mistake 10: treating the interview as a one-way assessment

The final and perhaps most fundamental mistake is treating the interview as something that's happening to you, rather than something you're actively participating in. The company is evaluating you — but you're also evaluating the company. The questions they ask, the way they explain the role, how they respond when you push back on something, what they say when you ask about challenges — all of this is information about whether this is a place where you'd actually want to work.

The candidates who show up with this mindset — curious, engaged, genuinely trying to figure out if this is the right fit — almost always have better interviews. They're more relaxed, more natural, more themselves. And they make better decisions at the end of the process, because they've actually gathered the information they need rather than just trying to perform well enough to get an offer.

If you're preparing for a technical interview with us, we hope this gives you a clearer picture of what we're looking for. And if you're curious about what working at Lasting Dynamics actually involves, take a look at our open positions.