How To Hire Programmers
Tags: webdev, career, hiring, programming
Published: 2022-02-20 20:43:05

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:
<br/>

> 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??

<br/>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&trade;.

[**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??
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bxyhaqrkgi1pehljgbrt.jpg)
## 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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/spb4h8780k71r6cpqwii.jpg)
## 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.

1. 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_. 

1. 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_.

1. 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.

1. 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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y4qzr1e618isy9iin48a.jpg)
## 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.

1. 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_.

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

1. 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.

1. 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_.

1. 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.

1. 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.

1. 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.

1. 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_.

1. 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_???
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xquk2ai6ocu8a719kvr0.jpg)
## 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.
<br/>

> **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.)
<br/>

> **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.
<br/>

> **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_.
<br/>

> **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.
<br/>

> **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..._
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/is29915tgs1vpusosvdr.png)
## 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.