Thank heavens Jon Evans posted Why The New Guy Can’t Code, an explanation for all software development shops to read before hiring someone. This article explains that the evils of all poor hirings are:
a) Microsoft's fault
b) old systems
c) hungarian notation
d) not female
It's not the fault of poor HR, a bad interview, or even the lack of the supervisor's ability to explain a problem - no, the above are the reasons that the new developer "can't seem to get up to speed", "shows basic ignorance", and produces work that "is so kludgey that it...must be rewritten"
OK, I'll agree with a few points:
1. The brain-teaser questions.
Sure, they're fun - HR loves them because they can remember them - but ultimately, they were designed to show how people think about problems and how people arrive at solutions. They aren't actually a bellweather, especially as most of them are posted online.
Can you imagine a MacGyver interview? "You're on a plane plunging to the ground, you have a paperclip and a coat-hanger and 10 people to save, how do you do it?"
How do you test knowledge? Yes, you ask them to solve a basic problem. Really though? The best interviews I've ever had or even given involved giving a real world scenario. "We're building such and such a system, how would you do it?" If you're what the company wants, you'll likely be describing the same system they are building. If you're good, you'll give some ideas that they may not have thought of (not that they would let on). If you're great, they'll simply walk out going " I have to hire this person".
2. Old Systems.
Yes, we all get that the new systems provide features that no one had when growing up and learning systems. That doesn't mean those skills are not valuable. Maybe it's just me but I wonder how I would get along if everything changed and we lived in a world where electricity was banned or forgotten.
I'm not saying that you have to know how to forge an steel but I remember years ago someone arguing for procedural programming over OOP and guess what? Today there are people who will argue for MVC or MVVM patterns or writing 1s and 0s over 0s. The fact is, learning programming is the same - the tools make it easier, but they are still just tools. Learning good programming techniques is the same, whether it be C+ or Python and Ruby.
3. Hungarian notation.
OK, I know Jon didn't go after hungarian notation as a concept - he merely used it as an example of someone making tons of money from an idea implemented by Microsoft but still, is hungarian "the dumbest widely-promulated idea in the history of the field"? While I'm sure a**hole programmers like to think that code should be unreadable except by themselves, MOST developers recognize that code should be read-able. While a variable named CustomerPhoneNumber is obviously a string even though it's named Number; if your newest hire is from a foreign country, they may not know that SocialSecurityID should be a string but EmployeeID is a numeric field because of the way a system was designed.
Hungarian notation does solve a particular problem for any language. Is it perfect? No. Is it overused? Yes ; but then so is any naming convention that results in a variable named TableWasRetrievedByInvalidNumber (while a fabrication, naming variables descriptively have been taken way too far).
In retrospect, it's crazy to think that some people still have horses to travel, when there are cars or Segways. Despite the fact that roads were only built the size they are to accommodate them.
4. Not Female
Not even going there. I'm sure there are female programmers that suck, even if Jon's never met one.
I don't know Jon Evans, a fellow Canadian, but he calls himself a software engineer yet his history shows very little software engineering. He graduated from Waterloo and spent most of his time writing novels. While I'm sure he's done some software development, most of it appears to be in order to scrape by while writing. I'm sure the post was written with the best of intentions..actually, I think it was written more to incite than to explain.
Maybe the real message got lost in the wording: "Don't interview anyone who hasn't accomplished anything." As he accurately states: there is no excuse for software developers who don't have "something" that they can point to and say "I did this, all by myself!"
That isn't something new, though. If you hired someone without seeing what they could do, for ANY field, except maybe theoretical physics, you likely shouldn't be hiring. I wouldn't hire a writer without asking them to write something. I wouldn't hire a tester without either a) seeing them test or b) know their testing work.
And this isn't just about the new guy - there are lots of "old" guys who have gotten to the point where they rest on their laurels and don't improve.
The comments on this post are what make this article:
a) Pair program a recruit with your top engineer for 30 minutes. (hell, I'd say any engineer)
b) train before you hire
c) hire them to produce
If the purpose of the article was to generate conversation (and is there any other reason?), then it succeeded.
Comments