Coding challenges as part of an interview
Brent Simmons writing about coding challenges as part of an interview process.
I’ve read a bunch of the advice on this, and the advice says things like: “Start talking. Restate the problem. Talk out an approach. Consider how much space/time it will use. And then start writing code.”
I feel like Brent is speaking for myself when he says:
Which is of course not at all how I solve problems.
He then goes on to explain in detail how he typically approaches a problem domain that he is unfamiliar with when writing code. Which sounds very familiar to how I go on about writing code too. Furthermore,
And — even more critical — I don’t have a 45-minute time constraint. Nobody is watching me type and judging. I’m writing code to solve a problem, rather than writing code to get a job.
There’s a huge difference between “solve this performance problem with a binary search” and “pass this test so you can feed your family.”
This hits the nail on the head. I too had to solve similar coding excercises during an interview only to suffer from anxiety. I get tunnel vision and I am unable to demonstrate clear thinking.
Thank you for saying this Brent. I take comfort reading that a developer like you, at the top of their game, is faced with the same challenges as I do. It tells me I am not alone.
Related
- Practicing the Coding Challenges - inessential by Brent Simmons
- A Coding Challenge Can’t Show How I Solve A Problem - inessential by Brent Simmons
- We need to raise the bar on software development - qnoid.com