On hiring - A rapid hiring process for busy startup engineering leaders

Learn a lightweight hiring process to help you quickly hire great engineers with as little overhead as possible.

Image from Pixabay

I was once the Director of Engineering at a startup that was always busy, busy, busy! We had people to help, processes to fix, and product to ship. Every day was a fire or pivot.

Strategically we had some key skills gaps that I needed to close, fast. I knew the only way to do it was to increase the size of our team, but given all of the other things going on, hiring kept falling by the wayside.

Engineering, architecture, management, company strategy, wouldn’t get done if I focused too much time on hiring, and yet hiring was critical in ensuring these things got done effectively long-term.

I needed to find a way to hire that would have both speed and quality in a way that wouldn’t take away from the hundred other responsibilities on my plate.

I decided to implement a lightweight process that would help me achieve my hiring goals with as little friction as possible and without interrupting the rest of my priorities.

This is that process.

This process assumes a few things

Be sure to tweak this process (or throw it out entirely, if appropriate) if your context is not the same.

• You have few resources, whether it be time or money

• You need to do most of the hiring process yourself

Building the pipeline

Efficient hiring is about building a pipeline and getting qualified candidates through that pipeline with as minimal effort as possible.

After doing it for a bit, I saw an immediate pattern: software development. The process of moving a candidate from sourcing to closing felt so close to how an issue goes from ideation to development to delivery that I started treating it like a Kanban-style software project:

The hiring pipeline can be interacted with as a Kanban-style software project.

From my perspective, we had the following stages:

• Sourcing

• Intro Email

• Phone Screen

• Tech Screen (Prompt)

• Tech Screen (Discussion)

• Group Screen

• Decision

• Offer or Rejection

These stages were mapped to status columns, and a candidate was an issue ticket that flowed from stage to stage. An additional element was who was responsible for the next-step:

• Was I supposed to do something? (eg. send an email, schedule an invite)

• Were they supposed to do something? (eg. send us a technical submission)

• Was the next step scheduled scheduled?

This worked really well, especially as I started to involve other developers in the process. By leaving comments and updates on the ticket, it was just as simple as collaborating on an issue would be.

Queue management practices also worked well for the pipeline. Monitoring cycle time and wait time helped me identify pipeline bottlenecks early, allowing me to switch focus as needed.

The candidate only saw 3 of these stages

From the candidate’s perspective, they only had to “prepare” for 3 of the stages:

• Phone Screen

• Tech Screen

• Group Screen

This helped make the process feel lightweight. It also kept things simple and straightforward when I had to explain the hiring process to them. Advertising a hiring process as a “3-step process” was massive in an age where some companies require you to study 6 months just for an interview.

Remember: a snappy and simple process is a competitive advantage. I strove for a 2-week maximum turnaround time from source to decision.

Sourcing — Where do you find developers?

There’s different sources you can draw from when looking for candidates.

Sourcing is the act of finding candidates to bring into your pipeline. There’s a lot of different channels you can use to source, with varying levels of cost, effort, and effectiveness.

I found it the most time-consuming part of the hiring process. I’d spend about 30 minutes to an hour a day sourcing, when I could spare it.

LinkedIn

Low effort, High Value

A couple of LinkedIn posts to your network can draw a significant amount of inbound interest. As someone who has built up a network over time, it was one of my largest sources of candidate leads.

If you don’t have a large network today, I recommend you start building it — it’ll pay off dividends the next time you hire. It’s not just the number of 1st-degree connections that matter, either. Every 1st-degree connection you have expands your 2nd and 3rd-degree reach.

Connect with people, say hello, engage with their posts. Yes, it’s a social network, but it’s actually a useful one.

Referrals

Low Effort, High Value

Referrals from existing employees is another key source of candidates.

We had some talented people on our team, and their recommendations carried weight. I asked the team to recommend people directly, and many took me up on it. It also showed that the team was willing to refer people, which was a positive signal of the culture.

Keep things consistent
Always make sure that referrals go through the same exact process as everyone else, and that anyone who referred someone is not involved in their hiring decision other than to provide some additional data-points and context. This helps prevent nepotism, which can damage organizations.

Be thoughtful about your incentive structure
I’ve seen some disastrous results with companies implementing referral bonuses.

First, remember that all systems can be gamed, and engineers are notorious for knowing how to game things — it’s almost as if it is in our DNA.

