How to hire your first VP Engineering

7 min readDec 14, 2021

Written by Niniane Wang

After advising a dozen startups and a VC fund, some of the most common questions I encounter are about the VP Engineering in a startup. When should a startup hire one? What profile of candidate should they look for? How do they interview for this role?

First Off: What Does the VP Engineering Do?

Many tech-industry people are familiar with a job role called the “TLM” (Tech Lead & Manager). The VP Eng’s job also has the components T, L, and M: i.e. Technology, Leadership, and Management.

For the “T” (technology), they need to ensure that the correct technical architecture decisions get made. They may not be the ones making the actual hands-on decisions (they may be delegating that), but they:

articulate the priorities for making these decisions
help judge the trade-offs
settle disputes regarding architecture
step in and make decisions that span multiple eng teams, especially if the teams disagree

For “L” (leadership), the VP Eng oversees the engineering roadmap and collaborates with PM, Design, Marketing, Sales, Customer Service, and other departments. This includes:

refining processes to ensure a high development velocity
adding software best practices to keep the bug count low
collaborating with the business team to ensure technology will help hit business goals
setting a roadmap to create innovative technology that acts as a sustainable advantage over competitors

For “M” (people management), the VP Eng will:

create structure for career paths and promotions
build a diverse team with an inclusive environment
manage team morale
prevent conflicts (and resolve the ones that couldn’t be prevented)
create an environment where engineers feel a high sense of fairness in how people are given responsibilities, promoted, and guided in their growth
maintain high productivity, such as by matching tasks with engineers’ interests and strengths

When Do You Need to Hire a VP Eng?

Below is a list of symptoms that occur when your startup goes for too long without a VP Eng. Go through this list and mark how many are happening at your company.

Symptoms:

Technology (architecture decisions):
Are your engineers fighting frequently over technical architecture and getting into stalemates?
Do your engineers talk about how your codebase has high technical debt or how there’s a lot of spaghetti code?
Do tasks consistently take longer than expected because the engineers say the code is brittle or hard to understand?
Do engineers often uncover many problems in the course of fixing a narrow issue?
Do non-technical people end up serving as a tie-breaker on technical decisions?
Leadership (software development process & collaborating with other departments)
Is software development velocity consistently too low, compared to other companies using similar technologies and solving similar problems?
Does your production website have 2+ user-visible significant errors per week?
Does your production website have an outage more often than once per quarter?
Is the business team repeatedly holding back on making requests (and instead using suboptimal workarounds) to tiptoe around 1 or 2 “grumpy” senior engineers?
This is especially concerning if the CTO or current head of engineering is one of these grumpy engineers.
Are the engineers unclear on the vision and roadmap for Engineering?
Are other departments (e.g. Marketing, Operations) unclear on the roadmap for Engineering?
Does the business team think that the engineering department is working on “tech for the sake of tech” and is not working on the most important priorities to drive the business forward?
Management (careers, people management):
Is there an increasing amount of conflict between engineers?
Are a significant number of engineers demoralized?
Have you experienced unwanted attrition of several engineers?
Is there a “clique”? Do engineers complain that there’s an in-group and an out-group?
Do you have a non-diverse team? Do you get complaints from the few underrepresented engineers about the team environment?
Is there tension and uncomfortable silence in many engineering meetings?
Are there low performers whose performance is not getting addressed?

If you answered “yes” to 3 or more of the above questions, it’s time to look for a VP Eng.

Decide Which Stage of VP You Need

Before you start interviewing for a VP Eng, you need to decide which stage you’re hiring for. Here are some stages of VP Eng:

VP Eng is writing code most of the time, and doing people & project management in the remaining time. This happens when the eng team is still one cohesive team rather than subteams, typically 10 engineers or fewer.
When interviewing, cover technical architecture, coding, software development process, and managing ICs.
VP Eng understands the codebase and is managing managers. They read through some of the changelists submitted by engineers. They spend their time on strategy, roadmap, and software development process. They may occasionally write non-critical-path code. There may or may not be a promotion system or career ladder. This is typically 11 to 30 engineers.
When interviewing, cover how they lead the software development process, create a culture for technical excellence, and manage managers.
VP Eng is one step removed from the codebase, and relies on directors & managers to make technical decisions for each codebase component. They are in charge of the career / promotion ladder. They also create the annual budget, OKRs, and strategize the 2–3 year technology roadmap. This is typically 31 to 100 engineers.
When interviewing, cover how they set the yearly engineering roadmap, handle promotions and career paths, and create a culture for technical excellence when there are many independent teams.
VP Eng manages technology for multiple product lines. Their reports (directors) present them with choices on areas spanning roadmap, org design, headcount, and in which areas to invest development. They make the final decision. This is 101+ engineers.
When interviewing, cover how they do long-term org design, set the 3+ year technology roadmap, and assess industry trends in order to create a sustainable technology advantage over competitors.

