Being a senior software engineer that can write in multiple languages, that has experience with building and managing teams, and over a decade of experience in the software development world. I wanted to throw my hat in the ring and provide you with insights on what type of interviewees I have interviewed in the past and give you my recommendations on what you should be looking for and who to hire, and who not to hire.
Which programmer do you hire: the one who programs a messy program in three hours or the other who does a well-structured program in twelve?
Time to complete means nothing, it’s the deliverable and the question(s) asked by the interviewer, and the interviewee’s ability to talk/walk through the code after
Being a senior software engineer that can write in multiple languages, that has experience with building and managing teams, and over a decade of experience in the software development world. I wanted to throw my hat in the ring and provide you with insights on what type of interviewees I have interviewed in the past and give you my recommendations on what you should be looking for and who to hire, and who not to hire.
I personally would not pay attention to the time it took them because this is irrelevant. A good technical interviewer would know it’s what’s before/next that matters.
First, if either interviewee asks questions immediately after tasking them with the project but before programming has started is a great start. The individual with the (most/right) questions is most likely the better candidate. Some examples of these questions can be, is this a quick tool that is planned to be thrown away or will this code be actually used in production. Is there any sort of deadline for the project. Most interview type programming is time-restricted, as to be more real-world-like. But let’s step through some candidates that I can relate to personally, having hired/managed/worked with programmers my entire career. For the sake of this article, we are going to assume that the candidates get 3 hours to complete the project assigned.
He/she has made models/classes, set constants for any seemingly variable aspects of the program (like file paths, ports, IP addresses, strings, etc), functionalized most of the re-usable parts of the codebase, has great comments, a GOOD readme with examples on how to compile and run the program. They probably wrote a script which automatically compiles the program, perhaps a makefile, maybe even included some testing (unit tests) to ensure this program’s input and output works properly and functions within parameters. This person went above and beyond and is probably a senior-level programmer and someone you want to hire. BUT, they did waste a lot of their time and went above the allocated time of three hours. This is someone that is probably incapable of “hacking” of any kind. They are perfectionists, they will often think through a problem, sometimes for weeks, before having any deliverable. And though when they do kick out that deliverable, it will be AWESOME, it may not be what you need, because you didn’t know what you needed until you had it, which is ever-so-often in the software world. This is a solid hire, but you should probably balance your team out with some “hacker” types so that this candidate doesn’t take 7 years to develop a simple program which ends up not being what you needed when a simple proof-of-concept could have been made instead.
This candidate will ask a lot of questions after you assign them this task, most of which are questionable at best. Their end-result they provide you looks like something an intern fresh out of college would do, their functions are named terribly, there are no common programming patterns followed, there is no readme, the program barely works, and he has to walk you through how to compile it because it’s not immediately obvious. You can tell the lack of experience and expertise because they took over the allocated time to produce something that isn’t usable, so this is a non-hire, immediately.
See how “12 hours” can mean two completely different things? Time is simply not a factor when trying to hire someone to accomplish a task. It’s the deliverable both in the code/quality and in the interviewer’s ability to plan out the next steps for it.
This candidates’ code is a mess, as others developers might call it a shit-storm or spaghetti-code. It has no inline-comments, no documentation. It will never be able to be reused, there are no libraries, maybe even no classes, neither individually nor any sub-aspect of it. They don’t follow any best practices and create a lot of tech debt. This person could be a very skilled hacker-type or simply a newbie, either is possible but neither are desirable for hiring except as a Junior/Intern that you plan to pay a lot less and train underneath some seniors to improve their code style, skill, mentality, and approach. Most of us start here and from my experience, some developers don’t get out of this phase. The thing that kills developers like this is their EGO, they believe that they know better and refuse to code any other way.
He/she absolutely kicks ass (this is me, by the way) and cranks out a functional prototype of this program in record time, probably in less than 3 hours, to be honest, the candidate probably finishes in like an hour, but then spends some time reviewing their code, cleaning it up, adding some comments and placeholders for pulling things out for re-use when time permits to restructure it. This candidate makes this code to work, but with very clear plans for the future of its use and already has some ideas of possible adaptations for this code and aspects of it to be re-used. When they turn it into you, they can walk you through their process, their code, in detail, they are passionate about it and can explain to you what would be next. They probably put a rudimentary README in place for absolute idiots and posterity and structured the codebase well, and they probably have some helper script(s) to compile the code. But this candidate didn’t waste an extra 9 hours for an “interview” or whatever. They fit into the time constraints and this is, by far, your best immediate hire compared to all other interviewers referenced here. This person can manage their time, deliverables, expectations, and still architect massive systems if enabled properly.
This candidate interviews extremely well, and is filled with confidence. What they turned in is actually really good for 3 hours, on-par with the candidate above, but when you go to ask them to talk about the code, they stumble and try to use their charm, and charisma to avoid hard technical questions. This is hard to catch especially if you don’t have any technical experience yourself. If you are a good interviewer with technical experience, you should be able to figure out that they didn’t program this, they found their developer friend or used an internet site to hire someone to program this for them. You should be able to ask them something specific to the project/codebase that a clever “good interviewer” type can’t weasel out of as easily. This also is an immediate non-hire (hire the person that actually wrote the code), but this requires a good interviewer to find out, and often 2–3 interviews to figure out that this person is simply a great people person but not a solid engineer.
In conclusion, there are many different types of candidates that you will run into when hiring the perfect engineer that fits your team and culture. I prefer passion and experience than someone that looks good on paper as my personal preference. I have a lot of love for software development but an even bigger passion for building high performing teams that can get the project done in record time. I hope this article helps solve the problem of which programmer to hire for your team/project.
You will never miss my podcast, latest news, etc.
