What I Learnt About Hiring

  1. Hiring takes a loooong time: at one time, it took me as much as six months from the day of posting the job to the time someone joined. And engineers then take six months to become fully productive. This is a total of one year from the day you decide to hire to the day the engineer is fully ramped up! Ignore the exaggerations about hitting the ground running. I can’t, and most people I’ve seen can’t. Accept it, and plan for it.
  2. A company should have at least 3 engineers, so that product development doesn’t come to a halt if two people leave.
  3. Every person should ideally add skills to the team, to do something nobody else in the team can. Ideally, they shouldn’t just be hired to do work.
  4. If you need an iOS engineer, for example, don’t hire one who doesn’t know iOS. It takes a quarter to learn iOS, delaying your product development and adding to your costs. And he may then leave, incurring the cost of ramping up but not giving you any reward for it, wasting a lot of your time and money. Similarly, if you need a backend engineer, don’t hire an iOS engineer. You can make an exception if the candidate agrees to a significant pay cut for the first three months. If you offer this, most candidates will refuse, which is good for both sides.
  5. You don’t need to be so rigid within a certain area like backend: if you use Rails, and someone knows Django well, that’s not enough of a reason by itself to reject the candidate.
  6. Hiring is a compromise: you can’t have everything you want. So be clear what to insist on and what to compromise on.
  7. The most important qualification for a candidate is that he wants the job. For example, candidates who’ve solved the problem we ask them to solve are far more responsive than those who haven’t.
  8. This means inbound. Outbound recruiting has a very low success rate and should be done only if you have lots of time on your hands or a dedicated recruiter.
  9. Hiring is a funnel — eliminate bad candidates as soon as possible. For example, I ask a question in an in-person interview that eliminates a lot of candidates. But I’ve already spent a couple of hours on the candidate by that point, which goes waste. I wanted to ask it on phone, but it was too complex. So I came up with a simplified version of the question which I ask on the phone and reject people early. This is an example of the general principle: always be looking to optimise your process like this, just as a factory tries to reduce waste. The more effective a question is at eliminating candidates, the earlier you should ask it. My best question eliminates 90–95% of iOS engineers. So I ask it first, ending the interview in as little as four minutes if he fails. You can spend 4 hours on the 1% of candidates who’re good, but not on each candidate.
  10. A good question shouldn’t a) require too much context, since explaining that takes up time and a misunderstanding there can derail the answer for no fault of the candidate b) reject everyone c) pass everyone d) make everyone give more or less the same answer e) make people give vague answers, because you can’t say for sure that it’s a wrong answer and so reject him. In all these cases, you’re not accomplishing the goal of separating the hires from the no hires. A good question is a sieve, and the above kinds of questions are a sieve with a huge hole in it.
  11. Ask hard questions that separate out the great from the okay people, not easy questions that don’t let you separate them.
  12. Identify questions that are common to all engineers on a platform, irrespective of what they’re building. For example, if an iOS engineer doesn’t know memory management, I wouldn’t hire him. But not knowing how to process images using Core Image doesn’t mean someone is not a good iOS engineer.
  13. Don’t reject people for not knowing things you don’t use in practice. If you’re building a CRUD app, don’t reject people for not knowing the time complexity of sorting. You’re not Google, so don’t cargo-cult them.
  14. Delegate a good part of the hiring to junior people in your team, to save your time. Certainly the first round of interview, the phone interview.
  15. If you’re not sure about a person, let him continue till the last round.
  16. Note down a list of questions for each profile (iOS, backend, etc), ask these in the phone interview, and eliminate 90% of people before an onsite interview.
  17. Cover as many areas as possible during the phone interview. Let it go on for 3 hours, with breaks.
  18. Give people a take-home programming exercise like to save your time in the onsite interview. It shouldn’t take much more than an hour and a half, because good candidates will refuse to do it. Link this from your job posting.
  19. Some people talk very well but can’t code, so check that.
  20. If people plagiarise, reject them immediately. This could be Googling answers to questions. Or getting their friend to solve a take-home exercise. Detect this by asking questions on the code that was sent in, to make sure he knows it well. Don’t work with people who have integrity issues. I did once, and it backfired.
  21. Ask the same question to 100 people, so that you have a very good idea of what’s average, what’s terrible, what’s good but not great, and what’s spectacular. For example, when asked about memory consumption, only a few candidates out of perhaps 1000 distinguish between peak memory use and baseline. So if someone pointed it out, it’s a strong signal. I learnt this only because I looked at a lot of solutions to the same exercise.
  22. Interviews should be collaborative, not combative.
  23. Given that you’re in a position of power over the candidate, even things you say that are not intended as blunt or put-downs can be interpreted that way. So be extra nice, extra friendly, extra respectful.
  24. Don’t give feedback during the interview unless there’s a reason for it, like the candidate feeling diffident. Or if the interview has gone on for more than an hour, a compliment may provide a boost for him to go on. Because giving feedback can affect the course of the rest of the interview. Besides, a good candidate should know roughly how well he’s done.
  25. When you call a candidate for an interview, ask him if it’s a good time to talk, and set expectations like “This can take up to 2 hours. You can take a break any time you want.”
  26. Don’t tell candidates to do things that are good practice anyway. For example, don’t tell them, “I’m looking for code that handles all cases, is readable, well-structured, etc.” Because you want to see who takes care of these without being told. These people are the gems you want to hire.
  27. Junior candidates often give an answer without thinking through. The first time that happens, I tell them, “When I ask a question, take as much time as you want. There’s no penalty for that. But there’s a penalty for giving the wrong answer.” If they still give a wrong answer, and I suspect they haven’t thought it through, I assume they don’t know, and continue with the interview.
  28. Give people plenty of time to answer. Don’t rush them. People are tense to begin with, and rushing them more increases tension even more, which is not a good experience.
  29. Hiring is a two-way process: in addition to the candidate convincing you that he’s good, you need to convince him that you’re a good company to join. I do that only after ensuring a baseline level of skills, to reduce time wastage.
  30. Interviewing has multiple aspects, and you may not be good in all of them. That’s fine as long as you know your limitations and rope in others to cover for them. For example, if you’re not good at reading people, rope in your friends, seasoned managers, to cover for you in that area.
  31. I don’t even read resumes till I’ve validated the candidate’s skills to a reasonable degree. Beyond rejecting obviously unqualified people, like a photographer who applied to a Software Engineer job, resumes are a bunch of lies. People put in all kinds of buzzwords — machine learning, big data, cloud, blah, blah — that they don’t have. Know enough to evaluate skills you don’t have. For example, I don’t know machine learning, but I know one question to ask that exposes the 90% of bullshitters who claim they know ML but don’t.
  32. If a candidate has put a skill on his resume, but can’t answer a basic question, it’s possible he hasn’t worked on it, and is falsely claiming experience with it. If that happens, switch from technical to non-technical questions: when did you work with this technology? In which company? How many people were in the team? What part of the work did you do? And so on. A liar won’t be able to answer these immediately and convincingly. And if someone has lied about even one technology, I’ll reject him immediately, since that’s an integrity issue, towards which I have zero tolerance.
  33. Don’t ask textbook questions like “What’s time complexity?” or questions that can be Googled. Because you won’t learn enough from the answer. And you’re selecting for people who mug stuff up. Instead, select for people who can apply their knowledge to solve a problem. Pose a scenario-based question, a problem to be solved that requires knowledge of time complexity. For example, I ask for an algorithm that operates on an array. When the candidate answers, I ask, “Suppose we change this algorithm to first sort the array. Will it be faster?” A great candidate will say, “No, the existing algorithm is O(N), while sorting is O(N log N), so it will be slower.”
  34. This illustrates another point, which is not to ask direct questions. This goes for non-technical questions as well. For example, don’t ask, “Have you been a tech lead?” Instead ask “In your team, who divides work among the different engineers?” and more questions on the lines of what a lead does.
  35. Don’t ask trick questions, or questions where you either know the answer or don’t.
  36. A person who didn’t know the answer to a question but can work it out from first principles is more impressive than one who already knows the answer. Because you know that the former has a good chance of solving a novel problem that arises after he’s been hired.
  37. Candidates who drop off usually just stop responding. They don’t usually tell you they’re not interested. Give one reminder at most and then forget them.
  38. When multiple people in the company are involved in hiring, they need to agree on a process and follow it. This can be what steps there are in the process, where information is recorded, what happens next, etc. Otherwise, you’ll forget to get back to a candidate, or two people will get back to the candidate with contradicting information, creating a bad experience.
  39. The process I’ve used is: candidate applies -> we email him to ask him to solve a take-home exercise -> he sends the solution -> phone interview -> onsite (or VC if remote) interview -> sell the job -> offer.
  40. Note that we don’t even talk to them on the phone — let alone in person or videoconference — till he solves the problem. This saves us a lot of time, and weeds out candidates who’re not serious, at the cost of losing some smart candidates. Who are the ones who have multiple options and won’t do a take-home exercise. That’s a conscious tradeoff I’ve made.
  41. Hiring has conflicting goals — you don’t want to waste time on unqualified people, but at the same time, you don’t want to turn away great people who don’t want to waste time on a company till they know it’s good. This is a tradeoff. You can choose one or the other, but you need to recognise that there’s a tradeoff.
  42. This is why it’s better to hire before it becomes a dire need. If you wait till it does, you’ll have to waste more time on the process, and compromise in other ways like salary and attitude.
  43. Know what advantages your job offers and pitch them. This should be in the form of telling the candidate how this will further their goals. People care about their goals, not about you. For example I ask, “where do you want to be 5 years from now?” If the candidate says “Start a startup”, I say, “In that case, you should plan and work towards that goal from now. If you join an early-stage startup, like 3 people in our case, you will have the maximum learning. You’ll know how to build a great product quickly. You’ll learn how to talk to users. You’ll learn how to hire. And so on. All this puts you in a good position later on.” If he doesn’t answer the question of where he wants to be 5 years from now, I ask more questions like “Do you want to start a startup?” If he says no, I ask, “Do you want to be a CTO?” At this point most candidates say yes, at which point the above pitch comes in.
  44. If a candidate says he can’t join in a month, don’t wait, because they’ll shop around your offer. In such cases say, “I’m sorry, but I can’t wait that long. You can call me after two months, as you said, and if the job is still vacant, I’ll be more than happy to hire you, but I can’t guarantee it.”
  45. Don’t hire people who come for money. It shouldn’t be an auction where the highest bidder ones. If someone gives you that feeling, don’t hire him. You want people who are coming for the right reasons. You want to pay them a fair salary, but they shouldn’t be coming for the money.
  46. Give everyone a profit share or stake to retain them.
  47. Have a shared account jobs@mycompany.com that multiple people know the password to and can collaborate on the hiring process. Don’t use one person’s email ID like kartick@mycompany.com
  48. Use an ATS or spreadsheet to track who is at what stage. At an early stage, a spreadsheet is fine, but you need at least that, or the process descends into chaos.
  49. When you hire, give people both personal and company milestones. For example, our first goal is to launch feature X, then Y, then improve UX. This is at the company level.
  50. Also give people personal goals over different timeframes: It could be: “In a quarter, you’ll be a fully productive member of our team. You’ll know how we work, how we plan, how we communicate, and you work effectively as part of the team. In two years, you’ll be able to manage your own work without me having to do it every week. I’ll be able to tell you to launch this feature, and you’ll be able to figure out what the intermediate milestones are, estimate, track progress, handle dependencies, execute and keep the rest of the team updated. In three years, you’ll be able to lead other people are well.”
  51. Unless you have product-market fit, don’t hire a UX designer. A professional designer gets you from 95 to 100. But that’s premature unless you’re at 95. A software engineer with a good sense of design can get you from 0 to 95. Design is important, but needn’t be done by a designer. In fact, designers come with a lot of overhead. They look at everything solely from a user’s point of view, without considering technical feasiblity, or when we want to launch, and without regard to overall team priorities or milestones. They think and work in a waterfall way. As a concrete example, one designer I worked with designed an animation that took 3 person-days to implement. This wasn’t a good use of engineering time since we had a lot more important things to do. It was like polishing the steering wheel of a car whose brakes are not effective. Quite a few designers aren’t T-shaped and don’t focus enough on the big picture, just their part of it, which makes collaboration harder. I’m not saying designers don’t add value, just that the value they add comes at a significant cost that’s not worth paying before you have product-market fit.
  52. Don’t hire people who are part-time, temporary or freelancing (whom I’ll collectively refer to as part-time from now on). For two reasons: one is that there’s a lot of fixed overhead communication, coordination, aligning people, building a relationship… With part-time, I paid this overhead but didn’t get enough in return. It has often been a net loss. We can make an exception for specific, well-defined tasks like designing an app icon that can be compartmentalised. Not for, say, designing the UX of the app, which requires very close interactions with eng and product. I have found it more efficient to design the UX myself, though I’m less skilled at UX than a professional designer. The other reason why I wouldn’t hire part-timers or temps is that there’s a lot of work in every area. If it’s worth hiring, it’s worth hiring full-time. Part-time is neither here nor there.
  53. In particular, don’t work with someone who has a full-time job and is working with you on the side, because their real job will be their priority, no matter what they tell you. They may be well-intentioned, but when push comes to shove, their job will take priority. There are, of course, exceptions, people who do a stellar job on the side, but in general, getting someone on board is a huge investment in time and opportunity cost, not just money, and I’ve generally found this investment wasted when working with people who have another full-time job.
  54. If you’re about to start a startup, don’t. Instead join one of the dozens of founders looking for someone with complementary skills. Why? In theory, you can start a startup and hire for the missing skill, but, if you’re a techie, people with a proven track record in marketing (say) have a lot of more promising startups courting them. So they’ll pick an idea that’s more interesting, or better funded, or paying a higher salary, or doesn’t suffer from whatever other drawbacks you have. If you want to hire such a person as an employee, you won’t be able to afford them, and hiring a cofounder is even harder. I couldn’t find one in three years, nor could many of the startups I worked with. So, if you start a startup, you might very well end up with a missing critical skill, being like a one-legged person. Instead, team up with someone with complementary skills, so that you have a potent startup. That may not exactly be the idea you want to work on, but the idea is only 1% of the startup as a whole. So don’t overweight it. Now, you can still find a startup in a sector that appeals to you, like fin-tech. If you have a general theme that motivates you, like empowering people, you could choose to work on an edu-tech startup, for example. So, whatever general themes motivate you, you can find a startup or founder aligned with them, and join forces with them.

--

--

--

Consulting CTO. Earlier: Google | Founder | CTO | Advisor

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Why Music Performance Majors Need a Backup Plan

Making The Most Of Your Intership

Soul Desire at www.souldesire.co.uk — All About entertainment for wedding kent

3 Ways to Create a Compelling Career Transition

Make Writing Your Life!

What is it like to work at LinHart?

Real life equals real ramifications

Analytic Buyer’s Guide — Technology

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kartick Vaddadi

Kartick Vaddadi

Consulting CTO. Earlier: Google | Founder | CTO | Advisor

More from Medium

Confessions of a Job Seeker

We Need To Talk About Entry-Level Jobs

How to Find a Job as an Australian Student in 2022

Dior women AW2022 : In an effort for tradition to embrace the future