project interviews [part 2]

Aug 5 2025 · 7min · leadership, career

vibe check

When I interview Senior candidates, I don’t like giving take home projects or whiteboarding gotcha problems, and pair programming feels like testing a candidate’s ability to perform under pressure more than representing how they work day to day. Instead, I focus an hour conversation on two projects that the candidate has led or significantly contributed to. The first is their favorite or most successful, and the second is their worst experience or least successful project.

the interview

I’m going to just give a bit of a script / story about how I would approach this as the person being interviewed, in order to give what I think would be a good example of the worst project I’ve ever led. Like in part one, it’s a real project, and the answers are how I would answer a similar question.

Interviewer (I): Quite a lot of good information in that last one, thank you for sharing. Now we’re going to pivot to your worst project. We learn more from our failures, so let’s focus on those learnings, and don’t shy away from sharing the details. You won’t get penalized here for being honest, we’ve all had projects blow up in our faces.

Candidate (C): That sounds good. I’ve got one that I look back on frequently, and it’s one of the first large projects I led as an Engineering Manager. To set up, when I worked at ActiveCampaign, I was the Engineering Manager for the Automations team. This was the core differentiator of the platform, with three teams focused on it. Since I was a front-end focused full-stack engineer, my team handled the majority of the UI, first in Ember.js and then leading the charge into React. So immediately I wanted to rewrite the entire front-end for our Automations builder.

I: Oh no

C: Yep. This thing was in PHP and jQuery, it never even got moved to Ember, and it was awful. It was slow and janky for our customers, and we regularly dealt with bugs there. Then we were hiring React devs and throwing them into this terrible developer experience that slowed everyone down. We were getting a lot of pressure from the SLT about development being slow constantly. I started gathering information and getting buy-in, both in delivery speed and when we could get the rebuilt system out the door. Man, I sold that like crazy. I reviewed with my other engineering manager at the time, who was not a front-end dev, and everything sounded great with the timelines. I finally got our VP Engineering and my director into a room and sold it. Everyone signed on to a three-month big-bang project. Surprise, it was definitely going to be longer than that.

I: How big was your team?

C: I had four to start, and we hired a couple more through the process, eventually having somewhere around 8 total engineers. The issues started showing up immediately, and every one of them could have been avoided if I thought through things then the way I do now.

I: Anything else about the stack or the people I should know to set the scene?

C: Sure thing. I can start with the people. I had one engineer that I thought highly of and wanted to put up for senior in the next round, so I gave her the project to lead. I had a couple of mid-levels that were solid and had worked in Automations for a few years. And the first person to come onboard was mainly a back-end integrations engineer, but he seemed game for front-end, though he definitely had reservations about working entirely in front-end. As a quick aside, that guy was great, but he came on to my team as a surprise his first day and we changed his entire job expectations. I should have seen the red flag and fought to get him into a role he wanted, but he was a friendly guy that I thought would find his fit. Which he did, at another job. I could have kept him at the company by really listening, but i didn’t. I knew better.

I: Sounds tough. I take it you learned something there?

C: Absolutely. One-on-ones are especially important, but also setting clear expectations and following through. Even though I was talking to him every week, I don’t think I was taking his frustrations seriously enough and acting on them.

I: That’s unfortunate and pretty common. We’ve got some good insight about the project setup now, so talk more about the project itself.

C: Sounds good. We’d just gotten buy-in, we were ready to get started, so we were having meetings pretty regularly to figure out the approach we’d be taking. One of the first questions was state management. To redux or not redux? We started out without it, since the documentation itself pretty much came out and said “don’t use this if you don’t need to.” So we didn’t. The team gets started and I’m doing all the product management and story planning for it, with my trusted project lead estimating. This goes on for a few sprints, and I notice a lot of “progress” but not actual progress. I start digging, and it turns out, maybe we should have used Redux after all. To shortcut this, we switched in and out of Redux a couple of times for a few reasons. First, I didn’t actually understand the project and requirements because they were “make it like it is now but in React.” Second, we had a lot of strong, uneducated opinions in the room: me, my project lead, and the guy that didn’t want to be there but was a senior. My failing here was that I didn’t control the narrative or zoom in far enough to actually figure out that we were drowning in abstraction. And I definitely didn’t support my project lead nearly enough.

