I’ve always hated programming exercises live during an interview. Way I dealt with it typically was taking notes about it after (so that if you see something similar in a different interview later, you can be better prepared for it). Doing various interviews coding exercises helps a little too.

You can’t do much preparation since you don’t know what they’re going to ask. You can assume there will be some “basic” programming questions, but that’s really as far as you can take it in advance.

My advice here is for during the interview: keep talking. You should always be talking. That’s how the interviewer assesses you. They want to know how you are deconstructing a problem and how you want to solve it. Sitting there silent for 5 minutes and then banging out some code isn’t giving them anything.

“Ok, I need to modify this array and I should try to do that in place. I need to look up the syntax for that because i rarely need to do this…”

“I don’t remember what a splurgenarf is. Can you give me a quick definition before I get started?”

“I’m going to just slop this incomplete code in and run it once to see the output. It won’t work but I want to see if the first part is on the right track.”

“I think you’re asking me to write a wrapper around a basic network call so that it will _______. Is that right?”

Oh, and you’ll always home your first interview if it’s been a few years. Don’t sweat it, and don’t make your first interview at a place you really really want to work because of that. You need to go through a couple of interviews before your brain remembers how to function in a coding interview because it’s so far divorced from how a developer usually works.

If you gets stuck, ask for help. Explain what your thinking is, and how you plan to tackle things, and explain what help you need to solve your issue. If you get the job, your employer can work with you if they know you’ll ask for assistance when you need it - they expect to provide training or helpful oversight to any new starter. In the interview test, they are checking your basic knowledge, and also whether you are teachable.

Just remember that with challenges like that, the main purpose is to guage your problem solving skills. You don’t necessarily have to complete the challenge in time, don’t necessarily have to make it work error free, etc. They want to see how you work through it all. Don’t get me wrong, if you ace the challenge, that’s great. But they mostly want to make sure you have the fundamentals and skills to comprehend the problem and work through to a solution.

You prepare for these by doing specific exercises for them, sad as it may seem.

Leetcoding problems? You grind them out for a month or two to prepare for doing them during interview loops.

Mock interviews can help too, to get you better at handling the stress. You can use services/groups for these, or just go interview for random places you’re not necessarily planning to actually say yes to.

One thing that might help is having a broader background in the field and its concepts. If an interview question can feature a bunch of concepts you’ve never heard of, you might have missing bits of background you could learn more about to fill in gaps. You could go from “I have no idea what a hadoop is or what it’s for” to “I know people like to use Hadoop for X and it works basically like Y but I’ve never used it myself” pretty quickly.

Anyone useful as a computer-related employee is still going to encounter problems they don’t immediately understand on a daily basis, though. You need to be able to happily and confidently say “I have no idea what X is, what is that?”. An interviewer will be happier to get a clear idea of what you don’t know than to see you struggle to pretend to know things, because someone who pretends to know what they don’t is a danger in a real workplace. And maybe they’ll actually teach you enough to let you solve the problem, or, failing that, to be able to answer the next interviewer who asks you about that thing.

Sounds like it worked