Asklemmy

You prepare by fucking up a lot. You're gonna have to repeat this shit experience enough times that you get numb to it.

If you want to fuck up again, but in a more controlled environment, maybe check out some mock interview service like interviewing.io or others.

But, that's how it is. I just went through 7 months of getting punched in the balls before getting lucky.

(Also, leetcode and general prep does help a little too.)

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 are 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 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.

I just don't worry about it but yeah I can only do the simplest things when put on the spot and with no time to think or reference stuff.

I agree with every advice given here, I'd just add that you need to be proactive: in some interviews you'll be given a very lax list of requirements and that means that your capacity for risk assessment is being tested, you need to ask questions so that those very lax requirements slowly become very specific requirements. Risk assessment also play a part when you're determining scaling, security, and deployment concerns, and you win a lot of points by at least mention them, that's what is expected of you as an engineer with experience. Maybe you're interviewing for a junior position and the interviewer will say "don't worry about that for now", but what if he's expecting you to worry and you didn't?

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.

Other people have good answers already. Chiefly to ask questions and talk through your reasoning.

But also I've noticed the difficulty of interview questions varies wildly. Some places would give dynamic programming problems I'm terrible at. Others would give trivial "find the largest number in this array of integers, in python. Don't worry about efficiency. " problems.

What words do you mean?

Also that exercise is not about solving a problem but to observe how you would tackle the problem. And you do that, by asking questions when something is unclear, so you can actually formulate a solution on your head and then bring it onto paper, preferable in a programming language you know or pseudo code.

If you get 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.

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.

Sounds like it worked

You essentially have to practice for them by solving a whole lot of them.

I understand AI is really unpopular over here but for that I think it can be a good training partner.

Give it the name of the business the job description and let it work a preparation plan.

Also a reminder that sometimes we all fail interviews and that's the nature of this exercise. And sometimes interviewer will purposefully put you in an impossible scenario just to see how you behave under stress. So remaining calm and humbly saying what you dont know or understand can be a good thing to do. I did get a job for an interview I felt I had completely failed.

Anyway don't give up and good luck for your next interviews !

I've got nothing helpful to provide for you, OP. But these replies you've gotten from others, I wish I had known years ago. A lot of good advice here.

Best of luck.

I don't prepare, because it's testing a task that I do pretty much everyday. If I can't do it on-demand I don't see how I can call myself a programmer. That said, I do have some strategies.

Often the interviewer isn't looking for people able to recite detail in the documentation. They are looking at the quality of the code you'll produce. So I concentrate on explaining my approach to the problem, rather than the code.

• How am I going to structure it?
• Where are my concerns?
• What choices am I making about performance?

...and so on. If it's on a whiteboard I'll often write in pseudo-code that looks something like a language, but I'll state that I'm not trying to write perfect, compiler ready code.

I let them guide me to the level of detail they are looking for.

If it turns out they want to score points on me for missing a bracket, or getting the order of arguments wrong, then I take that as a negative against the company. Interviews go both ways, and you're looking for people you can work with too. So if they're going to nitpick in an interview they're probably going to be horrible to work with day-to-day.