My views are my own, not those of my employer or of anyone affiliated with my employer. Here I speak in a personal, not professional, context.
Those of us in the engineering field all know fellow engineers who should never have gone into the field. This of course is not specific to engineering; there are accountants who can't account, salespeople who can't sell, marketers who can't market...the list goes on. Who among you didn't carry a weaker student through some group project? And if you didn't...well...I'll let you think about that one for a bit. If you took Operating Systems 2 with me, you know the person who I epitomize as the type who should never be let near a compiler, let alone graduate with a CS degree or work as a software engineer. Talk but no substance (and this guy didn't even have
talk part because he was quiet and hard to understand).
My employer's been looking to hire a few software engineers, so I've been involved in that process: interviewing, looking at resumes, all that fun stuff. Part of the application process is a code sample that each applicant must complete. My boss gives each applicant a specification for a simple program which any first year (first semester, for that matter) CS or SE student should be able to write. I won't say what it is, but at the heart of this program is a function (which I'll call f()) that can be written in 2-3 lines of code (not counting whitespace or comments). Depending on what inputs you want to handle gracefully, it could grow to 5-6 lines (again, not counting whitespace or comments). I was skeptical that such a simple program could tell you so much about an applicant, but I've been made a believer.
When I first became involved in the hiring process, I was a bit intimidated. I found it strange evaluating applicants while being so early in my career. The first person I interviewed was in the field longer than I'd been alive, which was a very strange thought to consider. I've grown accustomed working with people who have children older than me, but interviewing and evaluating them is a whole different ballgame. I had visions of candidates thinking to themselves,
what's this pissant guy fresh out of college doing interviewing me?. But it's part of my job, so I do it as best I can. And because I know I'm susceptible to bullshit, I place a heavy emphasis on how well the person writes their sample program.
I remember the first code sample I evaluated. It was written by an applicant who as I recall had just under a decade of professional experience. The code was bad. And wrong. Their implementation of f() did the complete wrong thing. And when you're applying for a job, it's a bad thing to turn in buggy and wrong code.
And at this point I feel I must digress. I've written buggy code in interviews before; I suspect I'm not the only one who has. But I had to write it on the spot, on a sheet of paper. This is different. This person had a computer, a compiler, a debugger, Google, and as much time as they needed to write this application. And it was still buggy and incorrect. So I wrote a summary of what was wrong with it and went back work.
Surely, thought I,
This was an isolated incident.
I was emailed a second code sample a week later. It was worse than the first, written by someone with more experience. I was shocked. How could this be? These people are professionals who have been doing this for a long time. How could they not write f()? It's not that hard. Just to make sure I wasn't insane, I spent a couple evenings writing my own version of this program. And lo and behold, I wasn't insane; it's an easy program to write.
For a time, whenever I saw one of these bad submissions, I got angry. People applying for senior positions wrote code just as bad or worse than non-senior applicants. I've seen programs written by senior applicants where f() was 3 pages long. Lest we forget, we as a society have come to rely quite heavily on software engineers, and some of them out there can't do something any first year student should be able to do.
I don't get as angry as I used to when I see a bad submission, though I find myself ranting about it often. Recently I've seen two incorrect implementations of f() which were both incorrect in the same way. It was really strange because it was a way of writing f() I would have never thought of (mostly because it was wrong). I shouldn't be surprised and saddened anymore at this bad code, yet I am every time I see it.
Some of my colleagues tell me I'm overly harsh, that I wouldn't hire myself if my own submission landed on my desk. Given that all the open positions require at least four years professional experience and I have half that, they're right that I probably wouldn't hire myself. But I'm cognizant of this and try not to hold anyone's code to a standard higher than the one I use for my own. When I wrote my implementation, I met every criteria I myself use for judging one of these code samples. And given that we are talking about a CS 101-style project, and given that some people write submissions that I like, it's certainly an achievable standard.