Second — referring is a behavior that should already be happening if your team is happy. If you start offering incentives for it, it can potentially cheapen its use as a signal or lead to the opposite of the desired result if it becomes more profitable to refer people than to do work.

Finally— it’s better to offer NO incentive than an incentive that is perceived as too low. Too low an incentive can be misconstrued as insulting and make people feel the referral is not appreciated. Worse, it can also exasperate any existing feelings of under-appreciation, especially if your company already has issues with fair compensation. Given that some companies give referral bonuses north of $3,000 — $5,000, choose wisely before deciding to offer a $25 gift-card.

Recruiters

Moderate Effort, Moderate Value

Having a great recruiter you trust is a blessing that make hiring easier.

I had a couple of external recruiters I had never worked with send me some candidates to test the waters for a more robust relationship, but most were quite low quality and I didn’t pursue this further.

However, if you’re really busy you can have the internal recruiters do the sourcing and meet with them occasionally for calibration sessions where you can review resumes together and highlight what to look for in a candidate. This can help build up their accuracy over time.

They can also manage the scheduling for you, saving precious time and saving you from avoiding administration overheads.

Developer Communities

Moderate Effort, High Value

I’m a member of several groups and meetups dedicated to various software engineering subjects.

I leveraged them extensively to let people know I was hiring. Many of them have mediums dedicated to posting job openings. I would attend meetings and mention we were hiring at the open mic, post job ads in their Slack channels, and even sponsored a meetup or two to drum up interest.

All of this resulted in some great candidates for just a bit of networking.

Hey all!Widget Co. is actively hiring full-time mid-level SEII’s (3+ years) and senior-level SE III’s/SE IV’s (5-7+ years) engineers in Hawaii.We’re a mission-driven company with a single goal: provide every community on the planet with their very own supply of widgets.We’re looking for full-stack capable individuals, with a specialty in either:
* back-end (designing and programming modular subsystems and data models)
* front-end (implementing high-fidelity designs with clean front-end architectures)We don’t do algorithm / puzzle-style interviews. Our tech stack is:
* Ruby on Rails
* AngularJS
* Postgres
* Docker Salary bands are:
* SE II: 110k - 130k
* SE III: 120k - 140k
* SE IV: 130k - 150kplus RSUs, 401k matching, health/dental/vision insurance, flexible hours, etc.If you’re interested, feel free to DM me!

If you don’t have a large professional network, you can start small: attend meetups and join their Slack teams.

Be sure to follow their rules, though — don’t spam if they don’t want you to.

Job postings

Moderate Effort, Low Value

Job postings on boards and career sites were a decent high-volume source, but there was a lot of noise in it.

It also requires you to stay on top of the job description, tweaking it as needed depending on what results you get. Being able to A/B test messages and job descriptions often requires administrative access to the hiring systems, which you might not have. If you’re already busy with a hundred of things, you might not have the bandwidth to do this.

With that said, if you do have an HR system set up effectively, it can be a lifesaver. Systems like Greenhouse and Lever have automatic scheduling, templating, and pipeline management, which can save a lot of time and effort. Working in the same system as your HR team can help cross-departmental coordination quite a lot, and makes it easier to offload sourcing and scheduling activities.

Candidate Marketplaces

High Effort, Moderate Value

Platforms like Vettery and Hired had a lot of candidates to choose from. I spent a lot of time going through them. While I recommend these platforms, I do so with a word of caution:

• They can be prohibitively expensive

• Candidates are hit or miss — some weren’t even looking for jobs!

Since then, Vettery and Hired have changed their pricing and I believe one of them has acquired the other.

Internal moves

Moderate Effort, High Value

This is one key area to not overlook within your own organization. I’ve occasionally gotten lucky a couple of times when a great candidate who was performing another job function in the organization expressed interest in being a developer or taking on some developer responsibilities.

One of the best front-end engineers I’ve ever worked with was doing manual QA before I pushed for him to move into an engineering role. He turned out to be an excellent internal hire for the open position.

I also once managed to avoid having to hire a sales engineer by transitioning some time-consuming engineering work onto an eager account manager who later took over the dev-ops responsibilities of account setup (eg. domain names, certificate issuing, server monitoring, etc) with just some minor training. It was a win-win situation: the account manager could immediately solve an entire class of client problems, and engineering time was freed up to focus on other priorities.

