With LeetCode questions, I am able to solve up to medium/hard questions relatively easily (less than 30 minutes). I walk away from the computer and think it through, usually with a whiteboard or clipboard.

During "real" online interviews (Zoom/Google Meet), the interviewers would put up an algorithmic problem to solve, and tell me to explain my thought process, solve it, and code it up.

How can I ask to go away to solve technical interview questions with a clipboard and alone time? I am willing to ask for clarifications as they arise, or explain my thoughts at the end (I can write down notes).

If I stay in the Zoom session, I feel as though they're watching and they keep telling me to explain my thought process, which distracts me. I am not able to solve anything with these pressures/distractions, even if they give me two hours.

I had also asked to use my clipboard/whiteboard, but they denied the request saying that they can't see what I write.

For those not familiar with software developers, the job does not usually require on-the-spot coding or people watching (except maybe demos, but that allows pre-scripted code).

Of course, asking for the accommodation is only a metaphorical bandaid, so I have been practicing with my webcam on and pre-recorded "please explain your thoughts" audio that plays when I pause typing for too long, like in an interview.

  • 3
    Would it be acceptable to both you and the interviewers if you shared your screen while using a whiteboarding app and graphics tablet? That way you get a chance to draw and think and they get a window into how you're visualising the problem. Commented Oct 3, 2022 at 8:15
  • 14
    The task you're being asked to do is not "solve the problem" it is "explain your thought processes". They're not looking for the solution, they're looking to understand how you approach the problem. Commented Oct 4, 2022 at 14:51

6 Answers 6


If I was your interviewer I would have no problem with you having a whiteboard behind the camera or a clipboard with some notepaper, I would have an issue with you walking away for some peaceful time to think.

These challenges are designed to put you under a bit of pressure to find out your approach to the problem, and for me at least, what you would actually be like to collaborate with.

If you're going to do this on your own then it might just as well be a take home test.

If you're interested in working at a company which has this kind of interview process then you've got no choice other than to become good at it or lose out to other candidates.

It is what it is and you're not going to change it.

  • Agreed except that I wouldn't say the challenges are designed to put the candidate under a bit of pressure, at least not necessarily at most companies. A lot of people don't work that well under pressure, and we want those people to be as relaxed and at ease as possible (given that interviews are inherently stressful) so we can see their best interview performance.
    – David Z
    Commented Oct 16, 2022 at 6:39

How can I ask to go away to solve technical interview questions with a clipboard and alone time?

Do you mean "go away" as if there is no camera watching you during a live coding interview ?

They won't let you do that for many reasons.

The first reason is that they are concerned that the candidates may cheat by going online and googling for a solution.

The second reason is to see how well you can verbally articulate and explain your solution live (perhaps under a bit of pressure and distraction in this case).

I had also asked to use my clipboard/whiteboard, but they denied the request saying that they can't see what I write.

This has the same answer as the question above. Even though they may view the candidates via zoom, they have no idea if the candidates are communicating with someone else or googling for a solution online.

I guess you can practice the following steps to do well in a live coding interview:

  1. First, tell the interviewers about your general strategy to solve the problem.

