Inside the Zus Engineering Hiring Process

1 – Was this a hard problem?

At different levels, the hardness of a problem is different.  And the hardest problem you’ve ever dealt with is the hardest problem *for you*. And it’s probably hard, not just because you learned something new doing it, but also because it wasn’t necessarily something that was queued up for success.  There were likely big unknowns, risks, tricky organizational situations, and other problems.  That’s actually what makes the problem a great discussion point.  I find that one common failure point for candidates is coming up with a presentation about a problem that got solved flawlessly.  In my experience, if your problem/solution pair is flawless it means either it wasn’t that hard – either it was well-within your existing experience or you had an awesome team/manager/company backing you up – or you have glossed over and avoided the very interesting parts that are most useful to talk about – the adversity.

Here’s a breakdown of how I think of hardness vs. role:

• Software engineers – are learning a LOT – problems may be within a team and are hopefully within a supportive team context.  But the candidate is leaning into a learning curve, dealing with big unknowns like never having worked with a specific tech before, or taking on a more ambiguous piece of work.  It’s totally normal for that to require team support like discussion with a team lead or other SME, trial and error, multiple rounds of iterative development and hard feedback – all good stuff.
• Senior engineers – may be taking some of the biggest & hardest tickets within their teams, or are working across teams.  May be guiding others.  May be working on something big under the guidance of yet more senior folks.  Might be working on something that can take a month or more to accomplish, or might be something that is high pressure for days to a week, but with a massively critical type of impact.  Should also know why what they did matters, and should know the tradeoffs in the chosen solution.  Calibration on this can be particularly tricky, because some companies can have very prescriptive choices that engineers work within, while Zus definitely expects independence in this role.  I like to think, that any senior engineer is tackling some form of serious ambiguity and showing us where that was, why it mattered, and you figured out your path is very likely to be the core of the presentation.
• Staff engineers – had better be having impact beyond themselves.  If this challenge is a week long endeavor. that had better be one heck of a challenge.  It might be.  I’ve seen engineers at this level save companies from very serious issues, by wrangling a few teams, using their clear communication skills, technical wisdom and organizational trust to accomplish something profound in days.  But in  my experience, that’s rare.  I often find people are better able to describe the serious impact of the staff engineering role when they are talking about a project measured in weeks to months, that involves more than just their own work, and which seriously changes the company’s ability to deliver engineering value relative to the business.  Note that this isn’t a supervisory role – impact is usually mentoring, setting technical direction, and influence without authority.  But to me, the staff engineer role is the turning point where an engineer starts to multiply what they get done in a day by not only writing fabulous code, but in setting up others for success through wisdom, good practices, design skills, leadership by example and being that guiding light to others.  And that’s what I hope to see in the panel.
• Manager – 100% not working single-handedly.  This one is often the trickiest, because it needs to be a good solid technical challenge, but one where the person is probably NOT the biggest hands-on force.  Instead, a manager has to really understand the technical risks, but also be leading the project, doing the project management, and showing good stakeholder management skills.  It’s a lot to cram into a half hour if you’re doing it right – you’ve got to cover why this mattered to the company, what was the technical nature of the problem, where could it have gone wrong (where did it go wrong?, getting everything perfect is almost never reality), and how did you and the team work through challenges.  Don’t worry about giving us your CV or a huge backstory – let’s get into this cool hard problem!  The biggest difficulty I’ve seen with manager candidates in particular is that this isn’t a sales pitch, it’s a project retrospective to a group of not-on-the-project people.

2 – Do we understand them?

In all cases, the panel is also attempting to gauge your ability to work with a team.  Your day to day work at Zus is collaborative.  We know that engineers will have to talk about problems with tickets after scrum, present incident reviews and design summaries at engineering wide discussions, and talk to other stakeholders and other leaders about project issues, risks and other challenges.  At every level, the way we get through tough problems is to discuss and combine good ideas.

So, bottom line in the panel is – how well did we understand what you were trying to convey?  If you’re trying check boxes on this, here’s some questions you may want to ask yourself as you prep the presentation:

• Why was this problem hard?  What were the limitations that you or the team had in front of you that make this notable?
• Why did solving it matter?  Was there an impact on the team?  The product?  The company?  It’s customers?
• Will people understand the steps toward the solution?  Diagrams, tables of tradeoffs, major steps on a slide – often this is where a visual thing to point to becomes most important.
• What was the definition of done?  How did we know we were done?
• How did it go?  What were the issues?  What were the surprises?

This is where one good, hard (enough) problem clearly and succinctly presented is going to do 100 times better than trying to throw a bunch of problems on the wall and seeing what sticks.  I’ve been absolutely fascinated by a bunch of the problems people have brought to us and the common thread is that I really understood why it mattered and why the solution was built to get that important thing done.  

Let me at least try to take some pressure off here – we’re not looking for professional public speakers here.  If you happen to have that skill – great! – but we realize that we’re hiring people who are hopefully very comfortable writing code and reviewing it, and talking to trusted colleagues about it.  And way less comfortable giving a public presentation to a group of people they barely know.  We’re going to do our best to calibrate for that – I’d much, much rather have a presenter who is clearly very nervous, but excited to share something they find really and truly interesting, than a super polished presenter who is either disengaged or has nothing interesting to say.  Please believe that we’re on your side here, and we want to learn about this hard thing you’ve done, because we like doing stuff like that too!!

3 – Q&A

In all honesty, when I listen to panels with my team, my biggest worry is a panel with no questions.  It either means:

• The team is utterly confused or utterly disengaged (maybe both) and haven’t found a thing to grip onto to ask a question about.
• The team is stunned with amazement at how great this panel is, and the panelist keeps answering questions before they can even be asked because they are just THAT good.
• Our best question askers missed today’s panel and everyone else should have drank some coffee before this meeting.

So first and foremost – realize you are already in good shape if you are getting questions.  Don’t stress out that you missed something.  So, so many times I’ve seen us get engaged and ask questions a slide or two ahead of the answers.  In my mind, that’s a great outcome – it means we got so engaged and excited we couldn’t contain ourselves.  And we do like asking questions mid-presentation.  We’re not trying to startle you, it’s just really hard to hang on for too long if you really want to know something.

If you’re new to presentations – here’s a polished presenter’s trick – take a beat.  Pause a sec, collect your thoughts, figure out what you want to say, and then say it.  I can almost guarantee if you take a single breath and let it out before answering you’ll have come up with a shorter, clearer answer than if you don’t.  It’s also a great chance to get yourself a little extra oxygen.

Do pay some attention to time.  We have an hour.  We ask for a half hour presentation, in part to give time for questions to come up during the presentation, so if you’ve got a good sense of timing, you should see that you’ve got the slack you need to easily answer 5-10 minutes worth of questions and still fit easily into the hour we’ve blocked.  That’s the method to our madness.

4 – Any questions?

By the time you do a panel, you’ve hopefully gotten asked this many, many times.  It’s because we’re excited to explain why we love Zus and we want to get you excited. 

So – it’s perfectly alright if you have run out of questions at this point.  Some folks nail down all their questions early on, some are only just evolving questions now.  There’s no wrong way on this one.

I will say – this is the one spot in our hiring process where you get a chance to read the room.  It’s hiring managers, team members, maybe even cross-team groups.  It is the most diverse perspective set you could get in any interview, and the one where you can see one person answer and another person make a face.