Intro Email

The intro email is a way for you to get prospects hooked. It’s your first contact with the candidate, and you want to present the best possible face.

The whole point of it is to get the prospect to agree to a phone screen and enter the hiring pipeline. I knew I had to build excitement about the company, while ensuring that I was providing transparency and engaging the candidate on the terms that they wanted to be engaged on. I also needed to do it in a way that didn’t seem robotic, since everyone hates those automatic, generated emails.

A good intro email should:

• Let the candidate know what the company is about

• Let the candidate know what the position is about

• Prompt to schedule a call as soon as possible

I made a pre-made template with some basic standard information, which I then filled out depending on the prospect’s background and the role I was hiring for (eg. front-end, back-end, full-stack, etc.).

Hi Martha!I’m the Director of Engineering at Widget-co, and I wanted to reach out after I came across your profile on LinkedIn. I thought your background was a great match for an open position we haver for a Senior Software Engineer at our company, especially your recent work experience in building administration dashboards using Vue.js.Widget-co is a tech startup building a SaaS widget distribution platform. Our mission is to make widgets accessible to everyone, and we do that by providing widgets at low cost to as many under-served communities as possible. We’re well capitalized and have an exciting opportunity in front of us.Our tech stack is Vue.js and Ruby on Rails, and recent projects include a WYSIWYG website editor, and a dynamic report generator for large data exports. We have a lot of exciting projects on the horizon related to building out our administrative capacities, and I would love to chat with you about them.Do you have some time this week for a quick 30-minute phone call to discuss the role and answer any questions you might have?Best,
Joseph Gefroh
Director of Engineering @ Widget Co
555-123-4567

The cold emails typically did pretty well — I had over 90% of candidates I reach out to with a customized email agree to a phone screen. I don’t know what the industry average is, but I think it helped that I was an engineer reaching out to another engineer, versus a random recruiter.

Phone Screen — How do you determine fit?

The purpose of the phone screen is to ensure there is a basic fit between the opportunity and what the candidate is looking for in their next role.

Make sure there’s a genuine match. Don’t use it to coerce the candidate into interviewing for a role that they don’t really want. That just does the candidate and your company a disservice.

Goals

I had two desired outcomes for the phone screen:

• Get enough information so I could make a determination of fit

• Give enough information for the candidate to make the determination of fit

Remember — the candidate is interviewing you as well. You want to make sure they have enough information up-front to be confident in proceeding with the opportunity.

Key areas

I wanted to ensure the call gave me enough examples about the following areas:

• Verbal communication ability

• More context about the candidate’s past experience

• Candidate’s job preferences

Thinking back to my own experience as a candidate looking for a role, I also wanted to always make sure that the candidate was left informed about the things they wanted to know, in particular:

• Details about the hiring process

• Company’s compensation ranges

• Information about the team and environment

Follow a structure — it’ll save your introvert hide

As an introvert by nature, I absolutely dread talking to strangers. I forget what to say, and I clam up and become an inarticulate mess sometimes.

My earliest phone screens were absolutely terrible for both myself and the candidate. I didn’t want to continue inflicting that on people, so after some experimentation I discovered that having a phone screen structure in front of me during the conversation really helped keep things streamlined and fresh.

By following a structure, I was able to build up my screening skills to a passable level and eventually got to the point where it wasn’t a robotic experience, and the conversation flowed more naturally. It also ensured a more consistent candidate experience, which improved the reliability of the interview process across candidates.

I found the following structure worked for a 30-minute call, with some adjustments depending on the role:

• Introduce yourself

• Put the candidate at ease

• Tell candidate what to expect

• Explain the company and mission

• Explain the role

• Learn about the candidate

• Be transparent with compensation

• Give the candidate an opportunity to ask questions

• Start the close

• Explain next steps

• Close the conversation

Some example questions

I’ve included a set of example questions in more detail. It’s not intended to be a checklist, but rather ways you can start and guide the conversation. The call should be engaging, fun, and leave room for open-ended discussions.

Remember: you’re not conducting an interrogation!

Introduce yourself

Hi Martha, this is Joseph, the Director of Engineering at Widget-co. Is this still a good time to call?

I like to start by ensuring the time is still good for the candidate. Sometimes unexpected things happen that throw schedules off.

