Don't worry. I know I'm not the first person to point this out (ex: here and here and here and here--geesh, 4.3K claps! AND HERE and here and her...
For further actions, you may consider blocking this person and/or reporting abuse
Amazing piece. Should be required reading for all interviewers.
I think it was DHH who wrote that he considers himself to be a "software writer". I.e., it is his job to write his intentions, through code, clearly and unambiguously to be understood by others.
If we're honest with ourselves, unless we're writing seriously low-level code, this is what most of us do. Those who believe otherwise should come off of their high-horses and learn that people and not code is the most important part of their work. Their interviewing approaches should reflect this.
I agree. I've done well on many of the "coding challenges" and failed on others. Another interview point that really gets to me is asking about patterns & practices, diving deep into specific ones, like SOLID, or Clean Code, passing those and getting hired - only to find the company does NOT use those patterns or practices! I've had several jobs where the interview did not at all match the expected job execution.
I like a lot of your thoughts, and as a 25 year veteran with a CS degree and masters, who did have to learn how pointers worked and write a simple interpreter, I probably would still fail some of those codewar tests.
Two things stand out as areas of lukewarm disagreement:
1) I find that having some decent familiarity with the way the low level architecture works (assembly, pointers, call stacks, etc) can be beneficial in solving some otherwise incredibly weird technical problems in business applications. And yes, even in the world of virtual machines. This is one of the areas where my education has resulted in savings of tens of thousands of dollars of debugging effort.
2) There are some "developers" who know how to google and fix syntax errors, and that's it. They appear to be developers, but are unable to produce almost anything non-trivial without a template. Those people are not common, but they exist, and I would prefer not to have to clean up after them. Having said that, esoteric coding tests are not the sensible fix.
Thanks again!
I agree with you to some extent, but in todays world knowing the basics is no longer enough. Knowing CS theory and a low level programming language well wont get you a interview, you have to know a myriad of frameworks and libraries as well that change every 5 years or so.
If you are hired to code vanilla C++ or Python then yes what you are saying is true but most of us need to know a whole bunch of extras on top of that its almost impossible not to open Google search, and you cant say that im not a true dev because I am not 100% familiar with the inner workings of a obscure framework that came out 5 years ago.
I agree with you. The CS things I've learned do come in handy on occasion!
This is a very thought provoking article.
I'm having a little bit of trouble imaging how to apply the PBI format to programming. Would you be interested in writing a followup post that gives a few example questions along with good vs. bad answers?
I enjoyed this article. Not to be nitpicky but "qualified" is mis-spelled as "qualifieid" which I don't believe was intentional in the sentence "To restate, the danger for companies is missing out on otherwise well-qualifieid individuals"
Thanks. Sometimes I sure wish I had a proofreader. :)
Can't agree more!