I write code, at an average of about 3000-5000 lines a year. But sometimes a lot more, like in 2002-2004 when I wrote 21K or last year (2018) when I wrote 13K in a single year. The line count means very little regarding the value of what that code does to the business of software. So much of that depends on things out of my control it’s almost laughable; making motivation for doing the work kind of existential at times. But sometimes you hit the nail squarely on the head and your code is just what is needed for the business. And that feels wonderful!
Okay, true confession – I like to take interviews for other jobs occasionally. Since I haven’t changed employers for 2 decades (well, employers recently changed me, or whatever you’d call it), it’s clear it’s just an exercise in seeing what’s out there. But I’ve seen a lot.
One trend that bothers me is the interview coding test. It’s very popular among technical recruiters and I uniformly do poorly at it, having a problem presented to me and told to write code while my critical audience looks on. No, I don’t do that well. And I’m glad I don’t.
I write code in an IDE – Interactive Development Environment. There are many of these; my current tools of choice are Visual Studio (Code and regular) and Eclipse for Java. I’ve used many others though and they make the developer productive.
But I do not code on a white board in front of my peers or technical leadership. I get nervous, feel exposed as people see how I bumble through false starts, fat finger typos and well, bugs. And I challenge the value of that exercise in the interview process. Not because I stink at it, though yeah, I do and I’m proud to stink at it. But because it measures nothing but someone’s public coding ability. There generally isn’t anything that shows knowledge of libraries, tricks of the trade or ability to work on a team. Indeed, for the latter, I think this is the antithesis of teamwork.
If your company has people coding on white boards I really don’t want to work there anyway because you’re going out of business. And there are many fools’ metrics in technical fields, and the “grade” one would score on such a test is just that. If someone is a star public coder, what value does the business acquire? Arrogance? Fast code at the expense of functional, performance or system-level quality?
I’ve recruiting probably 200 people in my career. And I’ve batted around .900 in that, with facts like their productive stay in an organization being at least 2 years. I’m good at it.
But I will never give coding tests. I may ask for pseudo-code to demonstrate knowledge of overall control flow and variable and data structure management, but it’s always heavily couched in the “pseudo” genre.
Obviously software developers need to know how to code. But a Pavlovian exercise on the way in the door does little to predict how well someone will work out on the job.
Here’s a list of people who would NOT have been hired if we (and I) evaluated their candidacy solely by their results on a coding test:
a. An award-winning DevOps engineer, who came to us having written a few shell scripts and performing some very basic administrative duties on a UNIX server at an obscure company. I remember saying to my manager “This kid (and he was a kid) can do a job 3 times for every time anyone else does, so even if he messes up, he’ll be ahead”. I was completely correct; he thrived.
b. A very non-technical Lithuanian immigrant to the U.S. who decided to learn the Java 1.2 cold just for the interview. This person had never coded a line yet became a key contributor for several teams in system and performance testing.
c. A full-functioning peer of mine in database internals who was so timid in front of people he would wilt at even being introduced. He has written mountains of very useful code, specs (in conjunction with others) and performed diagnostic engineering tasks as well as anyone I’ve ever worked with.
Heck, I wouldn’t even qualify for my current job. That’s a new level of ludicrous. Because I write a lot of very useful code.