I: Wow, that sounds like a complete dumpster fire.

C: Absolutely. So I did the one thing that I probably shouldn’t have. I started grabbing up front-end engineers from around the company. They wanted to work on the project, and everyone liked me as a manager who protected and nurtured their team. So I didn’t have any trouble at all bringing more people onto the project, a lot of whom were also senior. Eventually I had twelve engineers under me, and not a single thing improved.

I: Mythical man month?

C: Basically a textbook example of it. Finally when I got everyone together, we went back and really looked at the scope, the libraries and proofs-of-concept we would need, and came up with a new timeline. A year. Maybe more. As soon as that timeline came through, all buy-in stopped. We started getting pushback and other projects to work on. People started getting frustrated, both on and off the team.

I: Did you manage to salvage it?

C: We went on to do some great projects, including building out a new way of working with SRE. This albatross hung around my neck and prevented me from moving up, so I and most of the team ended up leaving before that project was done. I found out that it ended up launching in early 2024, around five years after I had first pitched it. It was an unmitigated disaster that taught me so much about project planning, big bang versus incremental delivery, listening to your team, setting clear expectations above and below, and how to actually coach and mentor someone instead of throwing a project at them and walking away. I definitely could have used more guidance as well as I never got any actionable feedback, but I should have also asked more clearly.

I: So it seems like you’ve really had some things blow up on you and you’ve learned a lot. How would you prevent that from happening again if you started here?

C: First, always incremental delivery. A project that has a team go away for six months almost never works out. I’ve seen it played out in other teams and other companies after, but I always push for a small delivery that we can iterate on. It doesn’t have to be even a small delivery to end users, but something that we can show and get feedback on, then move. If that piece is taking too long, then we figure out why. Second, having the right people. You can’t just throw a project at someone that you think is ready and let them drown. Take extra care, even if they’ve delivered a hundred projects before. Don’t just ask for status updates (that’s what jira is for), but talk to them about how they’re handling things, where they’re strong or need help, and then help them skill up. If you can’t help them, find others who can. Finally, I’ve realized that even though I’ve been through a lot of things myself, the network you build around a project is more important than the tech. If you can get someone in leadership on your side, and if you regularly push information before your boss or higher ask for it, and if you provide a place where others can pull information, the timelines seem to matter way less. Progress, learning, reasons, and the ability to always answer the status update questions built trust and confidence that allow you to deliver incrementally without interruption.

I: Thank you for feeling comfortable enough to share such a deep story where you clearly made mistakes and learned. I appreciate that you didn’t try to minimize the situation or turn it into one of those “my greatest failing is that I’m too honest” conversations.

and scene

Again, I’ve taken some artistic license and narrowed the scope of a much longer chat. But I tried to highlight that the benefit to this conversation is being open and honest that you failed in some way and how you learned from it. Someone who comes in with a fake story that is clearly minimized because they’re afraid of admitting failure just isn’t a valuable insight. You’d probably get a declination from me immediately.

From the interviewer’s side though, you have to very clearly provide a safe, trusted space for the candidate to air this out, and it’s your job to find the growth underneath. Then, when it comes time to evaluate the candidate, you can’t hold anything (that’s not unethical or illegal) against them.

For those reading this who might be on the other side of the table from me someday, treat this as my show of good faith that I really do want to hear and share the actual bad stories.

Quick reminder, this is part two of my Project Interview setup (see part 1 here). During these interviews, I take one hour with a candidate and talk about the two projects back-to-back. This is in lieu of a technical pressure test interview, and it mainly works for Senior level candidates who have been through some stuff. Your goal is to dig deep and find out how someone thinks, works, and grows within their profession.