Categories

  • blog

I recently completed an either 9 month or 2 month search for a new job, looking for Staff-level engineering positions for the first time in my career. I live-snarked much of the process on Twitter and heard that was helpful to some folks who are also thinking about starting their first Staff-level search. Some reasons this blog post may not be interesting or ring true to you:

  1. I only talked with ~10 companies and chose to proceed to final interviews at 4.
  2. I was primarily targeting companies with engineering departments in the 1,000-2,000 employees range. I didn’t interview with a single FAANG company.
  3. I don’t have a CS degree, I don’t think Leetcode-style interviews are any kind of indicator of job performance, and I think you can be a successful Staff engineer and never write a line of production code in that role. I know and understand why folks take different stands on these points, but they’re where I’m coming from when writing this post.

Everybody defines Staff differently

Let’s start with something as basic as titles. Every new company I talked to meant diving into their levels. Is there a concept of Staff-level titles? Is “Staff” literally a title, but there are additional titles that comprise “Staff+” ranks? There’s a ton of variation.

Next, not only does each company have different assumptions about what Staff means, there are likely many variants of Staff-level work within a single company. Will Larson does a good job of outlining four different archetypes for Staff-roles, although these are more valid for small/mid-size companies. I took a shot at outlining archetypes at Salesforce (50k employees). It’s likely that each company and even each manager you talk to will have assumptions about what combination of skills they’re hiring for and an inability to articulate them.

There are some basic questions you can ask to get a better sense of the role without ruffling any feathers. You can ask if the role will involve writing production code or not. Does the role do any programming at all? If it’s mostly prototype code, find someone in the role currently and ask how much time they’ve put into a recent prototype. You’re looking for whether they talk about days, weeks or months: how much time will this role spend programming (production or prototype)? For the rest of the work, will the role be meeting heavy or writing heavy? What authority does the title provide and what is it expected that you build up as informal influence?

Every team and company interviews differently

Like most engineering roles, there’s no perfect nor standard way to interview for the skills that Staff-level folk need.

The most common approach is to send Staff-level candidates through the senior interview process and expect the candidate to “A+” every interview. There are a couple frustrating aspects of this. One is that many Staff-level roles just don’t require upkeep of the same technical skills that seniors need, so you will be evaluated more on whether you were willing to prep for technical interviews than anything that indicates job performance. The other is that you may never get an explicit interview for Staff-level skills (interfacing with product, technical leadership, shepherding cross-organizational efforts, coaching & mentorship).

Because I only interviewed four places, I didn’t pick up on interview patterns. Most of my technical interviews were clearly testing a base level of competence, collegiality and willingness to go along with the unpredictable scenarios. However, I had one particularly interesting approach where they tried to test Staff-level skills within technical interviews by expecting folks to call out the interviewers on the vague requirements and push for clarity. Needless to say, I lack the guts to successfully do that. This is, however, a more common strategy than I would have guessed. Reflecting back on the experience, I think I would be able to identity whether a company was testing the ability to roll with unclear requirements or testing the ability to push for clear requirements, but I’m genuinely not confident. Some folks do “warm up” interviews with companies they don’t particularly care about to help with this. I didn’t have the energy or interest in doing that.

For companies that do Staff-specific interview processes, I got a lot of slight modifications. I’d still have one or two pure technical interviews, but it was often framed as “Just get through it so we know you’re not completely bluffing.” I would get the hardest design and behavioral interviews, often administered by folks who seemed pretty senior. At a few places, I made it through the full interview process without speaking to a single junior or mid-level engineer.

One company added in a management behavioral interview to my process, which was great! I’d strongly suggest companies consider adding some parts of their line-manager interviews to Staff-level processes. This was the only place that really dove into key parts of a Staff role: How do you grow people? How do you manage conflict? How do you build influence? Do you know which hills you won’t die on and how to retreat?

Besides the management behavioral, I had some other interviews I’d recommend:

  • Pair with a junior person. Either you or they have all the context, so you’ll be evaluated for how you handle a dynamic you’ll see every day on the job. This was both a ton of fun and a really good way to make sure I could program while not being an asshole.
  • Present on something you want to explain. This was such a good way to test communication ability and also whether you could say “I don’t know” when asked follow-up questions.

