Live coding is hard
I’ve done a weird amount of live coding lately, and unsurprisingly I’ve been really terrible at it. Live coding is hard. And like so many other things in life that are hard, the only real way to get better at is to practice. The unfortunate thing about live coding? There aren’t very many opportunities to practice.
I am friends with a lot of smart people and when I asked them for advice on live coding, the most common advice I got was to not live code.
They listed off several alternatives that I’ll go into here, but ultimately the advice I got was to avoid live coding.
Morgan Estes suggested using do it live or something similar to give the illusion of live coding without the live debugging. Paul Dawson suggested using a cheatsheet, or recording the live coding at home to then show during the live coding session. Mark Wissler suggested using the “cooking show approach.” Explain how you would write the file, and then show the completed file.
My personal ideal for a demo is to comment out your account and comment it back in during the demo to show off the functionality. This can be more tedious to prepare, but it gives the audience an idea of what each commented chunk of code contributes to the final product.
And even so, all of these are great, but what if you can’t fake the live coding? What if you have a job interview and you must do some live coding during the interview? Well I’ve been in that situation lately too, and I’m here to tell you I didn’t do well in those interviews. It is a super hard thing to pull off. In addition to having to code in front of another person – which by itself is never fun – you have the added stress of this being a job interview. In my experience those are never fun either.
So what do you do in this case? You can’t really fake it because you don’t really know what you’re going to be asked to do. You can try to prepare by doing some random code challenges in front of friends or family, but it’s not really going to reproduce the stress.
Well, I’ve put together some tips for dealing with this. Hopefully they’ll help you if you find yourself in a live-coding interview.
1. Try to relax
It is definitely the most overused piece of advice out there. Maybe the hardest to follow too. But it’s important to remember. Remember to breathe and avoid getting so worked up you lash out or shut down.
2. Talk through it
It’s not only awkward for you to sit in silence trying to come up with the answer, it’s likely awkward for your interviewer to sit there staring at you. Talk through what is going on in your mind as you try to come up with the solution to the problem. Do they have a whiteboard? Ask if you can use it to brainstorm a little bit.
3. Comments, comments, comments
I think this was the favorite piece of advice I got for this. Jesse Harlin suggested doing an outline of your program in comments before coding it. This allows the person interviewing you to see how you would solve it in case you run out of time, as well as give you something to go back to in case you go blank.
4. Ask lots of questions
Ask if there is something specific they are wanting you to show with this. Are they wanting you to use .map() or does it matter? Or perhaps use an object over an array. If your function is going to be accepting parameters, which types will be input? A string or an object or perhaps both? All of these are completely valid questions that will show you are thinking about the problem, and will save you some time writing the program.
5. Ask how you can improve
This can be really hard to do, especially if you feel like you didn’t do very well in the interview. But you might get some really good information that helps you in the future. I was told that I should slow down and think out the entire problem before jumping into the code. Pretty good advice since most interviews last an hour, and I spent a lot of that time writing what turned out to be wrong program because I hadn’t asked the right questions.
Most of all, remember that pretty much everyone comes out of a live coding interview feeling like they didn’t do well. It’s a tough thing to do in a very stressful scenario. No one really wants to admit that, but it is true. Live coding isn’t indicative of you as a programmer, it’s just indicative of how you did under pressure in this one very stressful 45-minute interview. So don’t beat yourself up too badly.
Do you have more tips for live coding? Let me know in the comments!
There are a lot people I talked to and sought advice from before writing this blog post. Here they are in no particular order: Rob Sullivan, Jesse Harlin, Mark Wissler, Devin Clark, Adam Rackis, Morgan Estes, Paul Dawson, David Roberts, and Ryan Hoegg. Thanks so much to all of these guys for chatting with me and giving their insights!
