One of the questions I get a lot is about live coding interviews. Like interviews, there is a HUGE variety in what you may be asked to do during live coding. Some of it is totally open-ended, no trick questions, just writing basic methods. Some of it is done in a live collaborative environment like repl.it. Others are the standard “is this string a palindrome” type riddles.
There is good news and bad news in that, you can’t prepare perfectly for everything, so there is no point driving yourself crazy. However you can stick to some simple guidelines to make a good impression while live coding, even if you make mistakes, or don’t finish the exercise.
While I personally avoided this topic for a long time out of being intimidated, I have done my best to come up with goofy, memorable, and painfully straightforward examples in this section below about Big O notation. Although optional reading, I hope you’ll give it a try and feedback is welcome 👇
A brief conversation about big O
If you are not ready to dive into the big O conversation yet, I would summarize it (in terms of actionable things to focus on in coding interviews) with the following guidelines:
- Hash data structures are superheroes (python dict, JS object, etc)
- Getting loop-requiring data structures (like arrays) into hashable data structures will be your friend
- Getting from nested loops to singular loops will also be your friend
Part I: Getting started
You are at an interview. You may or may not have known there was going to be live coding. In the first few minutes, I would say you have a few key priorities:
Take a minute to quietly read the problem to yourself 📓
Take a minute to read, then reread the problem to yourself. Don’t think of solutions yet, make sure you really understand it. I have definitely read too fast and gone off half-cocked with a solution that missed edge cases before.
Pick the language you are best with - seriously 👨💻
If given the option to pick a programming language, don’t worry about picking what the company uses or picking a language to make “a better impression”. It is already a high-stress scenario, pick what you are most comfortable with. If it isn’t what they use, in the past I’ve offered a breezy rationale like “I wind up doing most leetcode problems with x, so guess I’ll go with that”. If they offer the options, they intend to let people use them. Don’t worry about picking JS over Ruby looking bad or anything like that.
Make sure their code environment is working (run hello world) 👋🏽
Believe it or not, I have had the collaboration tool break! Check that you are in good shape by just running a quick log statement.
Set the tone with your interviewer for narration and conversation 🗣️
Let the interviewer know you plan to ask them for feedback and chat with them through your approach, like you would with a colleague in the real world. It feels much less like public speaking when there is back and forth.
Have your interviewer collaborate on some test cases 🏁
It is easy to miss things in the heat of the moment, so this is a great area to get extra eyes.
Bringing some of the above points together, this is something close to what I think I say at the beginning of code challenge interviews:
Me: Great, so first I'm going to take a minute and read over the problem to myself if that's alright
Interviewer: Of course! Have at it
...
Me: Great, so before I get too far into this I want to run a quick hello world from this function and make sure everything is cooperating. ... Awesome, looks good.
Me: So now to get started, I'm going to try to explain what I'm doing and my thinking to you as I go. Feel free to jump in as I'm coding, I think it will be great if this is collaborative and gives us a sense of how we'd pair together if I joined the team. I'll probably have questions for you as we go also.
Interviewer: Yeah that sounds great! And I will chime in periodically to remind us of where we are with time, so if we run out there's some room to discuss what you'd do next.
Me: Sure, sounds perfect. So to start with, I don't want to miss any edge cases. I was going to put together some test cases and whether they should pass or fail. If there is anything I miss as I'm doing these, please don't hesitate to let me know. Being on the spot for coding interviews, sometimes can be nerve-wracking and I don't want to accidentally miss anything.
(etc etc)
Probably if you ask 10 people how they like to start code challenges, you’ll get ten different answers. Some people may not like my last comment, that I admit I’m on the spot and may miss something. In my experience interviewers have responded to that in a pretty human way, I even feel that it has been helpful? Sometimes they have supplied a test case I would not have thought of, and sometimes it does illustrate some aspect of the code challenge I hadn’t realized yet and would have wasted time dealing with later.
Especially when you are new to code challenges and extra nervous, you can go quiet for a second thinking about your approach, and the seconds spiral into minutes, and you are just sitting there silently panicking. It is good to get the conversational rapport going early. For a junior coder, it is honestly pretty normal to get stuck on some aspect of a code challenge, but if you are already in a conversational rhythm with interviewer it is much easier to say “I feel a bit torn but think my approach should be this…” and open the door for feedback and direction. If you have been sitting there silently for several minutes, it feels way more awkward to suddenly ask for help.
It varies place to place, but in many interviews the code working is ABSOLUTELY not the only outcome they are looking at. They are looking at collaboration (especially for juniors!) they are looking for how you deal with ambiguity, that you ask for help and don’t get stuck and spiral into panic. I would say almost always in code challenges, if you can convey what you are or were trying to do you can get “partial” credit for that alone, even if you were not close to a successful implementation.
Part II: In the thick of it
So you have your test cases set out, you have the code running. The pleasantries and housekeeping items from the last step are sort of the “easy part” when I do code challenges, and when you are through all that just staring at the code that’s the moment where it is easy to lose your head.
💡Listed below are the BIGGEST priorities while doing the main task.
Comment out the steps/phases of your solution immediately (”comment skeleton”) 🦴
For me, that looks something like this early into a code challenge:
// previously empty function where I did my hello world
function myCoolAlgo(sortedList, target) {
// first, I'm going to build a hash from my list items so that I can look
// them up more efficiently
// next, I want to build a separate validation method to check <blah>
// third, I want to <blahblahblah>
// next, I'll take the result indices and see if they are a prime number
// last, I'll return the result * 23
}
^ by the way, the comment bodies are totally fictitious, no clue what kind of code challenge that would be. But that’s along the lines of stuff I would write.
I like to comment out the stages of what I think I need to do early. A) to get feedback, and B) so if I get panicked and lose my train of thought, I have some reminders. For places that may save the code, it also provides a trail of bread crumbs into what your plans were if you had more time.
Many places are more understanding than you might think about not finishing. Others, they have a laundry list of items that they would add on to the challenge indefinitely, so there is no real “end”, but you may be able to make an impression even on parts of the task you didn’t have time for by leaving some comments with your ideas.
Giving my code a “comment skeleton” is maybe one of my more helpful habits ever in code challenges. I mean it, they do so much good. They keep you from losing your train of thought, for starters. It is also great to see a new coder comment their code, since sometimes junior software engineers do not write the most clear code anyway it is particularly needed for the work of an early career dev, and I know for me seeing an interview-ee has good comment practices would be a huge plus.
Talk about why and how you are making your decisions 📰
if you read the Big O thing linked earlier, or have performance considerations that led you to your solution, this is a great time to talk about your thinking on performance (so you get partial credit for that, even if you don’t finish getting them working). It is also a chance to reveal your knowledge passively outside of the specific code you are writing.
For each increment of new code, run some of your test cases 🧪
If you have commented your code out into “sections” sort of as I suggest, finishing each section is a great time to run some of your test cases and log what is happening so that you can guarantee you don’t go farther on nonworking code
Keep the conversation going, solicit feedback 💬
It is also SO SO important to keep the conversation going here! You really can get “partial credit” for things you know but are not implementing. I know I’ve said things like:
- I have a feeling I could get the performance better here, I’d like to get this working first and circle back to it at the end with time permitting
- For some reason I have a suspicion there might be edge cases that could bite us at this point, but I can’t put my finger on one…do you have any thoughts?
- I had hoped that I could keep this in a single loop for performance, but at this point am not seeing a way around adding a second. If I have time at the end, I would definitely come back and tighten up some things, just as I would with real code before submitting a PR
The subtext, or literal commentary I sometimes have at those points is along the lines of “YOLO code interviews are stressful”. I find owning it relaxes me somehow? Just saying you know what, I have limited time here, some of it is setting off my spider senses and I’d like to revisit it, but out of respect for the time limit I’m going to move on for now.
Some other things to keep in mind 🧠
- Ctrl + f can be your friend, misremembering my own variable names is maybe my biggest cause of errors/debugging in code challenges 🥴 usually you can ctrl + f down a page to track something and at least rule that out
- When torn between a longer, descriptive name and a shorter, ambiguous one pick the longer one
- Even though you are in a rush, take time to make sure your code is reasonably formatted and your variables are named reasonable things
- Although often code challenges are in the scope of a single function, if your function gets too big it is worth either mentioning or implementing breaking the logic out into a separate function just to show you understand separation of concerns. If you are tight on time, its fine to just add that in running commentary “normally I would break this out” etc
- Sometimes the unexpected happens! I have had the collaboration tool fail on us unexpectedly. It is good to have a backup in mind. I think when that happened to me I recommend we switch to repl.it and screenshare, and I wound up getting that job haha
Part III: Wrapping up
I think every code challenge I have done has been a unique adventure. The first one I did was a train wreck and after that I avoided them for quite a while, I got so lost in my code that I was basically just rambling nonsense by the end. Others, I’ve felt I did nothing special and got job offers. Others, I’ve felt I nailed but got shot down.
Code challenges are kind of a terrible way of assessing coders because of the fact that public speaking is one of the most common phobias people have, and even without a phobia there’s still plenty of other rational anxiety to have about them.
Although they always feel stressful, I think I can count on one hand the live coding challenges I’ve felt were truly awful:
- I asked them how to prepare, they said NOTHING about live coding, then sprung it on me before we even had done basic chitchat. I was totally flummoxed (this was that first one I mentioned). I couldn’t remember the difference between
sliceandsplicein JavaScript and just absolutely spiralled over my inability to remember. It sucked monumentally in the moment, but I very quickly moved to finding it kind of hilarious. By the end I knew I bombed so bad I was just giving random database hot takes because it was like? Who cares - They had one of those code editors where you couldn’t run the code. I probably would never even do an interview with those again. It is SO UNREALISTIC! It is not how we write code, and yeah it really did a number on me, I think I did very poorly with that premise
Over time, I’ve kind of come to even like coding challenges just because they are so relatively fast and over with so quickly. The more I did, I realized how much you get so-called “partial credit” for things you didn’t finish, so long as you are communicating. I realized people weren’t really watching me just looking out for any dumb mistake as I’d feared. It really is a lot about how you think, how you collaborate, and it seems like many that I’ve done have found finishing on time secondary.
But as you are wrapping up your code challenge, here are my final pieces of advice for you:
- Reiterate anything you would change/continue working on in the current code (this is a nice point to mention you would of course add tests to any functionality you write)
- Thank the interviewer for their time, and emphasize that you feel you can definitely thrive in a collaborative coding environment
- You can offer a brief defense or acknowledgement of anything that went wrong, and how/why it unfolded and either what you learned, or how you might avoid it in the future. But definitely thread the needle on keeping it positive/brief here
And voila, that’s it!
Optionally afterwards, you can send a follow-up note. It won’t hurt anything to add “I feel so silly that I did not think of this while on the spot, chalk it up to interview nerves, but realized immediately after the interview ended I could have used x to do y. I wish I would have thought of it during our session, but appreciate the opportunity and would look forward to any next steps” to whoever you paired with. In my experience, it is unlikely to hurt anything and shows some self-awareness, if you don’t feel you had time to address it in the interview already.
Conclusion
The biggest thing I would want anyone to know for live coding interviews is that you can’t perfectly prepare for them. Even doing this a long time now, some days I bomb. I’ve had recent interviews where for whatever reason, I could not sleep a wink the night before. My last interview cycle actually I had the bad luck to have this happen TWICE! I felt that I completely flubbed both, one resulted in an offer and the other a rejection.
Live coding is inherently stressful. For me, it has become hugely more manageable over time, so maybe there is something to practicing. You can definitely arrange ways to practice with friends, alternating Leetcode problems while screensharing over Zoom or whatever.
At this point in my life, I don’t know if I will ever stop being nervous to live code, but at this point it is much more like going to the dentist or some other mundane trial than the terrifying gauntlet I once found it to be.
So at the end of the day, chin up, it isn’t the easiest thing in the world but the experience is helpful. You also never know when you will get lucky. I once live coded a problem where I had recently received the exact same on Leetcode and had a solution perfectly ready to go.
There is always the unpleasant possibility that live coding is going to result in you feeling silly or even stupid for an hour, but over the years I’ve started to look at it like “Am I willing to feel stupid for an hour in exchange for a $50k raise?” because more than once, that’s been at stake and it has been secured through live coding. So at this point in my life, I say hell, sign me up to feel stupid for an hour, what’s the worst that can happen 😎