how not to hire yourself a programmer
About a month ago, Jeff Atwood of the Coding Horror blog posted his guide to hiring a programmer and after taking a look at his suggestions, I can only urge those readers who are either looking to hire IT people or may be in a position to do that in the foreseeable future not to follow it. Why? Because this is the kind of screening and interviewing policy sure to frustrate and discourage good programmers who will get an offer way before a disciple of Atwood’s process even gets to meet a candidate, and give your company a reputation for slowness on your feet and being impossible to please because after every step in the process, there’s yet another hoop through which candidates have to jump.
After the tenth coding exercise and the second hour of comp sci trivia, your candidates are either going to stop returning your calls or politely decline to continue jumping through all those hoops for anything less than a senior enterprise architect’s job. In the IT world, people in demand living in hot markets for technical professions are usually already employed and don’t have time to play games.
But for one reason or another, Atwood insists that you have to treat each applicant as if he will be receiving top secret clearances and must be vetted just as thoroughly as a future military officer. A third of his process is all about tech screens, which are of course necessary, but not when taken to absurd limits. Tech screens aren’t all that intimidating for those who keep their skills sharp, and if the screen is grueling enough it could actually be sort of fun in a somewhat masochistic way. If you pass a screen with good scores, you can quickly cement yourself as a solid, knowledgeable candidate, and it’s not unknown for some IT managers to start discussing very involved architectural topics with you to pick your brains and get an idea of your design philosophy.
These sorts of tech screens are very useful because they let you test the depths of an applicant’s knowledge while at the same time treating him or her as a person. What they don’t do is assume that the applicant is a complete and utter imbecile until proven otherwise, as Jeff’s screenings do. One day, after having read a claim by some company’s lead developer that 199 out of 200 applicants they interview can’t code a simple, first year warm up application, he became convinced that programmers are by in large woefully incompetent and decided that a good tech screening is one that insultingly assumes exactly that and demands the applicant disprove it.
Of course one wonders how a company could manage to attract a contingent of overwhelmingly uneducated programmers when it posts a job and how simple brain teasers you do on your first day of Intro to Comp Sci would puzzle a PhD in the discipline, which is why I give this claim about as much credence as to a feature on the discovery of yeti tracks. Certainly there are awful developers out there but they’ll certainly pass this bar with far more ease than Atwood thinks. And if they do, they’ll have to show their coding portfolio because according to him, any programmer worth his salt has one.
Yeah, about that. You see, most of us work on very proprietary and business specific tools and if we published the code for even a small piece of them we would be fired as soon as we hit the submit button on GitHub. Those of us working on public facing websites will definitely have a portfolio but beyond that even open source projects we develop can be a hard sell. Sure, I have plans to get the Hivemind project out there but beyond people who work with artificial neural networks and AI, the code is not going to have any real significance. It would show I can write code that compiles and runs. But how would it show someone that I can build the project they need built with very different requirements and end goals? It would also be worth noting that not everyone has time for extraneous coding for a portfolio either.
But oddly, Atwood’s process sees no room for such niceties because after all the screening to make sure you can indeed write a line of code and can answer programming trivia, he’d like you to do a project for him before you’re even considered to be hired. By this point, a good programmer already has three or four job offers from other interviews, and exits the process to a company with a saner HR policy. For those masochists still in the mix, there’s the requirement to take on a real unit of work as a side project. It’s paid of course, but it better get done on time and work. How will you have time to do it after a normal 8 to 10 hour workday?
How will you have to tell your family and friends that no, you can’t spend time with them because you have to work work work just to get a shot at maybe being hired by a company that treats you more like a disposable tool than a person and expects you to ask “how high” every time they say “jump?” How effective are you going to be diving deep into a system you’d know next to nothing about for a business process that may or may not have been clearly vetted and documented? Unless in Atwood’s world requirements are almost always spot on and users don’t change their minds or want customizations, you’re in for a baptism by fire and should be demanding hazard pay.
All right, phew, you got that project done as well. Surely after hours spent proving that you know bits from bytes and can write a FizzBuzz program despite Atwood’s conviction that it should be beyond your grasp over 99.5% of the time, explaining why you don’t have a portfolio of ready projects for scrutiny due to NDAs and NCAs and your general desire to remain employed, housed, and fed, and write working code they needed written to help their business keep going, you should be getting a yay or nay, right? Surprise! Now you have to get in a room, set up a presentation, and pitch baby pitch! Go on and sell yourself and your code in 15 minutes, tell them the reason why your code is the best thing since both sliced bread and perforated toilet paper to show them your burning passion for your profession.
Though before you start, what exactly are you going to pitch? This is kind of like telling people to get in a room and solve a word problem. What word problem? Without something very concrete on the table presenting or defending code is meaningless and when you actually have to present a solution, it’s a highly technical and often very long discussion. You have now been asked to behave like one of the current crop of Silicon Valley execs instead of actually doing your job, and while pitching is useful as a skill to learn, you have to have a product or an idea to pitch first and a need to do it.
Seriously folks, this will not get you a good programmer. A process like that may work in the Valley scene and for social media startups but it’s not going to work anywhere else. Programmers don’t have time to waste on a barrage of ill-considered tech screens, surprise projects, presentations, and portfolio pitch fests. They have a lot of code to write, a lot of things to test, a lot of problems to solve, and surprisingly, they like to be treated like people rather than cogs in a machine. Give them a screen, pick their brains, talk to their past bosses, then do the right thing and let them know what you think.
Atwood’s three ring circus of a hiring process will alienate all the candidates you really want unless you’re promising to double whatever they’re being offered elsewhere at the same time, and at best, net you someone who has nowhere else to go and has to endure the months and months of screening, waiting, presenting, and side projects just to get a job. Maybe this person will work very well and gives you exactly what you need. But don’t you start a search process to find the best fits, rather than managing a marathon where the key to winning isn’t so much knowledge as it is endurance and patience?
