Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Software engineering manager interview questions

August 6, 2020

How do you interview software engineering managers? The core job of an engineering manager is to support the team, making sure they have what is needed to do their jobs, whether that’s information, more people, space to explore a problem, or promotion of their work to the rest of the company. It can be an ambiguous role. Technical people like questions with firm answers so it can be hard for them to effectively interview someone for a squishy position.

Here are some questions I like to use to get a sense of who an engineering manager is and how they work.

A developer manager will be hiring other people, so I like to find out how they recruit and interview.

  • Describe your hiring process. How much support do they need, and is that appropriate for a company your size? Someone coming from a big company might be used to pre-packaged job ads, recruiters that do all the scheduling, and panels that screen resumes. Someone from a small company might not know how to effectively partner with an internal recruiter.
  • What are some questions you ask in the interview? Do they ask a lot of direct technical questions or do they leave evaluating technical fitness up to their team?

Newer developer managers often have trouble getting out of the weeds and still want to build.

  • How do you approach technical decisions with the team? Are they still trying to be the architect?
  • ‌When do you feel the need to assist or take over someone’s work? Are they the former superstar developer and has the mentality that they can do it faster and better? Do they understand how to let someone struggle a bit in order for them to grow?
  • Tell me about a time that you thought your team was making the wrong technical decisions? What did you do? How did things end up?

How do they view other teams? Only part of building successful software involves the actual building.

  • Describe your typical day. Who are they talking to? If it’s their team only, it’s a red flag. A development manager should be spending lots of time talking to other teams. If they’re spending lots of time in design sessions, they might still think they’re an engineer.
  • How do you work with product management? A great developer manager views Product as a partner, as the other side of the coin from them. A mediocre developer manager expects product to tell them what to build. A terrible developer manager thinks Product just needs to get out of the way.
  • Tell me about a time when you had to balance the needs of the technology with the needs of the rest of the business. Can they effectively work with other parts of the company, or do they view it as "us vs. them"?

See how they handle team issues.

  • Tell me about a time when your developers didn’t empathize with the users.
  • Tell me about a time when you had a developer that produced great work, but didn’t work well with teammates.
  • Tell me about when someone quit because of you. We’ve all been there. Are you self-aware enough to know it happened, and what did you learn from it?

I also like to understand how they smooth out the info going to the team.

  • Tell me about a time you held information back from the team until you had more information?
  • When might that not have worked? Specific techniques for keeping the team from whiplashing from one direction to another as business reality changes, but also doesn’t keep the team in the dark.

Finally, I like to understand their views on how to grow and nurture their team.

  • Tell me about a few people you’ve managed, then talk about how your approach differed (or didn’t) for each.
  • How often do you meet with your team members 1:1? What would cause that to change?
  • What do you talk about in your 1:1s?
  • How do you make sure the team is always growing and improving?
  • Tell me about a time when you needed to train your team but had no budget for training or conferences?

A framework for onboarding new employees

May 15, 2020

When hiring new employees the process of getting them ready to be productive members of the team is usually arbitrary and disorganized. The HR process of getting payroll and benefits set up may be effective, but training someone in the way the actual work happens is not. Most of the time onboarding consists of, "Chuck will show you what you need to know." Chuck isn’t given any guidance to follow, and every new employee gets trained differently.

To learn how to cook hamburgers at McDonald’s, a new employee watches several hours of video, then gets a hands-on demonstration, and finally cooks a few burgers while someone monitors. When we hire someone to build complex software products, the onboarding process is, "You’re smart, I’m sure you’ll figure it out."

Running a good onboarding process is essential to making sure new employees are productive, satisfied, and effective.

There’s no single good way to onboard an employee. The details of the role, the company, and what makes for an effective teammate differ. Instead of One True Process, here’s a framework for creating one that you can adapt to each situation.

Read more »

TV hosts as a guide for software managers

May 10, 2020

I’ve been watching master interviewers recently and thinking about them as a model for what a software manager should be doing. Late night TV hosts and long-form journalists like those on 60 Minutes are fantastic interviewers and great models of how to lead a software team.

tv interviewer

A good interviewer doesn’t lead the discussion. He doesn’t tell the subject what to talk about. He understands that the subject is the focus, the expert on the topic.