I don’t want to interview a candidate when they are in a weak position. I want to give them the opportunity to put their best foot forward.

Reschedule if it isn’t a good time.

Put the candidate at ease

How is your day going so far?

I have a bad habit of jumping straight into the meat of the matter. Being on the receiving end of that is a little off-putting, which isn’t a great candidate experience.

I try nowadays to start by putting the candidate at ease. Say something pleasant, or share a light-hearted anecdote about your day. Lightly self-deprecating humor can be helpful, but don’t get carried away. There’s a very distinct line between telling a candidate “I accidentally tripped over my dog earlier today and now he’s giving me the stink-eye” and “my dog has cancer and now I have to put him down.”

Tell the candidate what to expect

I wanted to have this call to explain a bit about the role, our company, and answer any questions you might have. Does that sound OK?

Having a map of what to expect from the phone call is helpful for a candidate. You don’t want them distracted from your questions or answers because they’re waiting for some sort of surprise coding challenge to come up.

Make sure they know what to expect.

Explain the company and mission

Widget-co is the world's leading supplier of widgets. We've supplied over 10 billion widgets to underserved communities since 2009, and have goals to deliver 10 billion more within the next 2 years. We're greatly accelerating hiring of our team to ensure we build the best widget distribution platform we can.

A lot of developers look for companies that have purpose.

You want to be able to describe why your company is doing what it is doing, and ideally tie it into some social good. If you don’t have a social good to fall back on, that’s OK! You can always mention things like technology excellence or some other thing developers would be interested in.

I found that people opt in to the “Why?”, not the “How?” when interviewing.

Don’t assume knowledge
A lot of companies feel like the candidate should know everything about the organization and study up before the first call. They treat any signal that the candidate didn’t seem to do their legwork as a hiring disqualifier.

I don’t agree with that approach. People are busy, and job hunting is hard and confusing. Having an expectation that your company is a special company that candidates must study up on is a bit presumptuous. In some cases I just didn’t care enough to study up. That was what the phone call was for: to find out more!

Explain the role

The role I'm calling you about is for a Senior Software Engineer. We're looking for someone who can build out our SaaS web application as a full-stack developer, and help guide our team in effective development practices. Our current tech stack is Vue.js and Ruby on Rails, and our deployment infrastructure is Heroku.

Explaining the role helps set expectations and makes sure everyone is on the same page. Sometimes wires get crossed and people think a role is one thing vs. another — a problem that gets worse if you’re using non-industry standard tiles.

A quick sentence or two provides plenty of clarity.

When I was interviewing at my last job search, I ran into a lot of situations where I didn’t even know what role I was interviewing for during the call. Sometimes I forgot what company was calling, other times the company hadn’t actually listed a role. Having a recap was really helpful.

Learn about the candidate

Could you walk me through your past experience so far?It seems you have a lot of experience working with <small|big|cross-functional|agile|lean|etc.> teams. Is that out of preference?What does your ideal development process look like?What are you looking for in your next role?

Here’s the point in the conversation you’ll get to learn about the candidate.

Gear questions towards understanding the candidate’s preferences and learning more about the context of their background and experience.

Give them opportunities to highlight what they’re proud of, their biggest accomplishments, their most challenging projects, their best and worst environments.

Remember — you aren‘t making a skills assessment at this stage. You are trying to see if there is a fit between the opportunity, their background, and their interests.

Be transparent with compensation

Our current offering is $140k - $150k base, with equity, PTO, insurance, flex-hours, and other benefits. Does that sound in-line with what you're looking for?

This may not be possible at your company, but if it is, I recommend full transparency with compensation.

For starters, it prevents both sides from wasting each-others’ times if there’s a big mismatch in expectations. Additionally, the transparency helps keep you honest, and makes sure that large compensation discrepancies don’t appear over time for the same role at your company.

If it’s not possible, at least provide a range or indicator of some kind (eg. “we are in line with market” or “we’re within the top 20%”).

Don’t ask about current or former salary
This is not only illegal in some states, it is also what I consider a “jerkface move”.

Take it from someone who started their engineering career at $20/hr — people’s past salary should not determine their future salary.

Give the candidate an opportunity to ask questions

I've been taking up a lot of the time in this conversation - I want to leave room for you to be able to get answers to any questions you might have about the role or what we've just talked about.

