project interviews [part 1]

· 6min · 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.

setting up

Communication here is key. The candidate performs better if you set the right expectations before the interview. Here’s an example email I recently sent to a recruiter:

[Candidate] should have at least two projects (full features, with both good and bad outcomes) that they can talk about. What did they build, what were the struggles, outcomes, and lessons learned? Again, this should be a technical conversation, and I should leave understanding their skill as a Senior Engineer delivering value or learning from failure. This can be paraphrased as the best and worst projects or features they ever worked on and why.

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 my favorite project I’ve ever worked on. It’s a real project, and the answers are how I would answer a similar question.

Interviewer (I): “Let’s spend a couple of minutes going over the interview format as a refresher. We’re going to go through two projects that you’ve done at a company, preferably as a leader. We’re a technical audience, so go as deep into the weeds as you can, we want to know how you approach a project and deliver it. This is also a conversation, so please ask questions throughout and don’t feel like you need to hold them to the end.”

::generic introduction noises::

Candidate (C): “My favorite project that I ever built was for the agency I worked at, L2. They specialize in building websites for symphonies and theater companies, and this one was for a client called Woolly Mammoth. They came in as a client needing a full site rebuild, with custom seating reservations and checkout, which is something we specialized in through a partnership with Tessitura.”

I: “What was the goal of the project?”

C: “Scrap everything and build new, but they were…quirky. They actually were amazing clients, they told our designer to be as creative as possible. Their color palette was wild too.”

I: “So a complete rebuild, sounds like a big project. What was your role?”

C: “I was a front-end engineer on the project. I usually worked with a designer and backend PHP developer for these builds, but we’d just lost a backend dev and were short, so I said I would do the full-stack. We also had a project-slash-product manager who communicated with the client and handled the business side.”

I: “Tell me more about the stack.”

C: “We used a proprietary PHP CMS that was built a few years earlier. It ran fine, but it was all custom. So every build was basically starting from scratch implementation. We used jQuery on the front end, with normal HTML and CSS requirements. No bootstrap or foundation, and no Wordpress or off the shelf stuff. They migrated to that later after I’d left. We deployed with scripts to AWS, but I didn’t handle really any side of that, and it was really easy to overwrite things accidentally.”

I: “Did you use git?”

C: “SVN, or subversion. It was actually the second place in a row that used SVN, though I think they were moving to Git or something similar. I wasn’t really part of that, so I don’t remember details.”

I: “Okay, back on track then. You were going to handle the entire build out of a custom site? That sounds like it wouldn’t go well.”

C: “It’s my favorite project, and it did end up being successful, but it wasn’t a smooth ride. For example, I learned the hard way to understand product requirements before starting to code.”

I: “Go on.”

C: “Well, I got the mockups, and they all had the same background image while the content changed. The company had these huge, beautiful images that took up most of the screen. I interpreted that as what would now be a single-page application. I had been reading about frameworks like Angular, and knowing we weren’t going to switch I started building a custom client-side router in jQuery. Which did work, but it turns out I misinterpreted everything. When I was showing off all my work, the designer told me that the image was a placeholder, and we need to have relevant images on every page. And that those images need to come from the CMS.”

I: “So you built the wrong thing?”

C: “Absolutely. It was the first time that I realized if I wanted to be a better engineer, I needed to do the leg work before coding. It was the beginning of what I now refer to as ‘heads-up development,’ and I’ve told every team I’ve managed that they need to do the same.”

I: “With a custom build, you had to have tradeoffs too, right?”

C: “Yeah, one of our biggest was that Tessitura only returned information in XML. Our whole ‘pick your seat’ implementation relied on this data, so again everything was super custom. The biggest tradeoffs we continually had to make, not just for this project, was that we couldn’t really make templates. We had to manually copy things and then customize them.”

I: “But that was on every project, which you knew. What did you have to trade off in this project, specifically?”

C: “Well, for this one they wanted to have full page images that you scrolled on the homepage, like a carousel that was vertical and full page. First time I’ve used VH, actually. So the technical tradeoff here was that the CMS preview page was basically out, and we had to build this custom interface form that they couldn’t see until they published it. There were lots of these little places where we had to sacrifice the perfect design for something functional.”

I: “I think I understand now. How did the project turn out?”

C: “We launched the site, with a couple of follow up projects and change requests. I had to build a donation page, which was one of the times I asked questions because I learned, but then the client changed their mind after I built to spec. We built that donation widget three times, basically. But to your actual question, they were happy with the result. Last I checked, they did another site rebuild and stuck with L2 for it. I left pretty soon after Woolly launched and their team took over, but I would consider it a successful project that made me a better engineer. That, and it really was a fun build that stretched my coding skills to the limit.”

I: “What would you change if you had to do that project again?”

C: “So I’ve worked for a bunch of capital-a Agile companies since then, and there’s definitely a way to bring some of that to what really is a waterfall project. Each step of the way, the client needs to see the progress and sign off on it, and the developers need to understand why they’re building something the way they are. Clients have a vision, and I would want to spend more time understanding the vision before I built something wrong again. But also when I built it right, I’d make them say so in writing. I think I would also have less ego on wanting to force things into a legacy system that for all intents did work and was the company’s backbone. I wanted to make new, cool things, and I didn’t appreciate the code that paid my salary.”

I: “Thank you for sharing all that with me. It sounds like you learned a lot about how to work within teams and about yourself.”

C: “I did. Like I said, it probably isn’t the most successful, revenue-driving, conversion-improving project I’ve done, but it’s one of the foundational projects to my career.”

and scene

Obviously I’ve taken some artistic license and condensed what should be about a 25 minute conversation, but this closely represents how I’ve told this story I get asked about a favorite project. I love this example in my own career because it has echoed through every role I’ve had since.

With this approach, the interviewer learned that I can commit to and finish a project, step outside my comfort zone to get something done, and that I’m willing to admit mistakes and grow. It also doesn’t sound like a fluff project that has a bunch of vanity metrics on it. And because I wasn’t managing the project, the interviewer focused on my own growth and outcomes. Should the interviewer be worried about my syntax, or understanding how dependency injection works? That’s mainly up to what matters most to the hiring manager and the team, but in my experience someone that I am interviewing for a Senior will either already know or be able to quickly learn anything I’m trying to find out.

To repeat though, the candidate has to be prepared for this conversation. If put on the spot, they’ll default to something simple that they delivered with fanfare and all the accolades, but you really might not actually learn anything valuable here. Good news, though! The follow-up question is about their worst project, and this is where the real insights come.

In part 2, I’ll give an example of my worst project, and how owning failure can tell an important story.