She knows her audience, and helps the interview subject know them too. She gives context about what the audience will like, what has worked and hasn’t worked in the past. She guides the interview keeping it focused and from running too far off in tangents. She looks for nuggets that might be interesting to explore further and encourage that exploration.

She keeps track of time, so the person they’re interviewing doesn’t have to. Instead of a list of topics to check off in a certain amount of time, she has an overall goal for the interview, and an outcome to guide it towards. If time becomes tight, she will find ways to focus the remaining time on the most important things.

An interviewer produces bad interviews when he thinks he is there to be in charge, to run the interview. When he sticks to a rigid schedule, and ensures that he asks and gets answers for the list of pre-defined questions in a pre-defined order, the quality suffers. The answers are unpredictable so the rigid schedule predictably gets off track. Some topics end up rushed, especially those toward the end, and there’s no time to explore an interesting topic discovered during the course of the interview.

The interviewees come away dissatisfied. They weren’t there to think, they were there to implement someone else’s ideas.

Many software managers think that the job is to run the development process. Define a list of requirements. Turn those into tasks. Enforce discipline so that each and every task gets done on a predictable schedule to meet the estimates.

This turns out like those pre-scheduled rigid interviews. Tasks at the end get rushed, and done poorly. Discoveries along the way don’t get explored. The product might meet all the requirements, but there’s no soul to it. It’s mediocre and probably poor quality.

The team is dissatisfied. Instead of thinking and solving problems, they were a task machine, taking someone else’s ideas and implementing them on someone else’s schedule.

Whether she’s in a management position over the team or a product manager responsible for creating a product with a development team, a great software manager acts more like a great interviewer.

She doesn’t jam every minute of every day with pre-planned work, knowing that slack time is important both because of the unpredictable time required for the work. She knows that the team will discover new interesting ideas as the product takes shape and she makes sure the team will have time to explore those. She doesn’t act as the time-keeper, enforcing time boxes, but instead gently guides the team into making sure the most important work gets done in the time available.

A great manager is a facilitator and moderator. He’s not the owner of the team, or the most important among them, or the task-master.

He comes with the context and understanding of what the customer needs, and what the team goals are. He makes sure the team keeps all those in view, and gently guides discussions and explorations in that direction. He looks for interesting patterns and options to explore that further those goals, and steers the team away from irrelevant tangents.

A great manager provides guide rails from within which a team can explore safely. She’ll help the team stay on track, not because she needs to enforce some notion of control and schedule, but because she can free the team to be better when they don’t have to think about things like schedule and which metrics they’re chasing. She can keep track of those, and provide nudges and reminders to keep things moving in the right direction.

The best interviewer is invisible, measured by the impact of the resulting interview. No one measures him by how much he knows about the topic or how many questions he got through or how well he kept to the schedule.

The best managers are those whose teams have the biggest impacts.

The Improvement Flywheel

April 29, 2020

Improvement flywheel system diagram

A few weeks ago on Twitter, John Cutler posted what he called "the wicked loop" of product development problems.

A team doesn’t execute well, which leads to pressures to deliver things faster. Those pressures come from both inside and outside the team.

Read more »

Managers and technical ability

December 26, 2019

There’s a belief in the software development world that you can’t manage developers unless you’ve been one yourself. This often gets reduced to the shorthand that some manager "isn’t technical."

We say someone is "technical" or "not technical" as if this is a binary choice. In reality, it’s a giant scale. I spent much of my career as a developer before shifting to product management. Twenty years ago I wrote a web server and a database engine. I was CTO at two of my companies. I barely understand the basic concepts behind Kubernetes.

Am I technical?

It’s clear that I was technical. But am I still? Is "being technical" something you lose over time? If "technical" is a scale, am I technical enough?

Lisa used to be a network administrator and now is a development manager. She can still design and troubleshoot a network, so she’s clearly "technical." She told me that she’s struggling as a development manager and thinks it’s because she wasn’t ever a developer.

There was a study that found hospitals run by doctors perform better than hospitals run by people without medical training. It’s unlikely that doctors turned senior administrators would be able to lead a complex surgical procedure or would be up on the latest treatments for specific illnesses. Their medical skills and knowledge would be too rusty to be effective. Being a manager of doctors is a completely different career than being a doctor was and managing is now their primary skillset. Then what makes doctor-run hospitals better?