By now the candidate must have a dozen questions (or not). Be sure to leave plenty of time for them to ask and receive answers. Remember: they’re interviewing you, too!

If you don’t know the answer, write the question down for next time and get the answer from someone — chances are another candidate will ask. If you can, follow up later with the candidate with answers.

Finally, it goes without saying, but be honest. Don’t make your opportunity or company seem like something it isn’t. While a little embellishment is fine, don’t deceive the candidate — it’s not great when the candidate’s first impression when they start work is “I’ve been tricked.”

Don’t assume negative intent
Some candidates won’t have any questions at this stage, and that’s OK. Don’t hold it against them.

Start the close

We're right about our scheduled time, I really appreciate you taking the time to talk with me today, Martha! It sounds like there's a great match between Widget-co and what you're searching for in your next role. We'd love to continue the process with you, and if you're interested as well let's schedule next steps.

If you think there’s a good match, start guiding the conversation to the close — getting them into the next step of the pipeline.

If not, that’s fine, too:

Based on our conversation, it sounds like this opportunity isn't quite what you're looking for. I'm not sure you feel the same way, but if you do, let's put a pause on the process. Let's stay in touch in case something changes in the future.

Explain next steps

Excellent! Our hiring process is actually a pretty simple 3-step process:Our first step was to have our introductory phone call to discuss the role and your background, which we just did!.The next step is to do a brief technical assessment of a code sample you can provide us. After you send us the sample, we'll schedule a 30-minute call w/ an engineer to discuss the various tradeoffs and decisions you made. I'll send you the full details right after this call.The final step is an on-site where you'll get to meet some other members of the team and have deeper in-depth discussions on your background, work experience, and how our company operates. We don't do whiteboard algorithms or brain-teaser style coding challenges, so don't worry about that! The whole process should take less than 2-weeks, or we can accelerate that if you're evaluating other offers or are later in the interviewing stages at another company.

Explaining next steps has a two-fold benefit. You can sell them on how fast and light the process is, and you also improve the candidate experience by giving them a timetable and clarity. It also gives you an opportunity to sneak in some questions on who your competition is for the candidate.

Close the conversation

Does that sound good? Awesome! I'll reach out later today by email with details and we can get the next steps scheduled shortly! It was a pleasure chatting w/ you - have a great rest of your day!

Finally, close the conversation by letting them know that the ball is in your court and when to expect your response.

Technical Assessment (Prompt)

Immediately after the call, I would email the details of the technical assessment to the candidate.

I had structured the tech assessment to be lightweight and open-ended. Some people have other life obligations that prevent them from spending days or weekends on extracurricular activities. Others may be applying for several jobs simultaneously, and can’t realistically do take-homes for all of them.

By providing flexibility, I wanted to make sure we respected the candidate’s time. I also wanted to make the process easy — if the candidate already had a code sample they were proud, I didn’t want them to waste their time making another one that might’ve been less impressive.

Hi Martha,It was great chatting with you earlier! From our conversation it seemed like Widget-co really fits with what you’re looking for! We’d like to proceed to the next step, which is the Technical Assessment.Our engineers want to get an idea of your engineering approaches. Could you provide us a link to an open-source project or send us a code sample that showcases your skillsets? Ideally it is a Ruby on Rails or Vue.js project, but any technology will do as long as we can get a sense of your engineering approaches and can have a discussion around it.If not, we have some prompts here you can pick from to submit a quick code sample for us to have a chat about:<link to prompts>After you submit something, let’s schedule a brief 30-minute phone chat w/ a couple of engineers to talk about the project and the tradeoffs you made.If you have any questions or concerns, feel free to reach out!Best,
Joseph

The prompts themselves were small projects:

• Build a to-do-list library

• Build a Rails application that saves notes

• Build a front-end that can consume the Reddit API

• Refactor this terrible code

• Design a model layer for this problem

Depending on the role, there might’ve been a focus on one aspect of another. Each project was expected to take about an hour or two, and included a full initial scaffold to ensure candidates didn’t get stuck in local environment setup.

Tech Screen (Discussion)

After they submitted their sample, I’d have a call to discuss their project in more details.

The conversation typically focused on fundamentals, tradeoffs, and design approaches more than nitpicks like braces or coding style, unless coding style was significantly lacking to the point of impacting maintainability.

