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

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.

Tell us about a time you received feedback that was accurate but tough to hear? What was it? How did you respond to it?

Here's an incident involving some uncomfortable feedback that ultimately proved instructive. While I was heading Engineering for a fintech startup, I read an interesting book on sleep, Why We Sleep. For our team's quarterly all-hands meeting, I put together a short presentation about it. At some point in my presentation, I made a joking offhand remark, something like, "This is information that Tucker Carlson and Fox News doesn't want you to know." I may have referenced that guy who does the pillow commercials.

One of the engineers on my team brought it up at our next 1-on-1. I share a Google document as a running agenda for these meetings. It gives me and the team member I'm meeting with a chance to drop notes to discuss before we meet. Here's an example:

• 1-on-1 Meeting Agenda

As I was reviewing it just before we met, I noticed he had added a bullet point to the top of his section of the agenda stating that the comment had made him uncomfortable.

I'm glad I caught his note before our meeting because my first impulse was to say, "C'mon" and ask him if he was serious. But a moment's reflection allowed me to check that reaction. The engineer in question is fairly circumspect and easy-going so I reasoned it must have legitimately bothered him for him to bring it up.

When we met a few minutes later, I started by saying, "I read your first point here and I agree. I apologize for the remark. I'm glad you mentioned it. Sometimes my tongue is quicker than my judgment. I'll do my best to avoid making this mistake again." I could see that he was relieved by my apology. He thanked me and we proceeded to the next bullet point.

The matter didn't come up again. Since then, I've been slightly more cautious about how I about express myself around teammates or on Slack. It hasn't been hard. I recognize my sense of humor tends toward the sharp and oblique. (My favorite episode of Black Mirror is the first one.) So I found a simple heuristic: if I find something amusing, I should probably keep it to myself. Sometimes I even do!

The engineer in question went on to be promoted to a team lead and, despite some initial anxiety, did a great job.

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 continuing to help it build great products for its users while promoting the well-being of those with whom work.