Overview

If you’re working through the Zus engineering process, here’s what it looks like as of 2026.

• Recruiter reach out – one of our awesome recruiters is reaching out to you.  Maybe you applied (we do read them!), or from a search out there on the Net, or you’ve already got a friend or colleague in Zus and they’ve referred you.  Our recruiters work closely with hiring managers like me, and we do our best to pick out resumes and online profiles that look like the kind of team we’re trying to fill.  The goal here is to make sense of your particular skills and interests.  And to align, vaguely, on price (ie, salary, bonuses and benefits).  If what we want from each other, salarywise, is vastly different there’s really no point in scheduling the hours of interviews yet to come – it’s an unreasonable investment for both the candidate and the team.
• The Hiring Manager Interview – Personally, I see these as 1 part sales, 1 part evaluation.  I want to make sure that you, the candidate, is excited about Zus, its business, our team’s engineering challenges, and me as a leader.  And I want to figure out if the challenges you’ve taken on in their career are reasonably similar to the kind of thing I’d expect someone in this role to be able to take on.  I’m NOT focused on specific tech, but I am focused on the general discipline of distributed systems engineering, microservices, and designing services that process a whole lot of gnarly data.  And that you have taken on the level of ambiguous challenges that I expect at a given role.
• Code and Design Interviews – two separate blocks, often booked back to back, to see what a candidate’s hands on skills look like.  We’ve done our best here within the truly fake context of interviewing to try to simulate a work-like situation, even if it’s extremely condensed.  My general take – a more junior engineer should be able to do reasonably well on the code, but may flounder more on the design, while it’s vice versa for managers and more senior engineers.
• The Panel – we ask you to present for ~30 minutes on a specific challenge you’ve taken on in your career.  We assemble a team of engineers from the group you’ll be working most closely with, but we also open the invite to more folks in R&D (that’s engineering and product management) and we do get interest from other teams.  More on this one, next.
• Reference checks, and negotiation – As we start preparing an offer, we ask for 3 reference checks (one from a former supervisor), and start getting serious about the specifics on money and start date.  We actually do call those 3 references, and try our best to have a somewhat analytical process for thinking about the always-glowing feedback they give.  It can mean that we don’t go forward with an offer, unfortunately

The Panel

I got into writing this article because of the panel.  Every stage of the bullets above is a yes/no decision process.  We may stop the process at any of these stages, and so as a result, our hiring process is not a speedy one.  That means that by the time a candidate gets to the panel, we’ve all spent at least 4, usually more, hours talking to each other.  And the panel itself is an even BIGGER time investment, since the candidate + at least 3 other members of Zus’ technical team participate in the panel for an hour.  And it’s probably the hardest to evaluate and the part of the evaluation that is most likely to make us all debate our process.

And yet, I think it’s really useful, and so I want anyone reading this to have the ultimate, most informative, leg up to how we think about it, why it matters, and hopefully how to rock it.

Here’s what we end up evaluating for, and also where I see that candidates have the most problems.

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.

Good Luck!

If you’re here reading this at the end thinking “meh!!!  Beth still didn’t tell me how to pass this interview!!” – well then I’ve done my job.

My goal wasn’t to give you Beth’s Super Guide to Acing Engineering Interviews at Work – as awesome as that title is.  My goal was to give you some insights into the hiring process and help you prepare.  I’m hoping to ease a bit of tension and reduce some ambiguity on what we look for.  But to offer a perfect recipe would be impossible, because it doesn’t exist.

At the end of the hiring process, there’s me.  Looking at all the information we gathered through the process, trying to figure out – “is this person one of people who would be right for this role in Zus?”   And honestly hoping the answer is yes.