Things I learned interviewing for Staff positions (2020)

This should definitely be updated with a year (2020). This time period was peak "corporate engineering" culture imho. During this period I felt like a stranger in my own field.

In my entire career I had never cared about "leveling" and suddenly I found a world of people obsessed with it. Engineers were being hired en masse so your actual skills mattered little (you were going to be solving real problems, you were there to boost your managers head count), but your ability to "play the game" was everything. I figured out the rules, and had my bit of success but working in tech sucked in this time period (aside from comp). The worst part was that this infected companies of all sizes.

While you can still play the FAANG-game today if you want, it's increasingly become not required and I'm seeing more and more teams hiring people based on technical skills and the ability to solve real and actual problems. Weird smart people are starting to be in demand again (rather than pariah's because they couldn't perform the shibboleths required to fit-in). My last two companies had no "leveling" and were much better for it.

Hopefully we'll return to a time when people are exited for a role because it offers interesting problems to solve rather than chasing some meaningless career ladder.

Having trouble understanding what value this person brings to a company:

- Actively against writing any production code

- Doesn't want to make decisions (wants to report to another line manager - "absolutely excited about roles reporting to line managers")

- Lacks effort for "upkeep of technical skills"

- "lacks the guts" to request clarity of vague problem parameters

- limited scope. 6.5 years of experience in one domain. (6.5 years isn't nothing but plenty of people have 10-30 years of experience, over multiple areas/domains/industries)

I enjoy LC problem solving (but puzzles like Advent Of Code even more). However, I dislike the interviews that use these types of artificial problems, where the interviewer then only cares about an optimal solution no matter how ugly you wrote it. Once even had an interviewer tell me to “stop focusing on writing it nicely” because I wrote some type aliases (in Go). On the plus side, these interviews can also show you which companies you would not want to work for, as in the example I just gave :)

> Is there a concept of Staff-level titles?

Not anywhere I ever worked or consulted at, and the article never seems to explain what she means by it.

>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.

I think LC style questions which are frustrating during an interview process are best addressed by explaining to the interviewer why you think it's not applicable to you providing value were you to take the role and then proceeding to solve it as best you can calmly. Shows both willingness to participate in the process and staff-level critical thinking skills.

In my opinion, not being able to call out vague requirements is a red flag for any senior role, staff or not.

I call our vague requirements not because it's part of a certain process or something I read from a book. It's because I want to know what the heck you actually want because I want to double check your plan.

Heck, if a friend comes to me with a plan, my first question will always be "what are you trying to do?" because I don't want you to waste your time.

> One is that many Staff-level roles just don’t require upkeep of the same technical skills that seniors need