My absolute favorite were design interviews that were an only slightly simplified version of the team’s most recent technical challenge or major product feature. It helped them assess on 1) did I actually care enough to prep to know their product? 2) did I actually have the judgment they’d want? Especially when the title you would come in with brings some degree of authority, it gives future teammates the option to tank me if they just don’t think they would trust my judgment. Most importantly to me, these interviews helped me assess where the team was in terms of maturity and engineering quality. Where were they assuming that corners should be cut? Did I get nods and laughs when talking about certain scaling issues or intense, quiet note-taking?

Beware of too many modifications: One company I interviewed with decided to do a Google-style process, where they interview you generally and then consider what team they might place you on. This seemed to end in confusion on all sides (certainly on mine) as the work and skills for a Staff-level engineer vary based on team and manager. Since I didn’t know who to calibrate for, I had to interview for the whole rainbow of Staff-level roles I could possibly fill. It would have been better for everyone to have a conversation up front.

People hire out for team leads frequently. Other types of Staff+ engineers, not so much.

It’s relatively common to find jobs for “Team Lead” Staff roles. I’m not talking about the management variety of the title, but rather the role of senior-most individual contributor on a team with a line-manager. Common responsibilities would include mentoring junior engineers, taking on the leadership of the team’s latest major launch/refactor, fixing the performance problem, etc. Typically, the company is hiring out because the team is new, the team is growing or the team experienced a recent departure and no one is able to step up.

It’s a lot harder to find companies hiring out for roles with scopes of responsibilities broader than a single team. Every opportunity that was not vanilla team lead came from reaching out to my network. Even then, at most places I spoke with (not just interviewed at), I had a connection. At two of the four companies where I did full interviews, there wasn’t even a public listing that I was applying for.

Because these roles are not frequently hired out for, I had a lot of trouble talking with recruiters and some hiring managers about what I’m looking for. The mere mention that I was considering roles at other companies where I would report to a manager of managers caused major confusion. Even though I tried to be clear that I was open to range of different interpretations of “Staff”, I got a number of “I’m sorry, we don’t think we have a role for you in our company until we grow larger.” Since those companies all had people reporting to managers of managers and I was absolutely excited about roles reporting to line managers, I have now learned to interpret what I hear through these lenses:

  1. Many places just don’t hire out for those roles.
  2. Because the never see those roles, Recruiting isn’t even necessarily aware that folks fill those kinds of roles in their organizations.
  3. When a recruiter asks, the only right answer to “what are you looking for” is the role they have in mind for you, so try to hedge as much as possible until you understand what kind of Staff-level engineer the hiring manager is looking for.

To avoid making it sound like you’re not a good fit, I’d recommend trying to talk to hiring managers about their technical background before talking about how you see your role as Staff. Especially for managers who came up through the company, they may not need or want a large segment of the skills you may bring as a Staff engineer. Some of what I bring to the table sounds suspiciously like management (that’s because it’s leadership :tada:) and line managers especially can feel like you would be stepping on their toes. Getting your “Here’s how I complement management” statement right for that company and for that manager can solidify your candidacy as someone being hired from outside the company. Getting it wrong is the fastest way to tank your candidacy without explicitly failing an interview.

If you’re going to try to poke around your network a bit, be aware even that can get awkward. Staff roles and responsibilities can morph quickly and unexpectedly and much of your network may be out-of-date with your current work. Contacts may need some gentle updating and if your contact comes with different opinions of what is and is not the responsibilities of Staff-level individual contributors, then you’re right back in the conversation above. Even gentle updating may still lead to awkward interactions, as people hire within their network because they think they know you. You having progressed or altered your skillset upsets that assumed knowledge of you, which can lead to unexpected conversations – and hiring within their network is not supposed to be unexpected.

In addition to whether they hire out for a type of role, there’s whether they’ll hire from outside their industry segment. Domain experience can be a critical aspect of your success in a Staff-level role. I’m actually not sure how comfortable I would be with coming in green to certain companies. I have 6.5 years of experience building team collaboration tooling around very large blobs of data (pictures/videos/container images and now git repositories) that have a ton of mutable state. Should an advertising systems team have been interested in me? Honestly, I’m not sure. There’s a massive difference between the architectures of managing the state for a product built to run thousands of containers indefinitely and a product that has very minimal mutable state but massive numbers of events around small bits of unchanging data. Users can’t unsee an image nor unclick a link, which leads to very different technical concerns.

There is a lot more Leetcode-style interviewing out there than you might expect

This totally depends on where you’re coming from, but if you’re coming from the part of tech that really cares about humane processes welcoming to diverse candidate pools, you may be a little surprised.

