Culture Canaries - The Interview Coding Challenge

12 Jun 2016

An allusion to caged canaries (birds) that miners would carry down into the mine tunnels with them. If dangerous gases such as carbon monoxide collected in the mine, the gases would kill the canary before killing the miners, thus providing a warning to exit the tunnels immediately.

https://en.wiktionary.org/wiki/canary_in_a_coal_mine

Writing or talking about code during the interview process, a step of the “Joel Test”, is considered good practice. There are many descriptive accounts of job search ordeals involving some code assignment task to be completed under our own time and initiative.

Let us turn it around and look at “home-alone” code challenges as a cultural indicator for the companies internal organisation and preconceptions.

recapture

If the code challenge is just viewed as a CAPTURE[1], it’s your job to prove you are more than just dark matter of unknown provenance.

Some believe in a data driven process so that interviewees can be algorithmically processed.

Like a thundering herd, eventually one will succeed and thus validate an arduous hiring process. See! Our process works. Only the strong survived.

One elaborate coding challenge cannot address all contradictions about real people.

People may not have a lot of real experience, but are good at building skills. Not all people have or want to put out blog posts or have public source code, but have a variety of projects. People with or without a computer science background. People new to software development but experienced in life. People at all points in between.

For most development jobs there are a lot more people capable of performing the work than a typical job spec would imply. From the stackoverflow 2016 survey over half of developers identify with being self-taught.

One good aspect of asking for code in interviews; when people write code they can’t help create something unique and it can provide the basis of further conversation.

Ultimately the interview is a two way process to discover if people will have a positive impact after we hire them and the company will provide a positive impact too.

Improvements companies can make

First up, internally and externally, is the interview process documented?

Have team members been hired already using the process or has it been invented afterwards and is needed to handle scaling of new hiring?

Do the profiles of existing team members pass the interview process?

Create new opportunities when the profiles are too rigid.

Reach out to people for interview who may not be initially confident or think they have enough relevant experience.

Typically, job descriptions get over stuffed and are more aspirational than realistic - worse contain nonsense word salads “agile squads of cross-functional teams” and even create the opposite impression than intended - rigidity.

Don’t include “fullstack ninja rock-star” style terminology where language in your job post influences the gender of your hires.

State in the job description that for example, people with more than half of the requirements are welcome to apply.

Change the assumptions and ask if the company is good enough for the person applying. Why would they work here?

Interviews are like an on-boarding process for employees who are in another timezone - one that has yet to occur.

The hot doughnuts light for hiring should always be on. Companies can add all their job specs into GitHub, rather than the corporate careers portal, for a quick open source win. When someone who has enough interest stops by, interview them.

Blind hiring is also a problem if the company is also blind to what it is asking for; these are the things we know that we don’t know or what we do not like to know.

If companies treat people without empathy during recruitment what does it say about working there?

Just like canaries exposed to harmful gases, the code challenge can provide a useful warning for interviewees to exit stage left immediately.

To improve better tech interviews - we deserve better tech companies.