Im sorry, what? I just cant stand proliferation of this meme and ideas usually associated with it (“you don't need CS knowledge”, avoid writing code at all cost, “everyone has not idea what they’re doing”, etc)

I just applied for a staff level position at a large company and for the first time in my career failed a coding challenge. The feedback given was absolutely baffling and just goes to show it's really a crapshoot applying at these larger companies. If you get someone reviewing your code who clearly doesn't want to be there, doesn't know the language, and is too lazy to learn the absolute basics, then you're screwed. I've held numerous Head of Engineering and CTO roles, as well as several team lead roles prior to this. This is the same coding challenge that is given for junior roles, and is not leetcode. I'm just staring at the written response in disbelief. There's no path forward from here, bad luck, move on:

> Thank you for your submission. Your README was clear and concise, and included instructions on how to run the tests along with your assumptions and design decisions. You were able to analyse the requirements to produce a working solution, however the design was confusing, with components that interacted with each other in strange ways.

> There was a lack of test coverage on a domain model level. At a technical design level, the interface was not clear and confusing. This was due to not knowing where the main entry point for the provided solution was.

> We liked that you included an integration test for the scenario outlined in the exercise, however, we also found gaps in the testing, for example depositing or withdrawing with non-existent accounts.

I can't reveal the company or coding challenge details without giving away too much information. But needless to say the coding challenge specifically states not to implement a CLI or user interface of any kind. So when the reviewer couldn't find the entry point, what they really meant was they weren't familiar with JUnit! They also didn't take the time to fully read the "clear and concise" README which stated:

> We're building a JVM library, and executing some tests. There's no application and therefore no explicitly defined main entry point — just the tests.

There was of course also the precise CLI command (`./gradlew test`) required to execute the tests, a short explanation of the build system and why it was chosen. Additionally included was an explanation of how to run and debug the tests in an IDE. Plus all the standard stuff like documentation for the domain model and functional behavior of the APIs.

The feedback about "depositing or withdrawing with non-existent accounts" also makes no sense and demonstrate the reviewer is totally unfamiliar with Kotlin. There's no input (no CLI or GUI), so there's no way to provide a "non-existent" account. The APIs are strongly typed and non-nullable. (There's also explicitly no account deletion or multi-threading to worry about).

Sigh!

Don't get me wrong. I'm sure the code was far from perfect. I don't believe in such a thing and LOVE learning new things in code reviews. But my gosh, this is a company that has a truly brilliant Kotlin engineering department at their disposal. Unfortunately, with organizations of this size, all it takes is some part of your application to randomly land in the hands of the wrong person and it's game over.

> and I think you can be a successful Staff engineer and never write a line of production code in that role

Maybe for a while, but then they tend to lose touch and be less relevant. Someone who continues to be effective without writing code should be at a higher management level in the org to be sustainable.

Not sure how to explain this, but I’m convinced these “staff” positions are fake titles that are supposed to make roles seem nicer than they actually are.

Might be worth adding (2020) to the title

How do you interview for Fellow positions? :)

"I ended the job search with absolutely no interest in interviewing ever again"

Edit: perhaps I got this wrong. Maybe they meant staff engineer as in very senior IC who does not manage? If this is the case your role is to be strategic. You might write production code, you might design architecture. Whatever your current project(s) they will have wide reaching business impact. Asking difficult questions that may make people uncomfortable is very much part of this role. Yes these roles are seldom hired in to by first timers. But once you've be in one before, being hired externally is possible. I have a hard time believing that this person could do this type role at this point in their career (yes it was 2020 so adjust accordingly).

I'll leave the below since it might be useful for someone seeking a mid-level career.

--

I think they are equating a staff engineer with a mid-level engineer. They say that companies don't hire for this role but in my 26 years of working this has not been my experience. Granted, I focused on < 1000 employee companies because I liked the transparency, mobility, and influence I had there.

I don't know what kind of role they were looking for, but not wanting to write production code in a software company usually means you are going to be in a support role. These are often not traditional software engineering roles. You don't have to have a college degree, but you need to know the material. Programming is a skill just like anything. You have to practice.

Interviewing is an inexact, unfair process. Keep trying, doing as many as your sensitivity to rejection allows.

The thing that many applicants don't know is that many parts of a positions requirements that seem fixed are actually flexible.

Focus on good communication skills, listen well, and demonstrate concretely how you exemplify the skills they're looking for. Often the how and the why matter more then the what.

Recruiters usually know very little about what they're searching for. Yet they are the first line filter. Say what ever you need to say to move past them. But be mindful that they will often report what you say to the interview panel or hiring manager. Telling them an outright lie can be a bad idea.

Leetcode exercises aren't fun and they're a time sink. You can and should practice for them. In many cases they are a first line screen to filter out the noncoders. If you're considering searching for a solution and cutting and pasting it as your answer, know that leetcode has basic tools to detect this. They track your time and keystrokes.

Most teams have a balance of dead weight, followers, doers, and leaders. There are usually more of the former than the later. This plays in your favor if looking for a mid-level role.

Good luck out there.

>> 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.

Then don't fucking call yourself an engineer! Be a project manager, a product manager, sales, IT admin, QA, anything but mimicking a prestigious brand like Chinese "Adidos" shoes try to capitalize on the success of the original.

If you can't program you're not an engineer, period!

Mid-level LC questions are an excellent indicator of problem-solving ability: you need to read the task, understand the requirements, write code, think of edge cases, and potentially optimize, all of this in a time-constrained environment.

Flat-out refusal to do any kind of algorithmic interviews is a red flag for scammers and people who thrive on politics instead of building things.