My regular readers (both of them) know that hiring and developer evaluation are some of my favorite topics. Or perhaps more accurately, they are two of my biggest pet peeves. In my (angry, annoyed, agitated) opinion, soooooo much of how we evaluate talent is fundamentally and critically broken.

Due to this agitation, I've already written tomes on this site about everything that I think is wrong. But some thoughtful commenters on past articles have flipped the equation back on me:

If these are all the things that you feel are "broken", what exactly would you contend is the "right" way to go about evaluating potential hires??

It's a fair challenge. After all, it's easy to sit on the sidelines and gripe about everything you don't like. It's quite another to present a meaningful, actionable plan on how to make it better. So here you have it: The patented Adam Nathaniel Davis Programmer Hiring Plan™.

[HINT: It's not nearly as difficult or as convoluted as so many companies-and-hiring-managers make it out to be.]

I'm not going to get into how you find programming candidates. I'm not a recruiter. From my perspective, quality candidates are dang-near everywhere. But then again, my perspective from within the career field is undoubtedly a bit... biased. I'll just assume that you can find a pile of candidates. But how do you know which one deserves an offer??

The Non-Technical Phone/Video Screen

I feel like this has become a fairly-standard first-step in most hiring processes. And quite frankly, I don't have any real problem with it. So if your organization wants to follow this model, I get it. Some non-techie type calls Candidate to do some really basic, really high-level scoping-out. It should be painless, simple, and brief - 30 minutes max.

It seems to me that the primary goal in these calls is usually to understand the Candidate's salary expectations. And many candidates are dumb enough to spit this out in the first call. (NOTE: This is definitely the subject of a future article.)

My only critique of the initial screening call is that, beyond the desire to discover salary expectations, I'm really not sure what else the Candidate can do on these calls to get eliminated. When I'm on one of these calls myself, it often seems that I'll be forwarded to a second interview even if I tell the screener that I have to cut the call short because I'm flaying someone alive in the basement and their screams are making it hard for me to hear the questions.

I do think there can be value on these calls - for both parties - if there are any aspects of the role that are, in any way, unique or non-standard. For example, if you're calling someone in Poland, but the job would require relocation to Bolivia, then it makes sense to start with the non-technical screening. No need to waste everyone's time if the "opportunity" is a complete non-starter for the Candidate.

This is also a good place to address any obvious high-level mismatches between the opportunity and the Candidate's CV. For example, maybe he has a mix of BA roles and coding roles on his resume, but you're hiring for a pure coding position. Is the Candidate open to this condition?

Although this screening is typically simple and difficult to "screw up" (for either party), there are a few habits I've seen from non-tech screeners that I find annoying AF.

For example, I don't know how many times I've had a scenario like this: A recruiter pings me and says, "Here are the details about a role with XYZ Corp. Can I submit your resume?" I agree and a technical screening will soon be scheduled, but the remainder of the conversation in the initial call goes something like this:

Screener: So how did you hear about XYZ Corp?
Me: A recruiter pinged me on LinkedIn. [The mere fact that I have to state this always strikes me as borderline-silly. I mean, nearly every opportunity that I care to pursue starts with... a recruiter pinging me. On LinkedIn.]

Screener: I see. Well, what do you know about XYZ Corp?
Me: I know that your recruiter pinged me on LinkedIn, which led to this call.

Screener: [facetious laughter] Oh, sure. OK. But... what makes you want to work for XYZ Corp?
Me: I have no idea if I want to work for XYZ Corp. You called me.

Screener: [more facetious laughter]
Me: Look, I gotta go. I'm flaying someone alive in the basement, and the screams are making it difficult to hear your questions.

The Technical Phone/Video Screen

This is also a fairly-standard aspect of many companies' hiring processes. And I don't necessarily have a problem with it. In fact, in some instances it can provide real value. But there are some significant "gotchas" here that I really need you to understand:

1. This should never be done in-person. I don't care if you're hiring for a strictly onsite role. There's still nothing in the technical screen that can't be handled effectively and efficiently in a phone/video call. Save your own time - and respect the Candidate's time - by making this a purely-remote aspect of the process.

2. Like the non-technical screen, this call should never exceed 30 minutes. The point of the call should not be to have the Candidate give you a 30-minute soliloquy about his entire CV. Nor should it be to delve deep into every corner of his technical knowledge. It should just be to ensure that the Candidate can speak "programmer-ese". If you can't complete this call in a half hour, you're doing it wrong.

3. This call should be to test the Candidate's knowledge of general concepts. Yes, those concepts will be "technical" - but they should still be high-level. Focus more on languages (e.g., JavaScript) rather than frameworks (e.g., React). Better yet, focus on even broader concepts (e.g., principles of web development). Do not get cute by trying to quiz someone on, say, the default parameters of some language's particular built-in function. Do not ask "gotcha" questions (e.g., "A null evaluates to what type in JavaScript?"). The goal here should not be to stump someone on esoteric concepts. The goal should be to verify that the Candidate is, indeed, a programmer with at least a basic grasp of key concepts. If you're quizzing the Candidate about the difference between the Function constructor versus a function declaration, you're doing it wrong.

4. Agree on the questions to be used in this screening, and give the same questions to every Candidate. This is one of my pet peeves. Joe performs some of your tech screenings, and he asks softball questions. Mary performs some of your other screenings, and she asks hardball "gotcha" questions. This is poor form and it will skew your evaluations.

5. Give serious consideration to making this screening conditional - based upon the Candidate's experience. In other words, if you're talking to a 30-year programmer, it's kinda ridiculous to put them through this screening. And yeah... I can already hear some of you screaming that you don't know if a candidate's experience/CV is legit, so that's why you put everyone through the same screening. To this I'd reply: Get over yourself. If someone has truly fabricated their resume, there will still be ample opportunities to expose them. (And NEWSFLASH: such blatant fabrication is pretty rare.) When I'm put through these screenings, it doesn't bother me at all. But it's really a waste of time - for me as much as for the employer. I know this'll sound cocky as hell, but I don't care. I'm gonna say it anyway: If I'm applying for a JavaScript position and I "fail" your 30-minute phone tech screening, it says far more about your tech screening than it does about my skills.
   
   
   

The Coding Assessment

OK... So now we come to the real "meat" of the hiring process: The dreaded, frequently-botched, and rightfully-maligned coding "assessment". Someone has passed your initial non-technical screening, and your technical screening, but now you wanna know if they can really code. So here's what you should do:

[NOTE: With modern tools, this should be every bit as manageable for remote employees/interviews as it is for in-person meetings.
Screensharing and collaborative code tools (e.g., StackBlitz) now make it incredibly simple to watch someone coding in a live setting.]

1. Sit the candidate down at a real, live coding environment. If your interview is in-person, have a workstation already set up. If the interview is done remotely, just have them share their screen with you as they work. If you have multiple evaluators, ensure that they are all present and able to watch the proceedings.

2. Ask the candidate to begin coding a single, basic app. It can be almost anything. It could be a to-do app, or a tic-tac-toe app, or a battleship app, or... anything. If you need to see the candidate creating a deeply-complicated esoteric feature that will implement live video streaming for your universe of authenticated users, with content controls and dynamic tracking of ad placements, you're doing it wrong.

3. Tell the candidate that they'll only be expected to code for an hour. That's right. One. Single. HOUR. No more.

4. Also tell them that they are not expected to complete the app in this time. If your idea of a coding assessment is to give candidates a task that will take hours to complete, you're being a jerk and you're self-disqualifying your company from considering many highly-skilled, vastly-experienced candidates who simply can't be bothered to burn an entire afternoon working on your demo app.

5. Tell the candidate that they needn't concentrate on minute details of UX. Unless the position is almost-entirely focused on UX, you shouldn't be getting hung up on whether someone has deployed a clean, fancy, responsive, and intuitive <Grid> control. You should be looking for coders.

6. Encourage them to talk through their solution as they're writing it. Any clarification they can add is useful and will make the subsequent question-and-answer session far smoother.

7. Tell them that, while they needn't complete the app, if they want to "stub out" basic functions / components / features that they would normally implement, that's fine. Like, if they would normally implement a wrapper for asynchronous calls, it's perfectly OK if they just "stub out" that functionality without necessarily building it from scratch.

8. Let the candidate code the app in whatever language/framework they prefer. That's right. ANY language/framework. If this sounds ridiculous to you, then you're absolutely not screening for the right "skills". You're looking for people who just happened to have mastered your chosen tech stack. You're not looking for hardcore coders. And you should ABSOLUTELY be looking for hardcode coders.

9. Once the hour is done, have the candidate stop coding. They can keep the solution on-screen. But you should absolutely be respectful of their time and you should not be expecting them to extend their time so they can dot all the i's and cross all the t's.

10. The coding session should be followed by a question-and-answer session with the evaluators. That session should also have a firm time control. Thirty minutes is usually sufficient. But an hour is not egregious. If you really need to talk to them so much longer than an hour, you probably weren't in love with their solution anyway, and it's probably unlikely that you'll consider extending them an offer.

Annnnd... that's it. No, really. That's IT. And right about now, you're having an apoplectic fit, right???

Objections

If you're feeling a little triggered right now, that's okay. Really. I get it. This doesn't match your hiring process and every step in your sanctimonious hiring process is sacrosanct, right? So allow me to cover some of the most frequent whinings I encounter when proposing such a process.

We can't take all that TIME to watch all the candidates code for an hour! And then spend time talking to them afterward!!

So lemme get this straight. You're thinking about offering this person a salary that, in many regions, may be well north of $100k. You're gonna invest countless hours getting this person acclimated to your environment. But you can't put in a few hours, upfront with your team, to actually watch this person code??? Think about that for a minute...

I recently did a "coding challenge" for a potential employer. After coding the solution, all by my lonesome, for several hours, they then had me meet with THREE of their most-senior people to talk through the solution for more than an hour. Then they scheduled a second call, with the same people, to talk through some of the finer details of what I'd written! (FWIW, I was offered the job - but I didn't accept it.)

