His palms are sweaty, mind's blank, fingers are heavy
There's bugs on his screen already, code's spaghetti
He's nervous, but on the surface he looks calm and ready
To debug, but he keeps on forgettingHow to traverse trees, binary search won't come
He clicks a button but the tests won't run
He's choking now, compiler errors showing now
The clock's run out, N-squared complexity, pow!
Software engineers tend to have strong feelings about LeetCode-style coding interviews. The arguments against them typically include:
- People don't perform as well in the high-pressure scenario of having a time constraint and an interviewer watching them.
- The coding challenges in interviews are not representative of day-to-day work.
- Nobody has ever had to reverse a linked list as part of their job.
- Doesn't evaluate other skills like debugging or reviewing code.
I don't disagree with these as they are all valid counterarguments to coding interviews. But the question remains:
How Do You Determine If Someone Can Program?
As someone who has sat on the interviewer side of the table many times, simply reviewing a candidate's resume is not a reliable method for evaluating their programming ability. Asking them questions about their experience often won't give an accurate picture of their coding skill either. Many a time in my experience has someone looked good on paper, been able to answer questions about work that they've done, but then struggled to write a for loop when presented with a coding task.
LC Easy Questions Are Ideal
In my opinion, asking "easy" level questions is enough to verify that a candidate has at least a minimum level of programming skill. Easy questions are enough to verify that the candidate has at least a basic level of programming knowledge and they're not so hard that the time is wasted in figuring out some clever, esoteric algorithm.
"Hard" level questions, and even some "Medium", are more of a test of whether a person already has algorithms memorized than a test of programming ability. Hard questions are more about figuring out the algorithm itself in an abstract sense, than about the skill of translating the algorithm into code. While creating or solving complex algorithm is indeed a valuable skill, most CRUD applications don't have that much algorithmic complexity. Sure, you want to prevent O(n²) nested for loops where possible, but rarely is there a need to implement some new hyperoptimized sorting algorithm.
Questions Should Reflect Job Activities
Reversing a linked list during an interview is pointless, but what about a coding challenge that can be solved in either O(n²) or O(n) time and evaluating whether the optimal or suboptimal solution is implemented? That is applicable to real world programming work, or at least should be, and has realistic applications.
Demonstrating basic programming skill, in my mind, is like playing scales when auditioning for a role in a symphony orchestra. A violin player may not play scales during a performance, but it's a way to prove one's skill to a prospective employer. The obvious counterargument here is that the violin player should audition by playing a piece they will be performing in concert. Agreed, but companies rarely, if ever, want to show candidates some of the proprietary code on which they will actually be working. If a company or team is willing to do that, then that would be ideal, but a LeetCode-style interview question that is similar to the actual codebase is a fitting approximation.
On a side note, showing a candidate some of the code they would be working on also gives the candidate an opportunity to judge whether or not they want to be working in that kind of a codebase. It's somewhat hypocritical that companies tend to have high bars for the code written by candidates while at the same time having a codebase that is most likely quite a mess.
Debugging Code
All that being said, my favorite type of coding interview questions from the candidate perspective are: given a set of code, describe what the code is doing and/or identify the bug(s). This tends to be a lower pressure interaction and mitigates the chance of the candidate blanking due to stress. It's easier to blank on writing syntax than on remembering what certain syntax means.