Management Q&A

Overview

This page lists selected questions I have been asked over the years about managing software development teams, usually as part of a job application or interview. Questions are not necessarily my own but all answers are. Both may have been edited for correctness or clarity.

Questions

In 1-3 paragraphs describe a time-sensitive situation you faced that had major impact on the overall company. What was it, why was it so important and time sensitive, what did you do, what was the result?

Shortly after I started at the first startup I worked at, a fintech startup building a turnkey asset management platform for independent retirement advisors, the CEO sat me down and informed me that he had signed a contract with an API-driven clearing service. This would be the backend for the new investor interface we wanted to build to automate and accelerate client onboarding for our advisor platform. For independent advisors, onboarding new clients with the advisor's broker is a major pain point. CEO wanted to know how long it would take for us to deliver this.

The catch? In 6 months, we would be on the hook for a flat monthly service whether our product was ready or not. (The fee would be about the same as one developer's monthly salary.)

I met up with the first engineer I had hired, who had past experience as a product manager, to review integration requirements and come up with an estimate organized around major features and milestones. We came up with three estimates: the 6-month version (totally unrealistic), a time-insensitive version (much more realistic but projecting 12-18 months for delivery), and a Goldilocks version that made some optimistic (but not too optimistic) assumptions and aggressively narrowed scope on some features. The Goldilocks version projected 9-12 months.

This was all highly speculative as we hadn't even hired the team yet when the request was presented to us. I made this clear to the CEO when I presented him our estimates. In the end, the product took about 15 months to release to production (less than 12 months if measuring from when the 4-developer team was fully assembled). Our company negotiated some minor concessions on the monthly fees. A major unexpected development in the online broker industry, as the project was readying to exit beta, ended up requiring a major pivot away from our original API vendor (which went pretty smoothly thanks to the care we took in developing our code.) Our company was acquired a year later. A few months after that, the new owners laid off me and most my team and ended up abandoning the platform. I learned several lessons from this experience I'd be happy to talk about in more detail.

Tell us in detail about the architecture of a project you’ve led and/or designed. Lay out the high level components (e.g. front-end, web servers, database) and then drill down and review the design of each component.

For this question, I discussed a key refactor we made while building the investor interface for the turnkey asset management system we built while I was Head Engineer at a fintech startup.

Rather than present the customary architectural diagram, I created this sequence diagram to illustrate the complications we discovered:

• [sequencediagram.org https://sequencediagram.org/index.html#initialData=C4S2BsFMAIEkDsBukDOwD2AnaB5eAjdAQ0wBMR4BzaAMXHQHcAoQ4DAWwAcTQBjEbvGApoTJkV4ZsCZGizjJWaAEFSiECnndMfAUSHQARKvWbsABSzAi4Q9CIjl5ptt2DgRmaim4CxMhSUdg5wOGJecpgAtAB8JhpYAFzQAMLo8CgAruDWoOliALwF8WbQ9JQiFBj2nJwAdKTo7EQUdbxNRQDE4CCUABbA+OCZkGIlWLFOyWlcUMAwFLLA7JAGnJjonOgoNkzw6PPQ6MjYU6kASgCiygAql9C8PavAABQoAJRMTrGwOMlOsGS5hwAGUbtB1pttrt9odjpBpDhOqQSABrLD6SiQaZXW73IicAD6jxAzzenwiUgAPFFfolLs0QOBkgB1SDgdoraDVX6FAqUpQk3iokQ9eCo6AAMyUIHQDSaLXgbQ6BU6vF4ksl6vCSG8ExiLwAzO86edIJQNPNsC9eJhIERDos9ZhPrCYPDEckQdYdEc-CRyFRoAwQAAvAPiQgADyOJ1CABonJ0MVQEZBSF6AJ7wXgPJ4GAD00CdkXJewO7rjv06ADYa6RSHXkgLsJzOHNUH7CBHfpNzP9zIDoOZbikABJ50lCMu9mIAXUSwLB3PQD0ycnI+hUg6AA]

The diagram shows basic client onboarding flow for a new client of an advisor. Notes in orange and red highlight problem spots we identified in our original design. We refactored those elements of our architecture to consolidate data around a single source of truth and clearly delineate client and service roles in our architecture thereby simplifying development.

This is really a discussion of cost-benefits and strategic trade-offs. We refactored the two applications involved around a strict client/service relationship bounded by a conventional REST API. This required delaying release of the product by 3 or 4 weeks. But it ended up a paying off when, a couple months later, we had to swap out our backend custodial service provider due to an unexpected shake-up in the online broker industry.

What I find especially interesting is, in the wake of this project, I encountered similar bottlenecks or anti-patterns at two subsequent companies where I worked. The first I dubbed "mind-reading-as-a-service", the second "workaround-driven-development". In those cases, lack of clear service boundaries together with organizational politics made it hard to acknowledge the issues and was the source of ongoing complications in development.

Describe the process you used with your team in deploying a major product feature.

In brief, work with the product owner to break it down into milestones (if it's big enough to warrant them) and provide estimates on those. Break those milestones into user stories. Each user story should represent a unit of work ready for release upon completion. Milestones are mutable, user stories immutable (once development starts). Release continually: my teams usually work in two week sprints where main branch is released at sprint's end. If we need to defer the release of certain features or want to release the feature selectively for live testing, we use feature flags.

If the feature crosses teams, that will require additional planning and coordination up front. Important lesson I've learned: clarify boundaries and organize development around a client and service. Service team ultimately owns the terms of service.

If something else is meant by the term deploy here (e.g. the process of actually deploying the completed code) or you'd like to dig deeper into the process outlined above (say, requirement gathering or user acceptance testing), I'm happy to discuss that.

How do you determine shipping confidence? what tools and/or process do you rely on?

A deliberate crafted ever-improving process organized around automated tests, continuous integration, user acceptance testing, and, when needed, postmortems.

Services like Bugsnag and Datadog have also proven useful and allow our team to measure performance of our apps with greater confidence.

What does testing mean to you? Why is it important and when have you done it?

Testing is critical. For both understanding and even explaining an application and for guarding against regressions. In my last role, lack of tests with legacy apps was one of our biggest challenges. With tests, I try to focus on two things in particular: majors specs/feature requirements and bugs.

Code review: What is this process like for you and the person being reviewed and vice versa?

On recent teams I've led, the process has been good. Good linting tools like Rubocop have eliminated a lot of the chippiness that I've experienced in distant past and read other engineers complain about. Our biggest issue was the time investment. We were always searching for ways to make it more efficient.

What are your thoughts on pair programing?

I prefer to use it sparingly. I've never worked for an organization that's done it full-time but I've read about them. One point I've seen noted repeatedly is how mentally taxing it can be. At the same time, it's often praised as a great way to get new developers up to speed and that's how my teams have generally used it.

In order to best run routine database queries on very large datasets, is it better to build the software in PHP or Python?

I don't have a ton of experience with very large data sets. Where I do, the software was already built and used Python. So I'd be inclined to go with Python. In my experience, PHP is oriented toward web application development and Python has better support (tools and libraries like Pandas and Numpy) for processing large datasets and configuring the sort of backend processes where these queries would likely be run.

A cursory Google search seems to bear this out:

PHP was designed for web development at its core... On the other hand, Python comes with powerful functionalities that are hugely suitable for building apps based on AI, ML, data science, Big Data, etc. You have various options available for libraries like TensorFlow, Theano, Pandas, and more.

https://kinsta.com/blog/php-vs-python/

What are your Career Goals / Aspirations? - Where do you want to be in 3/5/10 years?

I'd love to be at the same organization. Not one necessarily focused on hyper-growth but on sustainable growth, investment rather than extraction or exploitation, and the well-being of its employees.