But this is more time than you realize! We have a LOT of candidates to assess!

Then your pre-screening process is broken. If you wanna see coding assessments from a dozen (or more) candidates, then you either have a ridiculous bounty of unimaginably-qualified candidates, or your pre-screening process needs to be "sharpened" a bit.

Let's just imagine for a moment that you do have a dozen (or more) candidates who all seem to be really strong. I still find it hard to believe that some of those candidates aren't sitting closer to the top of your hierarchy? And if there are some candidates who seem to be more qualified than others, the answer is pretty simple: Interview the strongest candidates first. Then, if for some reason those "top" candidates don't pan out, simply move a little bit further down your list.

This isn't enough time for someone to demonstrate all the skills we need to see in a potential programmer!

Then you need to earnestly question the qualifications of your evaluators. Seriously. Every time I've sat down to code with someone else (or to simply watch them code) for the first time, I've been able to get a pretty accurate read on their skill level. And I usually have that "read" within MINUTES. If you've watched me code for a full hour, and you're still not sure if I'm knowledgeable enough to do the job, then I guarantee that I'm not.

But by forcing candidates to do a coding assessment on their own, we save a lot of time because we can eliminate many candidates before we even need to bother pulling anyone into a live interview/assessment!

Ahh, yes. So you're admitting that you're one of those jerks who thinks it's cool to ask an army of questionably-qualified candidates to do your "take-home assessment" (meaning that you're asking them to do FREE WORK). And when the submission doesn't pass your sniff test, you'll just summarily terminate their candidacy? Without even providing any feedback as to how, exactly, their submission "failed"??