The discussion was more about whether the candidate was conscious of the pros and cons of the decisions they made, or whether they simply did them without intent or thought.

I avoided technical trivia at all costs, unless they were fundamental concepts to the technology. For example, asking about Ruby Hash constructor initialization quirks wasn’t a legitimate question to ask. Asking about why they chose a hash over a list was perfectly legitimate. Asking “why” also allowed me to see how they handled conflicting viewpoints and challenges.

I never asked whiteboard-style algorithm / challenge questions. I’ve found them to provide no signal whatsoever, and I try not to create an interview process that I wouldn’t be able to pass myself.

Leave room for questions

Leave some room at the end for the candidate to ask questions about the company’s stack, technology, development process, etc.

Group Screen

The group screen was a way for the candidate to meet people they would potentially be working with, and vice versa. It was structured, but not overly so, with gaps to enable conversation to flow.

The most important part of the group screen was the cross-functional element. I tried to get evaluators from as many non-engineering departments as possible, especially Design, Product Management, and Project Management.

To keep things simple, it was just 2–3 people at a time, rotating in or out over a period of a couple of hours, evaluating the candidate from their perspective and giving the candidate an opportunity to ask questions about their day-to-day.

There was a short technical component to it as well — engineers could go discuss some specific area or concept with them in greater detail and bandwidth than they could over a phone-call. For especially senior roles, we would do a mutual software design session, where we whiteboarded some architectural ideas together.

I found it helpful to not have the candidate go to the whiteboard, but to have one of the evaluators do so while the candidate drove the solution process. This took negative pressure off of the candidate that can be caused by “all eyes on me” situations.

Leave room for questions

Once again — leave room for questions. This is the candidate’s first contact with non-engineering groups in the organization, and getting their perspective may be useful to them.

Decision

Finally — it’s time to make a decision. Get everyone in the room together. Ask everyone what they thought. Ask whether they saw any red, yellow, or green flags.

If you can, have everyone grade the candidate based on a rubric of some kind. What goes on that rubric really depends on your organization’s culture and needs, but I always recommend starting with your core values and working from there.

Areas can include:

• Communication

• Collaboration

• Technical skills

• Core Values

• Initiative

• Continuous Improvement

• Potential

Don’t make the rubric the sole judge

Note: the rubric is not a math problem that determines whether you should hire or not hire someone after you fill in the blanks — you likely don’t have enough pipeline to reject people that arbitrarily.

Use the rubric to inform and generate the discussion amongst the hiring committee. Of key focus here is significant deviations in scoring or significant alignment in scoring.

Make the call

Finally, remember that hiring is not a democracy — at the end of the day, the engineering leader must make the decision.

As always:

• Never hire jerks

• Never hire dishonest people

Offer

Congratulations! The candidate made it to the offer stage. The final step here is to make an offer.

Hi Martha!I’m really pleased to offer you the role of Senior Software Engineer. The team really enjoyed chatting with you and we felt there’s a strong match between what you’re looking for and what we need.Attached are the details of your offer:<link to offer letter>We’d love to hear back from you soon, but take the time you need to make a decision that is good for you!If you have any questions or want to hop on a call to discuss the offer — let me know!Looking forward to hearing back,Joseph

Avoid exploding offers

An ultimatum is not a great way to start a relationship. If you do have some sort of urgency, make note of it but also give as much time to the candidate as possible.

Don’t let it get stuck in paperwork

Once you’ve made the decision, you should be able to send the offer our immediately. This means you should have already done the leg work to get budget approval, and have paperwork drawn up ready to fill in the blanks and sign.

The worst feeling in the world is when you have a candidate where you’re both excited about the match only to have it fall through because the paperwork got stuck in HR.

Rejection

Not all candidates are going to pass the bar. Rejections are hard, and you want to make sure that you reject gently.

Hi Martha,We appreciate you taking the time to meet the team and tell us about your background. Unfortunately, we have decided to not proceed with your candidacy at this time. While the team felt you had great front-end engineering skills, the role required someone with more expertise in full-stack development and back-end data modeling.We wish you the best of luck in your job search.Joseph

Should you give feedback?

It’s a tough one. Rule number one is: don’t open up your company to lawsuits.

With that said, candidates can grow tremendously from interview feedback. Provide useful feedback to the candidate if you are confident they’ll accept it graciously. I find candidates that ask for feedback are much more open to receiving it than giving unsolicited feedback.

