Tradeoff between clarity and technical performance in live coding sessions
When I code, I have a few habits that make it difficult for someone to follow:
- I frequently jump between functions and files, even if the one I wrote isn't finished.
- When working through my code, I often find it better to run the code to find and fix syntax issues instead of diligently reading line by line.
- I often use a random variable (could be the correct one or wrong one) as a placeholder while I type out the logic for some snippets and then update the variable to be the correct one after.
Although disorganized, I find this method makes me the most productive. I am detail-oriented, write test cases, and often refactor so although my methods are disorganized, my code is not. You may disagree, but for this question let's assume the tradeoff is: ease to follow vs output
This behaviour has negative consequences when someone watches me code. During pair programming I don't mind slowing down since high output isn't the objective and my abilities aren't being judged, but I struggle with deciding how much to slow down in live coding interviews. If I code in a more organized way and slow down to make my coding easier to follow, I would have less output. In a white-boarding interview it could mean the difference between a working solution and non-working solution. In a live coding exercise it could mean the difference between getting through all the iterations of a question/task or not.
I am looking for input from interviewers, or scatter-brained devs like myself, on tips on the habits and tradeoffs to make when coding live.
Examples of things I am thinking about
- Is there negative signal from frequently debugging over proof-reading code, and if so is there some threshold?
- If you're someone who has interviewed others, do you think there is a way for a candidate to be more disorganized but still clear. For example, if someones goes over the high level approach and says "I am now going to code out the rough happy path, it will take me a few minutes as iron out the syntax and refactor as I go", then I plug away, and afterwards, do a quick walkthrough of the completed code?
- Which would generally get a better score in a live coding interview? Fully implemented and hard to follow, or easy to follow but not finished?
Thanks!
![Mid-Level Software Engineer [SDE 2] at Amazon company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Famazon_logo.jpg%3Falt%3Dmedia%26token%3Dff5f2302-08be-43bc-b7b1-d381ba508d99&w=48&q=75){kind=logo}
Discussion
(1 comment)- 02 months agoEng @ Taro
Which would generally get a better score in a live coding interview? Fully implemented and hard to follow, or easy to follow but not finished?
I would challenge yourself to not set the expectation for yourself to be one of those two choices. Instead, the gold standard is to have both easy to follow and working code. Remember, you are going to be judged among other candidates, so the goal is to set the bar very high for yourself. But, if you had to pick one, you have to solve the problem at the end of the day. A lot of interview rubrics will give the candidate a weak no if they aren't able to solve the problem completely. There's no leeway unfortunately. I've seen candidates pull out heroics where they end up solving the problem in the last 5 minutes in a haphazard way, but since they solve it, you have to give a weak yes.
Is there negative signal from frequently debugging over proof-reading code, and if so is there some threshold?
There is some negative signal because it makes the interview think about whether the candidate knows what they are doing at a higher level, or if they are just guessing and hoping that they are able to get the output. The issue is that, in a production environment, this kind of thinking can lead to a lot of errors because it shows the candidate can have tunnel vision where they aren't thinking of the full picture of what they are doing. I think it's not a great approach to come up with an initial solution and sort of hand wave the edge cases away until you run into them, then solve them because it can greatly alter what the best solution is.
If you're someone who has interviewed others, do you think there is a way for a candidate to be more disorganized but still clear. For example, if someones goes over the high level approach and says "I am now going to code out the rough happy path, it will take me a few minutes as iron out the syntax and refactor as I go", then I plug away, and afterwards, do a quick walkthrough of the completed code?
I would reverse the order and do a walkthrough of your approach first. A lot of times, interviewers will prompt you with edge cases, and it's a lot easier to think about how the edge cases fit in with a more complete solution rather than band aiding fixes for the edge cases later on.
I often use a random variable (could be the correct one or wrong one) as a placeholder while I type out the logic for some snippets and then update the variable to be the correct one after
I do recommend getting out of this habit for interviewing because a part of most interviewing criteria is code quality. It's a simple enough mindset shift where it's worth it to take the extra 1-2 seconds to come up with a clear variable name as you are preparing for your live coding interviews. You can even practice this as you are coding in your day to day work.