One pitfall is that some startups want it all. For example, they currently have 8 engineers, and they want a VP Eng who can scale from 8 to 800, meaning that they want a VP Eng who has managed hundreds but who’s also happy writing code all the time. Those VP Eng candidates do exist, but you might need to wait several quarters and battle numerous other companies to hire one.

It’s more efficient to narrow down your stage. If you want a VP who writes code all the time, don’t interview a candidate who’s managing such a large team that they haven’t written code in years. If you want a VP who manages a large team, don’t expect them to also be a hands-on expert at your technologies.

Interviewing Candidates for VP Engineering

I usually get through 6–7 questions in a one-hour interview. I ask 2 questions in each area of technical architecture, leadership, and management.

For Basis Set Ventures portfolio companies interviewing VP Eng candidates, I provide a list of 12 interview questions that I draw from.

Pitfall to Avoid: When Interviewing, Don’t Accept Hypothetical Answers

When interviewing, ask the candidate to describe a real scenario from their work experience. Do not accept hypothetical answers of what they plan to do. Ask what they actually did.

Question: “Tell me about a time that you resolved a conflict between two engineers.”

Hypothetical answer: “In that scenario, I would have them each state their viewpoint, and I’d help them see the other person’s view and find a win-win compromise.”

Real life is rarely so tidy. The quote “No plan survives first contact with the enemy” is applicable.

Actual experience may sound like this: “Two engineers had been fighting for weeks, to the point of arguing angrily for an hour about variable names. Their manager helped them mediate, but for every issue that was resolved, a new one would pop up a few days later. Eventually, we sat down and had a heart-to-heart. One of them, “A”, finally opened up and said he felt disrespected because several times he submitted a changelist, B chimed in with suggestions even when B wasn’t the code reviewer. Then B said … “

If You’re Hiring for Complementary Skills, Don’t Lose Sight of That

Sometimes, a startup will be hiring a VP Eng who complements their CTO. If the CTO is very technical and focused on architecture design, the startup wants to hire a VP Eng who is great at people management and org design.

But during the interview, the CTO may inadvertently stick to their comfort zone (technical architecture) and apply overly strict standards. E.g. “I asked the VP candidate about red-black trees, and they gave a poor answer. How can we hire someone who doesn’t know this?”

If you are strong at an area, it means you value it. Because that area is important to you, it can take discipline to remember that you decided that area is of secondary priority for this role.

This can also happen with business-oriented CEOs interviewing the VP Eng candidate. They might say, “This candidate is amazing at understanding the revenue metrics. I didn’t test them on the technology parts, but it’s so easy for me to talk to them about the business side. Let’s hire them!”

Emotionally you will be excited to find a candidate who shares your strength (or disappointed if the candidate is weak at the area you value). You need to use logic to overrule this, because you’re hiring for complementary skills and not a clone of yourself.

Confidence and Bluster

Sometimes companies overweigh “confidence” during the interview. They think that confidence is key to leadership, and they filter out candidates who come across as soft-spoken or nervous.

This is risky. This can cause companies to gravitate toward slick candidates who are willing to bluster. They end up filtering out humble candidates. However, the modest leaders can often be more successful in the role, because they double-check information, make backup plans, and are happy to learn from feedback.

In addition, once a company starts basing hiring decisions on confidence, it’s easy to stray into the realm of unconscious bias, where people associate deeper voices and taller people with authority. They may end up hiring a worse candidate who happens to be tall with a deep voice.

In the long run, teams ultimately respect solid plans, knowledge, and skills. A blustery VP might be initially charming for a couple months, but eventually the results will be clear.

Focus on the content of the answers given, not whether the VP candidate answered with a loud voice or a soft voice, stood up straight vs slouched, and other “style” issues.

Good luck!