Yeah. Gotcha. I know exactly what kind of employer you are. I have no desire to work for you. And guess what?? There's an ever-growing community out there of extremely-qualified candidates who have already come to the same conclusion.

We can't let people code in "any language/framework that they want" because we need a true apples-to-apples comparison!

So what you're saying is that, if your environment is entirely dependent upon Angular & Node, you don't think there's any way that my kick-butt solution, written in React (oh no!) and C#(egads!), may be at all transferable to your tech stack? If I truly wrote a solid solution in React/C#, do you really think it's gonna take me some ungodly amount of time to "translate" those skills into Angular/Node?? C'mon, mannn...

Trashing the Assessment??

If my previous suggestions have you tearing your clothes and gnashing your teeth, then you're really gonna love this suggestion: Sometimes, you should absolutely consider bypassing the coding assessment altogether!

No, I wouldn't normally suggest trashing your coding assessments altogether. But you should really think about which tasks you're asking of which candidates.

I have a fairly-robust GitHub profile now. It contains the code for live, publicly-accessible apps. It contains the code for all of my NPM modules. It contains the code for numerous other coding assessments. If you have any serious doubts about what I've written (or whether I've written it), that makes total sense. We can just do a live review session of the reams of code that I've already written. I can talk you through any design choices that I made. I can even make small changes for you, in real-time, to demonstrate that I own the code, I thoroughly understand it, and I know how to safely update it.

This probably sounds hella-arrogant. (And I couldn't care less.) But the simple truth is that, if you're asking me to write some new little demo app when I already have tons of live, high-quality code that may even be directly-applicable to your environment, then your "tests" are often rather, well... annoying.

And I can already hear the hiring-manager apologists who are saying things like, "Well, if you can't be bothered to do our coding assessment (which is really just another permutation of stuff that you've publicly-posted many times before), then we don't want to hire you." And that's... great. Seriously. It is. But keep in mind that your hiring process is almost-certainly causing a lot of other extremely-experienced candidates (candidates who already have jobs and don't necessarily need your amazing opportunity) to simply "bow out" of the process altogether.