Being familiar with what it’s like to be a doctor is what leads doctor-managers to do a better job running hospitals. They know what it’s like to do the work, they understand the challenges, the tradeoffs, and the decisions that face doctors daily. This is they are better at leading other doctors.

The best development managers are former developers themselves because they understand what goes into developing software. It’s not because you need to be the technical expert to lead developers. But because you need to understand what it is like to be a developer.

This is why Lisa is struggling. She has a technical mind and understands technical concepts, but she has no frame of reference when her team is deciding the tradeoffs between two design options.

I suspect this translates beyond "developer" or "not developer" as well. Someone that has spent their entire career developing web applications won’t understand the things that make writing embedded firmware unique. Putting a web developer turned manager in charge of a firmware team would have the same problems that a network admin managing the team has.

A surgeon likely wouldn’t make a good manager of virologists.

The further up the management ladder you go, the less you get involved in domain-specific things, so the less your specific domain will matter. The surgeon that can’t manage a virologist team could lead a cross-functional group of teams, even when that includes virologists.

I don’t need to know Kubernetes to lead an ops team. I don’t need to know ops to lead an organization that includes an ops team. It’s enough that I can grasp any high-level technical concepts if someone in my organization needs to explain them to me.

Managing developers requires you to be a specialist. Managing development managers requires you to be a generalist. The closer you are to the people doing the work, the closer your skills need to resemble those of the people doing the work. It’s not a matter of "being technical."

Dysfunctions of output-oriented software teams

September 17, 2019

When I see ineffective product teams, it almost always stems from a focus on delivering features instead of delivering value to people. From sales to marketing to product to engineering, they are more focused on output than they are on outcomes. They ask, "did we ship that feature" more than "did we and our customers achieve better outcomes?" No one asks if what the team is doing is really working.

John Cutler calls this a Feature Factory. Melissa Perri calls it the Build Trap. Whatever you call it, the symptom is that you’re measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.

An output-focused team doesn’t measure the actual impact of the work, doesn’t know what metrics are important, and can’t connect the product work to the whatever core metrics they actually do have.

Instead of metrics and objectives, they have deadlines and customer commitments. They can’t cut committed scope to meet these deadlines so they cut quality. They still miss the due date, and now have a product that is both bad and late. Other departments berate the developers for not providing more accurate estimates. No one ever asks why the word "estimate" means "commitment" in this team.

To fit things into the schedules and meet the estimates-turned-commitments, managers come in to assign and track tasks. The output-focused managers are more concerned with "resource utilization" as if the people building the product are machines. They don’t have well-integrated teams, leading to frequent handoffs between people, and siloing of knowledge and responsibility. Those handoffs lead to backups and gaps in the schedule, so they play team Tetris to try and keep developers busy, which makes the problems worse.

When an output focused team tries iterations, they defer important things to "later." Everything is pre-planned months in advance, they’re at full "resource allocation," and they’re always late with every iteration. So later never comes.

The managers try to fix all this by adding more top-down process, bogging down the teams. Things slow down, so the managers add more process to fix it and "hold engineers accountable."

How do you escape this method of working? Take small steps and look to continually improve. Start by defining success through outcomes and deciding up from what measurements will indicate you have reached those outcomes.

Accept that it’s OK if you aren’t always busy. Slack in the schedule is healthy and helps give time to explore and experiment. If you’re not focused on being busy all the time, you’ll be able to think more about creating a flow of value to the customer. Above all, empower people. Trust that the smart, capable people you’ve hired will do the right thing. Try managing through Commander’s Intent: define what success looks like, and then let them figure out how to get there.

Recently Written

Software engineering manager interview questions (Aug 6)
Here are some questions I like to use to get a sense of who an engineering manager is and how they work.
A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.
The Improvement Flywheel (Apr 29)
An incredible flywheel for the improvement of a development team. Fix a few things, and everything starts getting better.
Managers and technical ability (Dec 26)
In technical fields, the closer you are to the actual work being done, the closer your skills need to resemble those of the people doing the work.
Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2020 Adam Kalsey.