Tech Anti-Interviewing
A conversation I had with the co-founder and CTO of a tech startup at Factory Berlin recently prompted me to write about my approach to interviewing technical candidates and also on how I approach these types of interviews myself. The TL;DR is this:
‘How to avoid tech interviews as we know them’
Tech Interviewing Is Broken
Many articles have been written about why the technical interview process is fundamentally broken (because it’s exclusive, elitist, dehumanizing, etc…) and, based my own experience, I would agree. For example, the dreaded whiteboard coding algorithm test interviews, in particular, have screened out many a qualified candidate — including me (multiple times, in fact, from Big Company X). The last interview concluded with the unfortunate, but sadly predictable, “since you are not technical….”
Fortunately, I have long understood my own skill set and work accordingly. I define ‘being technical’ as being curious and teachable, as do others.
All too often, however, I have seen the impact of this limiting mindset. Here’s just one example…after a recent Computer Science graduate, who had interned at Company Y ‘failed’ her white board interview for a full-time role there, she was told ‘don’t worry won’t we’ll find some thing that is not technical here for you.’ She reached out to me and was literally despondent, saying she was going to have to ‘find a completely different industry.’
What is she doing today? After three promotions in two years, she’s dev lead at a major Company Z. When Company Y took notice and reached out to recruit her, she told them, “I am not interested in working with your company.”
So what can you do if you need to hire technical people? First, consider the type of actual technical work you want them to do. Will they be coding alone? with a team? with developers? with DevOps people? Who will they be interacting with — external customers? other teams? etc…
Attempting to evaluate the type of skills needed to do the actual work (rather than some arbitrary algorithm puzzle) is a key part of to finding a more effective approach to finding top technical talent who will be successful in your company.
Another critical aspect is around the human side of coding — summarized as ‘how do they communicate and learn?’. I’ll use a client story to illustrate.
Startup A had the typical problem of ‘too much work’ and ‘not enough people’. Here’s our conversation:
Me: “What is your hiring process?”
Them: “Well, we’ve interviewed a few candidates, but no one passes our tests. But, mostly no one is even talking to us about working here. Bottom line, we don’t have time to do this.”
Me: “So you don’t have any effective method to find, evaluate and select candidates then? I would suggest me doing ‘interview-as-a-service’.”
Here’s what I did:
a) talked to every person on the existing team to ask ‘do you know anyone interested in technical work here?’ and, importantly, ‘are YOU interested in doing technical work?’
a) gathered names/emails of any interested candidates
b) mass emailed all of them with the following information:
“We have jobs, you have interest. Here’s the next step — fill in any one of these 15 minute Skype call time slots. Expect to show me some code you like, if you wrote it, even better. In our time together, I’ll ask you to take me through the code.”
The interest list of over 100 people quickly filtered itself. It was easy to see which candidate(s)could read and follow directions. Which ones sent me clarifying questions? Which ones used the calendar to schedule a call?
During the actual 15 minute video chat calls, further filtering was quick to do via consideration of their answers when asked questions—
- Who was comfortable talking about code?
- What type of code did they show?
- Had they written the code? Had a team written it?
- Did they run the code during our interview or just talk about it?
- What did they say when I asked ‘what part of this code is good and why’?
- What did they say when I asked ‘how would you improve this code’?
- How did they respond if I asked them a technical question they couldn’t answer?
- What did they say if I said, “I don’t understand x technical concept (included in their code)?”
It was EASY to find the people to hire using this process. For this engagement, I recommended hiring two developers based on attributes DEMONSTRATED during the interview. These attributes included the ability to clearly explain code (irrespective of my knowledge of the coding language), ability to communicate (including listening and asking clarifying questions), etc…
Interestingly, a fair number of candidates tried to ‘go around’ this unconventional interview process. Some wanted to read me their resume or write code live (to fix the bad code they found). Some were painfully uncomfortable talking about code, and some, sadly, talking about anything at all. A large number of candidates didn’t or hadn’t run the code they discussed — preferring to ‘run it in their head’. When I asked, “How do you know what this code does?” the MAJORITY of candidates answered with some version of “I am not exactly certain.”
What happened with the two developers we hired? One is still at the startup (several years later) and is leading the dev team; the other one stayed for a year (made significant contributions to the work there) and then left for other opportunities.
How to Find Great Developer Candidates?
Work on code WITH people.
I regularly judge or mentor hackathons, because it’s fun, it’s meaningful way of giving back AND I meet great developers. Over the past several years, I’ve hired a number of outstanding hackathon participants as subcontractors.
See this post about what my hiring process looks like. I am happy to say that ALL of the recent subcontractors who started with me as interns have subsequently got ‘real jobs’, mostly in Silicon Valley.
Combining their fresh Computer Science and Data Science skills with my real world (mostly DevOps and Cloud) experience not only produced great value for MY customers, but also supplemented their skills, so that they could get full-time jobs easily — ironically, sometimes, by passing the traditional interview process. They had more confidence, because they built ‘real working software’ with me and the rest of my team.
What is the 25% Life?
For many years, I’ve allocated at least 25% of my own work time to learning and/or technical volunteering. This approach has not only enabled me to keep my technical skills up-to-date, but also has connected with me a number of great people — some of whom became my clients.
The “I’ll do it for free first” approach definitely works as an alternative to taking part in technical interviews — besides, it’s offset by the fact that I don’t spend any time or money on traditional client acquisition methods for my consultancy.
So, what does this exactly look like?
Here are a few of examples from over the years in my professional life…
1. Data Mining — developed subscriber (classification) models for the a local Philharmonic Orchestra. Results — they were able to target their subscriber marketing more successfully and I was able to subsequently build data mining models for other (billable) clients. YEARS 2005–2006
2. Relational Database — created a relational database schema, cleaned and loaded data into a SQL Server database for an Education non-profit. Set up database backups and maintenance jobs. Results — they no longer ‘lost’ subscriber data, previously stored in Excel on laptops. I was subsequently able to bill clients (including Microsoft) for similar work. YEARS 2006–2007
3. Data Warehouse — build a data warehouse schema for national health records for Zambia. Train DW administrators. Train users to use Excel pivot tables as a Data Warehouse client. Results — Ministry of Health using aggregate data to improve quality of care in the country. I gained many DW clients subsequently. YEARS 2007–2011
4. Code Library — work on a an open source code library (TKP Java) with a group of volunteers and also end-users (school teachers). Write and refactor code, document code, write library/IDE installation procedures. Results — library is used in 16 US states & 10+ countries to teach kids to code. I have worked on code bases in Scala, Ruby, Python and more for clients. YEARS 2010–2018
5. Genomics Data Pipelines — advise to improve performance on two genomics cloud data analysis pipelines for CSIRO Bioinformatics. Results 70–80% speed up in execution times on the public cloud. I have subsequently worked with other bioinformatics clients on similar projects. YEARS 2017-present.
After many years of the ‘Learn | Build | Teach’ cycle (which is another way to describe working via 25% time, I no longer have to do any sort of marketing to get clients for my consulting business. In fact, I regularly hand off potential clients to other technical consultancies, because I am now working only on projects that interest me.
Keep Learning
I wrote this piece, because sharing what’s worked for me around technical anti-interviewing seems to have positively impacted a number of people with whom I’ve talked about this topic. I’d be interested in knowing, what works for you — share in comments please.