If you’re like me and agree that leetcode-style interviews don’t predict job performance, then you may be wondering “Why is this still the case?”

What I’ve seen suggests that the applicant pool can be so strong that tons of false negatives are accepted as the cost of avoiding false positives. This unfortunately means that the most popular companies can have the shittiest interview processes and then lots of start ups will follow suit because “Pick-your-FAANG is doing it!”.

For example, the interview I mentioned above where I totally bombed for not demonstrating requirements gathering skills, I didn’t get a hard no. Instead, I got a “Well, now that you know the interview process at $COMPANY, you might be able to ace your interview with another team”. It didn’t happen to me, but I have heard of even more blatant admissions by recruiters about the use of Leetcode-style interviews: “Just play along, we know these don’t actually impact job performance, but we get too many applicants, we’re happy with our candidate pool and it gives you a chance to show that you’re committed to $COMPANY by conforming to our process!” Accepting false-negatives (and even using interview stages as weedout processes) is absolutely a thing.

That being said, I would suggest considering interviewing at these places despite leetcode-style interviews being both stressful and a low indicator of success.

  1. It can be fascinating. The tech, the process, the roles: it’s all delightfully unique to those kind of organizations.
  2. The people are often exceedingly lovely and kind.
  3. You may have your ass handed to you, but you’ll learn about some cool stuff. If your ego can take it, I’d say it’s worth it.
  4. They’re great competing offers. One person found that by accepting leetcode-style interviews, they bumped their total compensation by 100k. Depending on where you’re at, it may be more than that.

It’s also worth bearing in mind that prep for these kinds of interviews may not be that bad. Yes, there are suggestions out there that you prep for 3-4 weeks, but you can get to the point where you can pass a decent percentage of them pretty quickly. I took a few CS classes and was able to do okay on one leetcode-style problem with only 110 minutes of study while unemployed. I got lucky that the question I was asked was similar to one I reviewed. Subsequent questions did not go as well with that minimal prep.

The study approach I used and was also recommended to me is to read the question, think about how you would approach it (but don’t write code), then read the answer and think about how your approach would have done. This way, you can get through about 2 to 3 practice questions an hour. With a couple hours a day for a few weeks, you may find yourself in a good enough place to pass most of these. Of course, from an industry perspective, this is still shitty, unacceptably privileged and a complete waste of your time. However, the financial benefit may be worth it to you if you can.

Depending on your background and confidence, you may be able to do a ton of these interviews and accept an ego-bruising conversion rate from interview to offer. You only need one high-comp offer to give you/your family the option of higher pay and more leverage with negotiation.

Some companies will be open to negotiating how you should be interviewed.

Especially for companies on the smaller size and for very senior roles at small/mid-size companies, there may be flexibility in the interview process. If this is first time the company has hired for this type of role, you may be able to present yourself as a partner in figuring out whether you’re the right fit for the job. After all, figuring out how to evaluate something (in this case, you) without clear success criteria is part of the job!

For slightly more established interview processes, companies may not be willing to remove interviews, but you may be able to suggest a hybrid IC/Manager process or simply add the interviews you need. If they’re not already part of the process, I highly recommend adding a skip-level interview and product person interview to help you evaluate the company and role.

If there’s someone you need to speak to be confident that you understand the job, the company should make those people available to you. Whether that’s further chats with the hiring manager if you didn’t get enough time with them, a sync with some senior engineers – if the company can’t make those people available for 30-60 minutes, that’s a red flag. Staff+ level positions are leadership positions, and you should be confident before you accept the job that within a short period of time, you’ll be able to start leading on challenges facing the team.

Interviewing is miserable but the people are amazing!

The best part of interviewing is always being invited in to see a narrow window of what a team of engineers is accomplishing and how they’re doing it. Interviewing was stressful and frustrating, but the people were spectacular, inspiring and so fun.

I started my job search with the advice to “Always take the interview.” You never know if the opportunity might be exactly what you didn’t know you wanted. And if it’s not interesting, at least you learn more about your marketability.

I ended the job search with absolutely no interest in interviewing ever again. It certainly doesn’t help that technical interviewing feels broken and unrelated to the job. However, given that I’ll eventually need to interview again, I’m focusing on how unbelievably lucky I was to get the chance to meet engineers doing great work. If you’re reading this and you interviewed me: thank you, talking with you about your work was the reward for all of this!