As an anecdote, I once rejected a candidate for being too junior. The way she incorporated the feedback we gave her was so impressive that we later hired her immediately when a new position opened up a short time later.

Some General Advice

Involve the Team

I always think it is a good idea for the candidate to be able to meet with the team they’re going to be working with.

It’s good for both parties: the team can figure out if the candidate will work well with them, and the candidate can figure out if they would like working with the team.

This is harder to do the larger the team gets — in this case, choose a few members who represent your organizational values as the representatives of the larger organization.

Make the process generally consistent

The best thing you can do for your hiring process is to make it generally consistent.

It’ll help you compare experiences across candidates, and give you signal needed to fine-tune the process.

Use rubrics, follow a loose structure, and try to make the process the same from candidate to candidate.

Keep the candidate experience in mind

Whenever you add a process gate or hoop the candidate has to jump through, always take time to consider the candidate’s experience and context.

Are they busy working a job already? Are they applying for more than one position? Are they in a rush, or do they want to take their time?

If you don’t keep the candidate in mind, you may create a process that can’t be passed by people in many different life situations, greatly limiting your access to talent.

If your hiring process is accidentally designed to only be passable by unemployed engineers with no life obligations fresh out of an academic program, you’re only going to be able to hire unemployed engineers with no obligations fresh out of an academic program.

People don’t need to be perfect

Looking for the perfect candidate is foolhardy. Nobody is perfect, and you’ll pass on some great talent.

I once had a committee give a thumbs down to a candidate because they felt he wasn’t as friendly as they liked. I had further discussions with the candidate, and made the decision to over-rule the group’s consensus and make an offer. The candidate ended up being a fantastic employee who was incredibly collaborative and people ended up liking him after all.

Your job isn’t to hire the perfect candidate, your job is to hire a candidate that fits well into organization and team structure.

Stay legal

There’s certain areas you should never, ever, ever discuss or ask about in an interview. Things such as:

• Age

• Gender

• Race

• Familial status

• Religion

etc. are all verboten, at least in the US. This also includes proxy questions — if you can’t ask about age, then asking about when they graduated high school and calculating their age is also prohibited.

Be familiar with what is prohibited, and avoid these situations.

Hire for the team

Being knowledgable of what your team truly needs opens up the playing field significantly in terms of your candidate pool.

Instead of looking for the ideal candidate, look for a realistic one. This means that you can hire someone weak in one area and it’s totally ok to do so if you have a team that is strong in that area.

Remember: you’re not trying to build an individual, you’re trying to build a team.

Don’t look for reasons to reject, look for reasons to hire

Everyone has imperfections, and it’s easy to say “no” just because a candidate has one or two weaknesses.

You’ll get a lot of false negatives that way, and because you’re reading this I’m assuming you don’t have time or the bandwidth to have that many of them.

Clearly reject people if the weakness is a critical one (eg. inability to collaborate, very weak technical skill, etc.), but be judicious.

Ask yourself:

• Can the weakness be covered by other members of the team?

• Do they provide strength in an area the team is lacking?

• Are they collaborative?

• Do they have significant potential, and growth trends?

• Is the weakness due to inexperience, or character?

• Does the candidate provide a perspective or viewpoint that is missing from the organization?

Create a process, then delegate

You don’t have to do everything by yourself.

If you make it clear what you’re looking for and have a consistent process, you can start delegating stages of the pipeline to others with some minor training.

By the time the process was in full-swing, I had delegated the tech screens to engineers, the scheduling being covered by internal admins, and some of the souring being done by HR working to help improve recruiting capacity. All of this gave me back valuable time to work on other areas of the company.

However, such clarity is only possible by defining the process, providing training, and trusting others with the responsibilities. Make sure you do this if you want to scale this process out beyond just yourself.

That’s it

I hope this advice is helpful for those busy engineering leaders who feel lost or stuck in how to hire.

Keep in mind: I’m not a professional recruiter. I don’t know what an industry-standard hit-rate for a cold intros is, or whether there’s certain messaging that works better or not, or whether this process is even scalable.

If you know of a better process, implement it! If something in this doesn’t work for your specific situation, change it! This is a starting point to an effective hiring process, not the destination, and is intended to help those with no process at all get off the ground with as little friction as possible.