For a recent round of interviews, I talked to about 50 companies. Of those, 24 moved on to phone screens. Just seven resulted in on-site interviews, and only three of those companies made offers. The whole process took about six weeks.
Preparation
I started by purchasing the canonical Cracking the Coding Interview book. The first ten chapters detail various types of technical questions. The most useful exercise was sitting down and doing the (approximately 60) example questions in those chapters. I recommend getting an actual whiteboard and talking out loud as you solve the problems. I took photos of the whiteboards when I was done in order to be able to quickly reference back to them, like flash cards.
You can see my full solutions, white-board images, and notes on GitHub.
Working through the problems on a physical whiteboard was the most useful part of preparation. Trying to verbalize my thoughts, translate them into diagrams, and prove that my solution worked on an example set was the closest thing to an actual interview.
Selecting Companies
My target companies were late-stage but pre-IPO, and they had to be in San Francisco. Initial brainstorming yielded quite a few candidates. Then, I looked at every connection I had on LinkedIn, and added the companies that met my criteria. I ended up with about 50 companies.
Next I created a spreadsheet of companies. Glassdoor ratings were a good source of objective data. Note: Glassdoor can vary wildly by the type of role; try filtering by keyword, such as “engineering.” Keep in mind that companies like Lyft and Uber have drivers skewing their Glassdoor ratings.
LinkedIn Premium was useful for directly InMailing recruiters. It was also interesting to see who was checking out my profile as I progressed through the interview process. I did not find it useful for identifying opportunities.
Reaching Out
I’ve heard that the average tenure for software engineers in the Bay Area is two to three years. People move around a lot. In my professional network, this meant that I knew people at virtually all my target companies. I asked each of them for an introduction to the right internal recruiter via a combination of text messages, emails, Facebook messages, and LinkedIn InMails. If I didn’t know someone at a company, I used LinkedIn Premium to InMail a recruiter directly.
Initial phone conversations with recruiters aimed purely to get on the same page about potential roles. The next step was a phone screen with a hiring manager. Those were usually focused on work history, and some initial behavioral questions about management. Rarely did we cover technical topics in the phone screen.
I found it useful to have a well-rehearsed synopsis of my background, types of roles I had held, and what I was looking for. I made sure to stress my philosophy of management, and how it might be different from that of other engineering managers. This helped determine whether a company was going to be a good fit.
Phone Screens
Phone screens started out with a two minute spiel on who I am, what I’ve done, and what role I’m looking for. I got pretty good at telling it like a story, and presenting my career arc as a series of intentional choices. This story also came in handy during recruiter conversations and on-site interviews.
Phone screens were split 80/20 between non-technical and technical topics. The bulk of the conversations were behavioral management questions. See “Common Behavioral Questions” for a representative list.
I thought about these conversations as two-way streets. The hiring manager was evaluating me, but I was also evaluating them and the company. I tried to figure out whether we both believed that engineering managers should focus on non-technical stuff.
I created a gut-check rating for how well each call went. Looking back, a positive gut-check was not predictive of whether I would ultimately be offered a job. But it did correlate to my ultimate enthusiasm about the role after an on-site interview: If I was excited about the opportunity during the phone screen, my excitement level after the on-site interview was unchanged.
I scheduled my on-site interviews such that the roles I wanted the most were clustered last. I used my initial on-site interviews as practice. These turned up a number of behavioral questions, for which I was able to come up with polished answers by the end of my interview loop.
On-Site Interviews
I was pleasantly surprised by the focus of my on-site interviews on management versus technical topics. All had substantial technical portions. One was almost purely technical.
On-site interviews were broken down into slots. All of them shared these features:
- One or two system designs on a whiteboard. For example, I had to architect a system to process web-hooks, or a link shortener like bit.ly; or implement RPC over pubsub. In general, I had over-prepared for these. I think I would have performed just as well with no preparation.
- Two or three behavioral slots, typically with other engineering managers.
- Meet your grand-boss, i.e., the manager’s manager. In my case, this was not a surprise: It was always on the schedule up front.
- Short wrap-up with the recruiter.
Around half of the on-site interviews also had slots like these:
- Present a past project that was sufficiently technical, and dive into architecture decisions, etc.
- Meet with partners/stakeholders, e.g. for product managers, QA, etc.
- Meet with prospective team members, i.e. the people who would be your direct reports. In some cases, this was just the single most senior team member. In other cases, it was a few people at once.
In three out of seven cases, the company requested a follow-up conversation/sell slot with the hiring manager or grand-boss on a subsequent day.
Only two companies asked me to code. I WAY over-prepared for these, doing more than 50 coding exercises! Next time, I will replace most of that preparation with more behavioral questions.
Common Behavioral Questions
This is an incomplete list of the questions I was asked. In my answers, I tried to be explicit about what action I took, and what the result was.
High-Level
- Why do you want to work here specifically?
- What is a manager to you?
- Why did you originally decide to be a manager?
- How do you manage people?
- What are your principles?
- Tell me about a time you failed.
Conflict
- Tell me about a time you had a technical disagreement with someone.
- Tell me about a time you had to override a technical decision.
- Tell me about a time you had a disagreement with upper management.
- Tell me about a time you said no to your boss.
- What constructive feedback have you gotten in the past?
- Tell me about a time you hurt someone’s feelings.
Execution
- Tell me about how to handle a poor performer.
- Tell me about a time your project was behind schedule.
- Tell me about a time you influenced another team that was not performing.
- Tell me about a time you prioritized refactoring over feature work.
- Tell me about a time you made an organization-wide change.
- Tell me about your proudest project moment.
Growing a Team
- How do you think about growing a team?
- How would you evaluate a candidate for promotion to manager?
- Tell me about a time you had difficulty hiring for a key role.
- How would you decide whether to make someone else a manager?
Making a Decision
Of the seven companies, I got offers from three. I pulled out of one because it was not a good fit. I got rejected from the other three.
Picking between the three companies was not a very scientific decision. I looked at the manager, team, project, and office location. I tried to estimate the total compensation over four years for each company. I reached out to a number of trusted people in my network to get their opinion on one company versus another. At the end of the day, my heart was with one particular choice.
Negotiating
Of my three offers, base salary and RSUs tended to be in the same ballpark. Yearly bonus and signing bonus varied significantly. Only one company committed to RSU refreshers and a yearly bonuses in writing. My strategy was to maximize different aspects for each offer, such as base salary, signing bonus, stock options, etc. Then, I asked my top choice to close the gap on the other offers for those dimensions. The result was about a 7% bump in total compensation over four years.
Lessons Learned
Here are some of my high-level takeaways for engineering-management interviews.
- Don’t spend too much time prepping for system-design questions.
- Spend virtually no time preparing for coding questions.
- Over-prepare for behavioral questions. The on-site interviews where I did the worst were the ones where I regretted one or more of my answers to behavioral questions.
- Treat interviewing like a full-time job. It took me about six weeks of 40-hour weeks to network, line up phone conversations, and complete on-site interviews.