For example: I am going to use dynamic programming to solve this problem. I will also use this "well-known algorithm".

  1. Second, in your mind, you can try to break the solution into a few small steps, small blocks, or small functions. (You don't have to tell the interviewers about all these small steps at this time.)

  2. Third, write code for one small step at a time.

  3. Then, briefly explain to the interviewers the purpose of that small block of code before moving on to writing code for the next small step. You don't have to explain every single line of code. Instead, you can tell them the main purpose of that small block of code. If they have questions, they will ask you further, and you can go into more details. Otherwise, you can just move along to writing code for the next small step. Generally speaking, they won't ask you to explain the meaning of each line of code.

  • "candidates may cheat by going online and googling for a solution": this is exactly what I do during the job, which is normal practice. "in your mind, you can try to": except when I do this, the interviewer either tells me to explain my thoughts, or if it has taken some time (because they keep asking if I can explain my thoughts), gives out unneeded hints. "write code for one small step at a time": without the uninterrupted thinking time, I would be blindly coding, which is usually not working code.
    – fejyesynb
    Commented Oct 3, 2022 at 0:02
  • I don't think having anyone else to provide the answer is any more of a concern with going away. I could share my screen and audio remotely, and be in a Discord call and some online whiteboard session with them, all without knowledge from the interviewers.
    – fejyesynb
    Commented Oct 3, 2022 at 0:15

How can I ask to go away to solve technical interview questions with a clipboard and alone time?

Ask for a "take home" test.

Some companies use these as a standard practice, others don't.

If you are using a headhunter or agency, you can ask them if there will be a coding test, and if so is it a take home test. You can choose to decline interviews for companies that don't offer the kind of testing that you prefer.


I really don't believe in "live coding interviews," because I don't believe that anyone can produce source-code "under pressure" that is anything other than pure-crap. ("And I've been doing this for a very long time ..." Koff koff ...)

But ... "thought processes?" Yes. That would be very valuable – whether or not you completed the "programming contest." When first confronted with this brand-new problem, how did you initially think to solve it? What "potential issues" did you then foresee, after you thought about it a little more?

  • While I agree with your sentiment 100%, the fact is that many companies use these methods. In my experience exactly 0.00% of actual software development is done under these sort of conditions but that doesn't seem to stop this practice from happening. As long as candidates agree to go along, it's likely to continue. I liken this to standardized tests in schools. You get what you measure and so you get kids who do well on the tests but can't do important things. Same with "LeetCode" evals. You get developers who can do the little tasks but can't solve business problems.
    – jwh20
    Commented Oct 3, 2022 at 12:23

I had also asked to use my clipboard/whiteboard, but they denied the request saying that they can't see what I write.

This part is easy.

Just buy one of those cheap document cameras on a swivel, or get an extra web cam and point at your white board, or buy a cheap Wacom knockoff digital tablet. Use OBS to consolidate your two (or three) feeds into one virtual video feed.

This works for Zoom, Microsoft Team, Google Meet, etc.

If I stay in the Zoom session, I feel as though they're watching and they keep telling me to explain my thought process, which distracts me. I am not able to solve anything with these pressures/distractions, even if they give me two hours.

This part takes practice.

But first watch Edbert Chan on youtube to see how he does it. It's very educational. https://www.youtube.com/c/EChanTech

Then practice using https://pramp.com/ There is no need to pay any money, just select the peer-to-peer interviews. Or you can do mock interviews with your friends.

When I did my mock interviews through Pramp, it was very enlightening for me to experience an interview from the perspective of an interviewer as well. So make sure you play that role as well.

For those not familiar with software developers, the job does not usually require on-the-spot coding or people watching

Yes, but the job does sometime require good communication skills and good collaborations skills. And many times, that's also what they're testing you on.

Also, they want to make sure no one else is sitting in the room giving you hints.


I've given this type of interview for quite a few companies. I hate to say it, but while there is some stuff you can probably finesse for your personal style, there are some unavoidable requirements to this type of interview.

The Goal

The goal here is not to have a finished and perfectly working piece of code from you. The goal here is to learn how you think & communicate while you attempt to write a basically decent bit of code. The idea here is the collaboration and that is part of the job. You are right that most coding exercises are reasonably fake, because it's hard to cook up a reasonably complicated sample problem that can also be reasonably likely to be solvable in an hour and not have that be rather fake. But the case of having a hard problem that takes a bit of discussion prior to being completed is something the software engineers on the teams I run face every day, and it's not unusual in some companies to do pair programming where you are literally writing code in front of someone.

While not every company that runs this type of interview is a huge pair programming culture, most companies that run this interview do expect that the software engineers will work in teams that regularly communicate about hard problems while they are in the midst of solving them, and they regularly do it ad hoc with very little preparation. I've run incidents for both Akamai Technologies and AWS and it's been absolutely vital in those cases to be able to discuss half-baked & probably wrong software designs on the fly with little or no preparation.

The other anti-goal is (unfortunately) avoiding cheating. Hiring someone who can't actually do the job is an extremely expensive mistake, and it's worth loosing out on hiring some great engineers if it means avoiding the cost of hiring bad ones. Having you go offline and appear later with a solved problem can raise the question of whether you did the work yourself.

Some partial solutions:

That said, I too experience total brain-freeze when trying to solve problems in front of humans. Especially in the fake collaborative context of an interview, where I know I'm being judged. So here's some mitigations I would have no problem compromising on as both the interviewer and interviewee:

  • Have a whiteboard or work surface they can see - put a video camera on it. Because I do this day to day, I actually have a whiteboard desk surface and a camera pointing down. But in the early days, I had a piece of white printer paper which I held up to my laptop camera periodically and got the same effect.

  • Feel free to say "give me 5 min to collect my thoughts" - you may need to stay on camera, but you can ask for silence and even turn away from the camera. You can't go solve the problem for 20 minutes and come back with a finished result, but you can take that 5 min to calm down a sec, get a general idea of what you want to do, and then re-engage.

  • Most people that succeed in this sort of interview can start by pulling out a common pattern from a set of templates - stuff like what data structure they may use, or how they would iterate through inputs - are generally patterns that boil down to a few key choices. The first round of discussion is usually that - what are the basic building blocks of the plan and why is that a good choice? that part really can be a conversation - then you need to code it, and for that, the interviewer is usually happy to be quiet for a bit, if they know what track you're headed down.

  • Realize that the person on the other end of the conversation has also written code, and knows that it's a messy process. The first round will be a mess. Nothing written in the first 5 minutes will be there by the the last 10 minutes. There's tons of typos and deleting. It's totally OK. If you have someone who's trying to micromanage every line of code on you - it's OK to say - give me a chance to do a rough draft, then I'm glad to take your notes.

  • Interviewers will nudge you if you've gone completely silent and not prefaced it with a request to ponder for a few minutes. The reason: they have a bunch of data they need to collect about you and your skills. They can't do that if they can't see what you are thinking. If they know you just need a min to collect your thoughts, they can keep an eye on the time, and let you think. But if you just randomly go silent, they are in the dark, and it's poor form for them to just ignore you and hope something useful pops out before the time runs out. Most of the time when I do these interviews, experience has taught me that there are timing milestones where if we haven't gotten a certain amount into the problem, we're in trouble. So I'd rather be irritating and push to see if I can get the candidate to tell me a partial thought, than wait pleasantly and hope for the best.

  • Practice, practice, practice - do this with a friend, you need an actual human to observe you.

I won't feed you some happy line of hype that it's "meant to be a good conversation" or "you and interviewer are in it together". You are being evaluated and you both know it. I will say, though, that any interview of this sort needs someone who can actually program to be running it and doing the evaluation - so at every place I've participated in this process, the interviewer was an engineer or former engineer (ie, a manager of engineers). These are not folks who by their nature are looking to enjoy someone failing. Worst case, they'd rather be designing actual software with you right now, than doing this fake interview project. :) - more likely, they want to see you succeed competently, both because it feels great to be able to vote "yes" on someone, and because it means maybe they can stop doing interviews, because they've make the hire their team so desperately needs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .