What I learnt about hiring
I have been the CTO of Affectv for 3 years now. During this time, we have grown from 3 to 40 people, more than doubling our Engineering team in the last eight months. In the next six months, I would like to double this number again. I have made mistakes, learnt from them and avoided some. This is a compilation of some of the things I learnt.
Writing the job spec
This is by far the most important stage of the hiring process. When I wrote my first job spec, I didn’t do a very good job. It looked exactly like the other job specs out there, listing a bunch of skills that I was looking for.
I only considered what I wanted the candidate to do right now. I didn’t consider projects changing, what the candidate’s role would grow into and what exactly the candidate would be responsible for. Understanding what it is you need the candidate to do now, then in six months’ time and even in a year’s time goes a long way in defining the rest of the interview process.
Take the time to write that down. You will realise you have made assumptions on the skillsets you require, or you aren’t clear on what the role will become once the “project” is over. And once you have clarity on the role, you will be able to better assess a candidates’ CVs and also articulate it during the interview process.
Very often, the job spec is the first thing candidates see – whether they are actively looking or have been approached by a headhunter. This is the first glimpse of your company. This is where you set the stage. What kind of company are you? Are you a fun place to work at? Is there something that sets you apart from other companies? Are there any special benefits that you offer?
I use the job spec to sell my company. I use it to sell the role. And most importantly, use it to tell candidates exactly what I am looking for.
I use the following format on a Job Spec. I believe it is concise and gives a good idea of the company and the role.
- About the company - This is where I describe what we do, what makes us different and some of the challenging problems we are attempting to solve.
- About the role - Here, I describe the role. What do I expect this person to do? Who will they report to? Which teams will they interact with? Will they manage a team? If so, what kind of team will they manage (Front-end, Backend, Sales, …)
- Responsibilities - And lastly, I list the person’s responsibilities. Will they be responsible for a set of projects? A team? For creating reports? For PnL?
Most CTOs I have spoken to have a love-hate relationship with recruiters. When I began recruiting for the first time, working with recruiters was quite hard. They were necessary to cast a wide net, but the logistics of dealing with them drove me up the wall. I would be sent a hundred CVs a day (across 5 recruitment agencies) and would be called incessantly regarding those. From looking at the CVs coming in, it was obvious that the recruiters had a limited understanding of the job spec and the kind of candidates I was looking for.
Something was seriously wrong. Surely, filtering candidates was their job, wasn’t it? Why was I spending over half of my day going through CVs and rejecting 98% of them? It was time to change things. I got in touch with more recruiters, spoke at length with them on the phone or in meetings, explained what I was looking for and made it clear that if I started rejecting more than 50% of the CVs, I would not be working with them anymore. I asked them to come back with any questions that they had in a week’s time, after which I would not be clarifying the job requirements.
During these conversations, I had interesting reactions – some recruiters were quite offended. This wasn’t the way they worked with other companies! They had to send me lots of CVs because “you might miss some good candidates!” And then, other recruiters weren’t. They were patient, asked intelligent questions and understood that I couldn’t allocate so much of my time to recruiting, and that it was better to send a select few CVs. They were the ones I wanted to work with.
Over the course of a few weeks, I narrowed down the number of recruiters to two. I created a process – CVs would come in on Monday and Wednesday mornings and I would respond on Wednesday and Friday afternoons. Interviews would be set for Tuesdays and Thursdays the following week.
This system worked wonderfully for me. I wasn’t interrupted throughout the day and expectations were managed across recruiters and candidates. I have continued working with these two recruiters (even after they changed agencies) and will do so in the future.
When it came to technical candidates (developers and scientists), the process was a little different. I introduced a test as a filter and only considered the CVs of candidates who passed the test criteria. It made filtering candidates so much easier! I will describe this in the next section.
When you have a new job spec, take time to explain the requirements to your recruiter. When they come back with CVs, tell them why you liked some and why you discarded the ones you did. Good recruiters will understand what you are looking for and will start sending you more relevant CVs.
Another thing I strongly suggest you do is follow up on how the recruiter communicates with candidates. This means
- Follow up on the job spec document that they send candidates. Recruiters create their own version of the job spec before sending it to candidates. This is done to hide the name of the company to make it hard for the candidate to apply directly without going via a recruiter. Please ensure this document portrays your company and the job spec in the way you intended it to!
- Follow up with the recruiters on where they post on the internet. Again, the above point applies.
The recruitment process
Based on my previous experience, I had a fairly good handle on what the technical part of the recruitment process was going to be like. I was hiring technical candidates, and it is easy to test their skills through a structured interview. At Affectv, I created the following interview stages which we currently use,
The email test
The first stage in the interview process is a programming test. It is a homework assignment consisting of a few non-trivial problems. The problems are very close to what the candidate would be working on at Affectv. The test is not time bound, and the candidate is encouraged to use different approaches and try to optimise the time complexity.
The solutions are sent to an email alias which executes the code against a set of test inputs and returns a score as a response. If the score exceeds the top x percentile of candidates, then the person is called in for a face-to-face interview.
The email test is the first filter we apply. It helps us weed out the people who are not genuinely interested in the role. We don’t look at CVs. We only look at CVs after they have successfully completed the test. Before coming in for an interview, we ask the candidate to list their top 3 skills. Examples of skills for a data scientist could be PCAs or Logistic regressions. If you are hiring an engineer, examples of skills could be a specific programming language, a class of algorithms or knowledge of a library or architecture.
We ask for the top 3 skills as we want to test the candidate in the areas that they are the strongest in. We ask for 3 skills because we may not necessarily be familiar with the candidates’ #1 skill.
Interviews are stressful. They are even more so when the candidate does not know what to expect. I like companies that tell me what the interview structure will be like, who will be doing the interviewing, what their background is and how many rounds of interviews I will have to go through.
Before an interview at Affectv, we inform the candidates about,
- Venue. Phone number to call on in case there is a problem.
- Time and the duration of the interview.
- Dress code.
- A bulleted list of the interview stages.
- Detailed explanation of the current stage:
- What to expect in the interview?
- What you will be tested on?
- Who will be taking the interview?
Interview: Stage 1
Each stage of the interview is a filtering process. For engineers, in stage 1, we test the following areas
- Coding ability - Can the candidate code in the required language? If the job requires it, do they have an in depth knowledge of the language or certain libraries?
- Problem solving - Does the candidate,
- Have the ability to correctly solve the right difficulty of problems?
- Try different approaches to solving a problem?
- Persist on a difficult problem, or does he just give up?
- Previous experience - It’s only after we have vetted #1 and #2 do we get to the CV and ask the candidates questions about their previous experience. Here, we ask questions on what you did and not what we, as a group, did. Some people tend to use “we” more, but after one butts in with, “Sorry, do you mean I or we” a few times, they start using “I” more.
- Top skills - This is where we test the candidate on their top 3 skills. We go in depth and gauge whether they really know what they claim to know.
At any step, if the candidate fails to impress, then the interview is politely concluded. This ensures that we aren’t wasting the candidate’s or our time.
Interview: Stage 2
Stage 2 of the interview process varies with the role. For junior roles, we skip this stage. For more senior roles, they are given a hard problem that we are facing and are given a week to think about it before they back with the solution. They will then present to a small group (usually 3 people) and there will be a QnA afterwards. Examples of the problems could be
- Architect role - How would you architect this system? What modules do you use and why? What technologies do you use and why?
- Product role - How would you manage the lifecycle of this product? SWOT analysis. Roadmap. Skills needed.
Interview: Competency based
The last stage of the interview process is the competency based interview. I get a non-technical person to do the interview as it gives me another perspective on the candidate.
We have broken down competencies into eight categories and have a scoring system with a pass mark against each category. This pass mark varies depending on the level (junior/mid/senior) of the candidate and helps create a common framework across different departments. Besides, the decisions we make aren’t based on emotional responses but are backed by evidence.
It is only after the candidate is successful in all these stages that we make them an offer. It is a long and arduous process, but then, I wouldn’t want it any other way. After all, products don’t build themselves. People do. And hiring the right people is what makes or breaks a business.
I am proud of what we have built here at Affectv. We have an amazing product. One that may fundamentally change the nature of advertising on the Internet. This is all due to the people here. Smart, dedicated and hard working people who thrive on challenges. Who make difficult problems seem a tad easier. Who make me look forward to each day in anticipation.
And that, is truly amazing.
- Revert back quickly after an interview. Inform the candidate or the recruiter of the next steps on the day of the interview. Both will really appreciate this.
- Hire people who are smarter than you. I suppose you have heard of the saying, “A people hire A people, B people hire C people”. You want people who are better than you so that they can take things off your hands and solve problems that you may not be able to solve.
- Do not go for smarts only. Also look at how well balanced they are. I know smart people are notoriously hard to find, but beware of individual idiosyncrasies. It will affect the rest of your team.
- Hire for complementary skills. If you have a person who is amazing at something, it makes more sense to hire someone who fills in the shortfalls.
- Your time is important. Come up with a process to quickly eliminate the wrong candidates.
- Jacks over Kings. During the initial stages at a startup, generalists are more valuable than specialists.