This story is unavailable.

If you don’t have time to learn who your candidates are (as people), then you should not be conducting interviews of any kind. Hiring is a human process. You can certainly apply the scientific method in your analysis of a candidate’s aptitude for a position, but it requires establishing a basis on which to analyze the candidate in the first place.

Placing a challenge before the candidate is a valid way to assess technical knowledge, but it’s absurd to do so in an in-person interview. A developer is not required to orate their architecture decisions to a superior without prior research, and yet this is the task placed before you choose as a grounds of assessing their ability. Demanding regurgitation of memorized answers to arbitrary domain knowledge questions fails to even acknowledge that problem solving is a skill separate from the ability to apply existing knowledge.

Instead of demanding that your candidates answer algorithm questions in a time-constrained setting, give them a take-home challenge. If you’re good at your job, you’ll put in the effort to design a challenge that can be used to assess not only the candidate’s ability to program, but also their ability to problem solve and follow directions.

Assess based on the real challenges faced in the workplace, not background knowledge that can be easily recited from wikipedia. If you’re focussing on the latter, all you’re doing is screening. That’s failing to follow directions.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.