We have been interviewing for a Senior Embedded Engineer, and a pattern keeps showing up: candidates sitting at their computer during the interview and using it for more than notes. Sometimes it is translation. Sometimes it is pulling answers in real time.

I get why it happens. Remote interviews make it easy to keep extra screens open. AI tools make it easy to produce a clean answer fast. And some people are desperate to get hired, so they take shortcuts. I understand the pressure. I do not accept the shortcut.

The problem is not that tools exist. The problem is that using tools during the interview breaks what the interview measures. A senior interview is not mainly about hard skills. It is about how someone thinks and communicates when there is no time to hide. In the real job, a customer call does not pause while someone types. A vendor call does not wait while someone rewrites an answer. A production line does not care that someone can sound polished when they have a helper on the screen.

Senior work requires clear communication, clear thinking under pressure, and the ability to say, “I do not know yet; here is what I would check first; here is what result would change my next step.” That is what protects schedules, budgets, and customer trust. Embedded work makes this even less optional. It is constraint-heavy and failure-intolerant. Timing margins, power problems, noise, manufacturing variation, and field conditions do not respond to confident language. The job forces reality into the room.

You can usually spot live help by watching for patterns. Eyes repeatedly drift to the same off-screen spot. Answers take a long time to start and then arrive in perfect sentences. Language quality jumps around. Responses sound correct but generic, with little detail from real work. The biggest sign is simple: ask them to walk through their own answer step by step, and the reasoning falls apart. If a candidate cannot explain why they chose a step, what they expected to see, and what would make them change direction, then the answer is not coming from experience.

If the role is senior and the interview is remote, treat the interview like a real meeting. Video needs to be on, audio needs to be clear, and expectations need to be stated up front: notes are fine; tools generating answers are not. If translation is being used, it needs to be disclosed, and if clear English is a requirement, then translation during an interview is already a problem. Then ask questions that force real-time thinking and clear speech. Ask what they do in the first ten minutes when a board will not boot. Ask what they measure first and why. Ask how they decide between firmware, hardware, and test setup as the likely source of the problem. Push for specifics: what they saw, what they changed, what they tried first, and what would make them switch direction. One short live exercise helps too: share a small code snippet or a simple block diagram and have them talk through what it does and where it can fail. It does not need to be tricky. It needs to require clear thinking, not polished writing.

If you suspect live help during the interview, do not play games. Say it plainly and give one chance to disclose it: “I am seeing long pauses and your eyes moving off-screen. Are you using anything to generate answers right now?” If they admit it, end the interview. If they deny it and the pattern continues, end it anyway. This is not a courtroom. It is a hiring decision.

Using tools is not the issue. Hiding tool use to fake ability is the issue. If someone needs translation support for daily work, that is not a character flaw, but it is a mismatch when the job requires clear English in customer and vendor conversations. If you want the interview structure we use to screen for real senior ability in a remote setting, message me “INTERVIEW” or reach out at https://endvr.com/.