Include debugging in the interview process
zhenghao.io
zhenghao.io
I really really appreciate having resourceful people about. People who can go hunt for answers, who can explore questions: they are the ones that make excellent fantastic programmers, and people who are fun to engage with & watch go at it. I very much agree there's a huge weakness in drilling people to see if they can come up with answers, and that this idea of seeing how they navigate & explore things is probably >50% of the real battle in sw dev life.
[1] https://freakingrectangle.wordpress.com/2022/04/15/how-to-fr... https://news.ycombinator.com/item?id=31047409 (993 points, 6 days ago, 542 comments, damnnnnnn!!)
Sure, it's closer to the actual day to day work, but a great dev should be able to understand code even without a debugger.
I find that “exploratory debugging” (for lack of a better term) is an under appreciated skill — using the debugger to learn about the code by seeing it in action as part of the ramp up process.
However, a contrary example to your point about being “able to understand code even without a debugger” is using a dev console in web browser to ‘debug’ html/css/js etc. Depending on the role that _could be_ considered an important skill (a specific case being examining http status codes).
Oddly enough, if we don't do our job, we get fired, just like everyone else. Other businesses actually apply this to their interviews and don't require applicants to demonstrate something utterly bloody trivial, as if they could somehow do their job for a decade and not know the basics.
Invariably, every dev writing these kinds of articles is simply stroking their own way of thinking - usually these discussions do not contain:
a) a modicum of common sense. b) an understanding your brain does not work the way everyone elses does.
Just because you find a certain debugging method works for you, doesn't mean it works for me - your most effective technique is not necessarily my most effective technique, because I don't think the way you do.
Some programmers may be slower at debugging, but faster at determining a good solution to a complex problem. They may be slower at writing Jenkins jobs, but faster at solving Maven problems.
https://dilbert.com/strip/2006-05-06
I wonder if Bug Squash fixes get submitted to the proper open source channels. Tha would be fun.
"Thanks for working through that, can you please sign this contributor agreement?"
I consider myself a good debugger, but the interview context helped me see some places I could improve my process. I was comfortable in the pdb debugging system, but could improve my ability to steadily narrow down the key buggy line of code in a short amount of time.
i was interviewing junior developers so i wasn't expecting master coders. and in addition to the points mentioned, i was also evaluating their ability to communicate. it worked out very well.