One of the more popular posts on this blog has been the one on how to interview your manager.
And one of the questions I am often asked is how technical does a VP engineering, or software development manager need to be if they aren’t writing coding day to day? And moreover how do you assess that in an interview?
This post outlines an interview question that could take 1-2 hours depending on the depth of the candidate (and of course the interviewer). However, I think it does a good job covering technical skills, and more importantly how those technical skills play into the real role of a software development manager or leader.
P.S. Like all interviews though, this is not a one size fits all so please be sure to follow up on the questions and facets relevant to your company and role.
Evolution of a Product Problem
Step 1: Stage the ambiguous BIG idea
Pick a big software system with relatively clear functionality. Ideally something you understand, but that neither you nor the candidate have a ton of expertise in (that way you should clearly be able to assess is this person way better than I would be – which should be something true of a manager). Some of my favorites are:
- An image hosting application (like Flickr – people upload images and others view them)
- A cloud storage system (like Amazon’s S3 – people upload files and access them)
- A simple ecommerce website (like Lululemon – one vendor of products, relatively simple check out process)
But you can really choose anything as long as (a) the candidate can understand the functionality easily (you don’t want to spend the interview explaining the nuances of the problem) and (b) it has the potential to grow in terms of traffic, usage, items, data, etc.
Step 2: Ask them to define it.
Once you have explained the big problem, throw the ball back into their court to define and articulate the requirements. This is a great way to get a sense of their general product know-how, and intuition on product design and implementation.
For the sake of this article, let’s say we chose the image-hosting example. So in this case I would say something like:
Imagine you were tasked with managing the creation of an image hosting service like Flickr, or Photobucket. What are the high-level use cases and requirements for such a service?
As they answer pay attention to how the approach the problem. Do they start with the customer first? What kind of questions do they ask up front? If you tell them to ignore the wireframes and design and just focus on APIs, what are the interfaces they define for the service? What parameters do they specify? Do they think about security or external/internal consumption of those APIs? Feel free to ask probing questions and give suggestions until you are happy with the result.
So for the image-hosting example their answers might be something like the following:
POST http://api.site.com/services/upload/ Arguments: photo file, title, description, tags, content-type Return value: photo id or error code
Updating existing files:
POST http://api.site.com/services/update/ Arguments: photo id, photo file Return value: success or error code response
Fetch or Retrieve the file:
GET http://api.site.com/services/get Arguments: photo id Return value: photo or error code response
Delete a file:
POST http://api.site.com/services/delete Arguments: photo id Return value: success or error code response
Step 3: How does the system actually work?
Once you’ve gone through the requirement problem you got a feel for the candidate’s ability to identify customer requirements it is time to move onto the actual technical design (which is what you are probably used to for senior engineer system design type questions).
Using their interfaces from Step 2, ask the candidate to actually draw out the logical pieces of the system needed to support these requests. You should cover the following things:
- How are requests services?
- Where is data is stored?
- What needs to be backed up and when?
- How do these different pieces interact together? What are the services needed to support the system?
At this point, they have probably drawn an architecture diagram that may look something like the following:
Step 4: Scaling
Then comes the good part of the problem. With their diagram ask them about scaling and growth.
- Where are the current bottlenecks?
- How would things need to change to support 1000x of the amount of traffic?
- How could you support more customers? Would you need more security and authentication?
- What are some different partitioning schemes?
Things to look for as hot spots are any place where you have a lot of incoming requests (client uploads and requests for images), outgoing requests (think of all the places you might want caches), and where data can grow beyond the capacity of one server (image files for example). Also, for long running jobs like uploads, you will want to make sure they understand one server can only maintain so many open connections at a time, etc. You get the idea.
Asking these questions will give you a good feel for the candidate’s knowledge and ability to diagnose and understand potential bottlenecks and issues as the services grows (which hopefully your company is doing!). It can also be a good indicator if the candidate really understands the system architecture and the way the pieces go together and support one another.
Maybe their diagram will end up something like this one:
Typically for great well-rounded candidates this first 4 steps will take almost an hour to go through in detail. They will be asking good questions, clarifying use cases (be prepared for that), and talking you through tradeoffs and potential solutions to problems.
Step 5: Building
Once you’re confident that they’ve done a great job with the architecture then it is time to move on to an important skill any software manager needs to nail – how to build a system. I like the follow up with something like the following:
Imagine you’re tasked with actually building this system.
- How would you staff the team?
- What technologies would you use and why?
- Which parts would you build first and in what order?
- How long do you think it would take to get a basic version shipped? How did you determine that estimate?
While there are certainly an infinite number of ways to build and approach this problem, you are really looking to dive into their thought process and philosophy around resourcing and staffing projects. You want to understand the way they structure and think about software and the build out of a complex system.
I once had someone tell me, “Well I would let my senior engineer make those decisions”, and maybe that would be true, but push the candidate to go through the full exercise as if they didn’t have a senior engineer and had to make those decisions on their own.
A great follow-up on this question is to ask the candidate if they had to build the system as fast as possible what do is the fastest they could build and launch it? How much time would it take? How many people would they need to make this happen? What are the greatest areas of risk?
This line of questions can provide a picture of how pragmatic and realistic the candidate can be, and perhaps some of their creative resourcing ideas. Hopefully they will pepper their answer with anecdotes from their past experience, and if not you can always prompt them and ask, “Have you ever tried that before? How did it go?” or “How to ensure your team hits deadlines and ships software on time?”
Step 6: Deployment and Releases
Once you’ve gone through a basic resourcing and costing exercise in step 5, a great follow up is to get a feel for how they would actually handle the deployment and launch of such a system built from scratch. There are two sections to this step – the infrastructure and the process.
Step 6a: The Infrastructure
In this portion of the interview you are trying to determine how well your candidate understands hardware, storage, and general costs of operating and maintaining a large software website.
A great line of questioning that works well is as follows:
- What is the minimum amount of hardware needed to operate this system?
- As you scale where would you add hardware first?
- What is the incremental cost at each step?
- Are there optimizations you could make to reduce your hardware spend? (good answers are things like compression, archival/cold storage, etc)
You are looking to get a feel for the candidate’s sense of cost and spend for hardware and hosting (which hopefully is something they have managed or dealt with at some point in their career – even if it was just their own personal website).
Step 6b: The Deployment
Now that both of you have explored the way the software might reside and operate in the physical environment a great follow up is how they would actually update or deploy the software. Fair questions are things like:
- What kind of tools do you use?
- How would you roll out to new users? (good answers are typically staged roll outs, betas, feature flags, etc.)
- How do you balance the “splashiness” of a big marketing launch (and peak traffic) with a brand new system?
- How can you mitigate risks to ensure a successful launch?
Hopefully they have some good ideas and can pull from some past experiences (including mistakes where launches went terribly bad – since most of us have experience with those).
Step 7: Operations
Since most of us are not so lucky to be able to build and operate products we created from scratch, understanding the operation of this type of system is an important thing to assess in the interview. You should be sure to touch on philosophies on operations and support, but also make sure they understand best practices. Here are some questions to help you probe these areas:
- What types of monitoring do you need for this system?
- How often would you look at your instrumentation?
- What sort of systems have you used in the past? How did they work? What did you like and not like about them?
- How many people do you think are needed to maintain and operate this system?
- How have you handled operational issues in the past? Did it work well? Would you change it if you could? How did the team feel about it?
- What kind of process or feedback loop should be in place for customer feedback/issues?
- What kind of business metrics do you want to measure or track for this project?
- How often and in what medium should they be reported?
- How have you tracked these types of business metrics in the past? Did it work well? Why or why not?
With each area of these questions you are trying to get a grasp of the candidate’s experience and thoughts with the various aspects of running a production system. Hopefully they will provide great answers that align with your company culture and resonate with you and your team.
This sort of problem should give you a lot of ground to cover in a lot of different areas; and for most software management roles it should many aspects of the role. Of course you can pick and choose each step based on your team’s needs and the responsibilities of the position. You can also add more steps too – things like hiring and recruiting talent, documentation, managing biz dev partnerships and APIs, etc. You get the idea. Hopefully this helps get you started, and if you have thoughts or comments don’t hesitate to add them to the comments