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.
*I think you meant "(you weren't going to be solving real problems, you were there to boost your managers head count)". Probably too late to fix the typo too.
Most of my recent gigs have come through friends working on interesting problems, but those places have done plenty of hiring so I know this is not the only way to find these.
My recommendation is to start looking for teams doing interesting work out there and reach out to them directly (especially if they're smaller startups). Technically curious people reaching out to teams working on hard problems is a strong signal for those teams. But the key is, don't present yourself as looking for work, show you're interested in the same problem and have skills that will help.
One caveat: if you're expected in FAANG style TC, then you won't be able to find great teams. You can still get paid well and work on interesting stuff, but if you are addicted to very high TC then you're going to have to fight it out at large companies still.
I’m ex-Google. I quit because of the terrible culture of head count boosting and promotions. I’m personally happy with the compensation trade-off of making startup pay if it means I get startup culture.
I feel like the entire industry decided to just copy Google's career ladder in 2012 and now we have a bunch of titles pulled out of thin air. People talk about being a staff engineer like it's a concept that existed forever but it truly feels like a few influential companies just made up the term and willed it into existence.
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 :)
When I interview candidates using coding problems, I ask them to focus on finding the solution first before improving the code design, if it appears they are spending too much time up front in that area - in which case what I'm looking for is a candidate that takes the advice on board and completes the solution first and then talks about improvements; it's a red flag if they ignore my instruction and keep fiddling with the appearance of the code over solving the problem. Of course, basic type definitions are a good sign, unless it starts taking up too much time
I interviewed a bunch and sometimes I saw folks attempting to write a perfect code snippet and it would almost always result in them not being able to finish the actual problem I wanted to see on time (which resulted in rejection). So after a few of those I started asking people to just get to the point first and then make it nice if there’s time
But presumably you should be testing for people actually being able to write code, and not to solve some arbitrary problem unrelated to what 99% of engineers actually do. Being able to solve the leetcode problem tells you how well they crammed for the interview , not how well they code.
And I say that as someone who is on the interviewer side of the table for the past few years at $FAANG
I can see where you're coming from and where the interviewer is coming from. I usually say "I like where your head is at, but unfortunately we have a limited time, lets pretend you did that and go back to x"... unless of course it's going to make things easier. Like tests, aliases to hang functions on, etc. And I give credits for what the candidate starts doing.
I agree. Someone writing type aliases to make the code safer and easier to reason about would be a big green flag for me. It also helps me see how you’re modelling the solution.
In day to day work this is much better aligned with the skills I care about.
I’m currently pretty exhausted by this stuff. I need a job but some days I get interviews I almost want to turn down because I discover I’m going to get grilled with leetcode problems. I’m so tired of it.
The biggest issue that I have with LC interviews, is that they don’t reflect the real world. They come from a perfect world, where every problem is solved in 50 lines or less, and will not need to be maintained.
I have known many folks that constantly practice these, and are extremely good at them. Many practice sites, optimize for target companies, advising on how to solve in a manner each is looking for.
They also frequently optimize for recent school graduates, as these types of problems are almost exactly how software development is taught.
In my case, I write code for shipping software, every single day (including weekends. Today, I am working on a backend admin tool for an app that has been shipping since the beginning of this year), and have been, for many, many years. In fact, my entire adult life, has been shipping software and hardware products. It hasn’t always been good, and it hasn’t always been successful, but it has always shipped.
Just about every single day, I am faced with at least one problem, that, if I don’t solve it, will mean that I can’t ship whatever I’m working on. Often, the solution requires that I learn something new, or unlearn something that I just know is The Right Way to Do It. So I’m usually humbled, every single day.
This also takes time; sometimes, quite a lot of time. I don’t really have the bandwidth to practice code that is irrelevant to solving my daily existential programming crises. Many times, learning the new techniques required to solve the issue, involves LC-style exercises, but focused on addressing a very real-world problem, so I guess I do practice.
But I am aware that today’s software industry isn’t really interested in folks like me. They want armies of uniform short-timers that will make relatively small contributions to massive codebases that will outlive them. I’m not particularly interested in that kind of work. I really enjoy what I do. I enjoy it so much, that I do it for free, as no one is interested in paying folks to do 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.
Realistically, if you're getting LC style questions, the interviewer is probably not choosing the interview format and is just reporting their feedback in the applicant tracking system.
Staff software engineer is a title I see that means something that used to be "tech lead" (or is a promotion above "tech lead" in a single team, to handling multiple) in my opinion.
It is also used (incorrectly, imo) as a simple promotion above senior software engineer.
I think it's a different sort of job than being an individual contributor, more about growing people, growing the health of the engineering organization, technical liaison to other parts of the company, and promoting engineering productivity and quality.
I also think that, if you're a staff software engineer and you don't write code, it's kind of bonkers. The Staff roles I've been in have been very hands on - writing examples, documentation, prototypes, libraries, refactoring; and pitching in on projects that are critical or behind schedule. I usually talk about it as being an 80-20 or 60-40 role, with often the larger part of your time being on technical work and collaboration, and the other 20 or 40 on soft skills and organizational work, but I could see people organizing it the other way.
> it's a different sort of job than being an individual contributor
Well, I've never understood the IC thing either - and it is so horribly impersonal - why not just call them "components", or indeed "integrated circuits"?
And I think people should worry a lot less about job titles - for example, the whole "junior" and "senior" stuff is a bit worrying to me.
Basically, I think all this crap is just a way of paying people differently, regardless of actual worth.
Unfortunately, you don't get a job title created specifically for your social snowflake expertise, even if you're the only person who knows how to do some particular thing. That's a major red flag for legal and HR everywhere that screams "sue us for discrimination" because some disgruntled employee didn't get the title they wanted.
So, instead we get vanilla titles that apply to groups of people. Unfortunately, nobody likes to apply for or be called "junior", and "software engineer" is passe because the "senior" in senior software engineer doesn't refer to seniority at all.
IC also better describes the nature of the job requirements. You're not expected to lead, design or plan timelines. The expectation is that you make contributions at the individual level (write code, maybe spec out your own work) as opposed to planning work others will do or leading a team.
"Actual worth", as you say, is really quite subjective. Someone could be the lynchpin of the company by being the sole person that understands some component. They might be 10x more productive at writing code. That's actually bad for the company if they aren't able or willing to lift others up with them- they become a bus factor of one, and planning on them being around forever is just bad planning, period.
Generally agree, I am reminded of a possibly apocryphal story about Thoughtworks, which apparently back in 1999 only had one title - if you wrote software, you were a programmer. One of the clients got really mad, they wanted principal technical architects "not just a programmer" and someone had to point out that one of the "just a programmers" working on their project was in fact Martin Fowler.
I've always wanted to get a business card that said "Just A Programmer" on it.
Obviously such things do vary across organisations. Usually these job titles reflect levels of trust and impact across the organisation. In my experience, a senior will be the backbone of a team while a staff engineer will have impact across multiple teams.
If you can't identify and communicate to the rest of the organisation about technical people who are providing a higher order of value, then it shouldn't be too much of a surprise if its hard to progress without going into management. I get that programmers tend to be slightly anarchic and distrustful of authority but these titles exist to support a technical career path.
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've heard a few roles define staff as mid level, and others define it as basically a founder/fellow level role. At that point it's probably better to read the job description first instead of assume what experience they require.
A lot of FAANG staff engineering is just navigating bureaucracy and making sure the product gets out the door on time. Or stuff that isn't complicated on an algorithms level but hard nonetheless because the codebase sucks, the packages are outdated, etc.
I don't think "hard" engineering gets you promoted reliably unless it's business-defining. Actually any work that has a one time benefit seems to vanish by the next performance review. You're better off (career wise) implementing a process that might help 10% of the time than a one-time savings of $1m in compute costs.
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.
At the peak of the meaningless hiring frenzy period in tech (when people were just shoveling bodies through interview funnels), I had to learn how to guess what the interviewer knew and thought was the correct answer. There's no greater liability in these type of interviews than actually knowing what you're talking about. If the interviewer corrected me with a wrong answer I learned to quickly apologize and pretend I was humbled and in the wrong.
Thankfully if you're a strong engineer there's more and more small companies out there that are solving real problems and understand technical issues. You'll probably find more success interviewing at one of these. Even most startups today have lost their lost for emulating big corps in interviews.
This happened to me years ago - I realized that the interviewer was expecting a very specific answer, but that didn’t apply to the specific system I was working on ( something like ‘ we dont follow best practice X because it’s a 25 yo app with a few million lines of code and a mountain of technical debt and this is very different from the greenfield project you’re working on ‘) - he somehow got angry so I stopped explaining.
I didn’t get the job, but learned a very good lesson !
You probably dodged a bullet! Also, doing a disservice to yourself and your community by not calling them out here, so we can avoid wasting our time by not applying at that hellhole!!
I guess that’s the risk of this non-leetcode kind of technical interview. I loathe leetcode interviews and really enjoy doing these kinds because I usually think it lets me highlight some of the softer skills (clear documentation, onboarding instructions, and other bits that would make it easier for a junior to join my team). But wow I guess this is the flip side where the reviewer is clueless.
At the very least this tells me if I continue to administer these kinds of technical interviews I will leave room for a back-and-forth with the interviewee and give an opportunity for an update.
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)
Well, in her defense, this wasn’t a blog post applying for a job.
I read it as:
* Spend time empowering others to write production code
* Reporting to line manager doesn’t mean not making decisions.
* Spend time empowering others without having to always know the latest greatest new ways of solving a technical problem.
* Meh, might be the circumstances
* If this is “limited scope” in terms of qualified for a job, really depends on the company. If “limited scope” in terms of qualified to author this blog post, as has been observed by other commenters, this blog post is out of date and practices have changed since 2020. Pretty sure the practices 6.5 years before she wrote it were so vastly different that the 10-30 years of experience wouldn’t have been able to write a better or worse summary
The existence of her blog and willingness to talk about this stuff as a resource for the rest of us is pretty powerful evidence she’d bring value to a company.
I will admit that I kinda dread doing any traditional job search now. If anything, my current plan seems to be 'survive at X and build something of my own on the side'. In short, I think we can all relate to never wanting to interview 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.
> 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.
"Fun" story: years ago, I was interviewing for some position at a now-defunct startup that was then a darling of the SF tech scene. Several people worked there who had worked with me, as an engineer, at a prior company. It would have been trivial to verify my engineering ability by asking their existing employees.
Instead, as a screening interview I was given an at-home, timed, leetcode-style test in a UI with an abysmally bad web-based code editor. I quickly noped out of the terrible thing, opened emacs, coded the solution, and pasted it into the editor window. I submitted, the code passed whatever tests, and I was assured a response.
The next day I was summarily rejected, with only a vague comment about "lacking technical ability".
I'm not surprised. If you do this again, maybe put a disclaimer at the top. Simply mentioning emacs will likely get you points with many.
Sometimes you just have to take it on the chin and move on.
I noped out of intelligence test when looking in 2020. It was a series of extremely difficult word problems that go increasingly harder. There were more questions than you could solve. You were judged on accuracy and speed. I took a 15 minute practice test and after a few minutes called the recruiter. You wanna talk architecture, you wanna judge critical thinking with programming challenges sure. But this, he'll no.
> Sometimes you just have to take it on the chin and move on.
...or you just stop.
I basically stopped being an engineer and moved over to PM because I couldn't take the stupidity of tech interviews anymore. It's just such a myopic way of doing things, and it only rewards youth, inexperience and the "raw horsepower" dimension of the problem. I tried to imagine being 50+ years old with 30+ years of industry experience, and having somebody 2 weeks out of Foo Bootcamp judging me for not implementing some trending version of towers of hanoi quickly enough while tapdancing backwards [1]. It all started to feel like a sick game, designed to keep the rats fighting in the pit.
PM interviews certainly have their own problems, but they tend to be the sort that reflect the actual difficulties of hiring a human who has to work with other humans on hard intellectual problems. It's squishy and messy and hard to quantify, and you can't do it with an "objective" test. Bad people can fake their way through the process on occasion, but then again...I've seen plenty of terrible engineers who do well on leetcode questions, too.
I miss coding sometimes, but whenever I get the urge to go back, the thought of having to do the leetcode gauntlet annoys me enough to keep me away.
[1] Meanwhile, the CEO of the company is likely running the entire organization with minimal prior relevant experience; the investors/board of directors got their jobs because they were in the same fraternity; most everyone else on the executive team got there via glorified personality interviews (and a healthy dose of "who do you know?") Objective tests of competence are only for the little people, you see!
>Interviewing is an inexact, unfair process. Keep trying, doing as many as your sensitivity to rejection allows.
I have a pretty high tolerance, but this year just plain sucks, full of gaslighting about roles that dont exist and disrespect from recruiter gatekeepers.
>Leetcode exercises aren't fun and they're a time sink. You can and should practice for them.
I'm nowhere near you, but I think it's absurd that someone with 26 years would still need to pass some graph traversal trivia instead of anything actually relevant to their experience. Especially a staff/principal level that is probably super specialzied in a specific few topics.
I know they are too lazy to do proper domain questions, but you can do coding exercise without pretedning that Big O notation and solving some random "twists" in real time. If you have 20 years and can casually code up some for loops and branches in your given language, you probably prove your coding as much as some leetcode hard question. At most else, you may want to test pointers and memory management in as well, but "coding" 99% of the time is those above 3.
> I'm nowhere near you, but I think it's absurd that someone with 26 years would still need to pass some graph traversal trivia
Two more perspectives to this: 1) it's the ability to learn/prepare/improvise quickly that is being tested (... or have insane recall of past experience.) 2) to be respected by juniors and peers, everyone has to pass through the same gauntlet.
The job itself can be trivial for most candidates, but employees still need to have respect their for job positions and colleagues. It needs to feel like an achievement for everyone.
> It needs to feel like an achievement for everyone.
But that feeling won't be equal. There's code I was proud of as a junior that current me would tear to shreds with hindsight (even if I empahize with myself for the conditions it was made in). I thought it was neat some decade ago when I did my first LC hard with no assistance. Today that would simply be "well that was an odd puzzle, when would I be in this situation?"
It's also that your time/energy decades later is different from a would-be juinior studying fundamentals full time. Someone who may not even know what part of CS they want to be in yet, fresh out of their algorithms course. It's bad enough some companies expect you to keep up with projects outside of work, but they also expect us to study these brain teasers as well, to a point where you can solve them in 30-40 minutes in an interview setting?
That just tells me they either can't identify what they need for their job or that the actual role doesn't require 80% of all the fancy tools/systems/domain knowledge the job description listed and they just needed any kind of coder instead of an actual "staff" engineer. .
I agree with this from the perspective of the candidate.
From the perspective of the employer and current employees, picking randomly among a set of 50 candidates (who are all adequate relative the "real world" requirements) trivialises the job and the current staff. Requiring everyone do LC and other tests creates prestige, up-values the current employees, creates camaraderie, loyalty, etc.
When there is more than one adequate candidate, the selection process is a ritual that affects mainly the employees. It should be obvious in companies where there is no meaningful payback in a "long tail" of competence.
We use the LC exercises to screen people who can't program. They are on par with day 10 to 15 of advent of code exercises. An experienced, _practiced_ programmer should have no trouble with them.
I manage a devops team. We do ever thing from writing ansible, fixing broken services, to digging in to open source code and fixing sasl gssapi kerberos Auth.
You would be surprised how many senior people we talk to who can't don't code regularly. Building rock solid tooling is very much part of the job.
It really depends on what you're hiring for. Bit leetcode exercises can be practiced. You'll discover common patterns and themes. Being able to spot these and know how to solve them will save you time.
Also programming takes practice. I learned a ton of languages, but everytime I would use one I hadn't used in a while I needed to go to the docs. It was only after doing things like Advent of Code or forcing myself to code for an hour every weekend, that I became faster and more prolific.
This has only intensified as I moved in to management and my role shifted.
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.
That’s how LC sells it. And companies buy it. I know enough people, that deliver on very tight deadlines, but can’t do whiteboard coding during stressful interviews. Are these scammers or thrive in politics? Or just stress level is way too high during these interviews with 3 strangers in front of you sitting in unfamiliar office with unfamiliar computer.
They’re not though because they are totally out of context, there are no real stakes and ultimately you aren’t building anything.
If you like solving puzzles then LC is your jam.
Puzzles aren’t the same as Problems. The point of a puzzle is to solve the puzzle, in which case my brain just simply isn’t interested. The is no wider end goal.
The point of a problem is to solve an issue for a wider context and, untimely improve a system/process/organisation in some way. In which case I’m all in and my brain starts firing on all cylinders.
The are no puzzles in work, everything is a problem. LC is nothing but puzzles.
Of course, and nothing in my comment suggests otherwise. You’ve highlighted tools and techniques that can be used to solve problems and puzzles. I don’t enjoy drawing for the sake of it but I’m happy to draw a sketch for a home layout or woodworking project, both require me to be able to use a pencil, but one I will do well in the other I would fail at.
My point is that there are far better ways to test that than LC. My favourite interviews have been “here’s a real problem, placed in context, how would you solve it?” And “here’s an app with a handful of bugs, please fix it”
No, but "failing" because you didn't use map.emplace instead of map.insert on a test that didn't let you look up documentation and you code in 4 other languages is definitely approaching gatekeeping instead of problem solving.
Nevermind that the parameters for STL maps are convuluted to begin with if you're not using them everyday.
>an excellent indicator of problem-solving ability
And completely devoid of how this works in the workplace. Instead, you are quizzed in a closed environment on a question you have no context for before the interview (i.e. no time to research the problem space). You are given a hard time limit to solve a problem perfectly with a proctor who can range from being a helpful teammate to a stone wall who just says "this is wrong" or "this isn't the solution I wanted". And if you pass that it says nothing about your ability to perform what was actually on the job description. Who wins here?
And the kicker is you may not even get a leetcode question in my domain to begin with. So all that trivia study could be wasted and you fail on some deep C++ deep dive or math questions or any other number of tooling questions. every company is different and they all treat these "problem solving" like we're still in high school and can "cheat" the answer.
From everything I’ve read, that seems to be the name of the game on anything beyond senior. Try to gather influence. Slap your name on projects that are going well, stay away from projects that are going bad. Say the right keywords that you’re supposed to say. It all seems so tiresome.
I imagine principal/staff level isn't quite high enough in many orgs to complete drive a project. You will just be arguing half the time with the director/product owner and forced to make compromises that were making the project fail to begin with
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.
*I think you meant "(you weren't going to be solving real problems, you were there to boost your managers head count)". Probably too late to fix the typo too.
How do you look for companies? Any indications typical for conpanies, that don't suck?
Most of my recent gigs have come through friends working on interesting problems, but those places have done plenty of hiring so I know this is not the only way to find these.
My recommendation is to start looking for teams doing interesting work out there and reach out to them directly (especially if they're smaller startups). Technically curious people reaching out to teams working on hard problems is a strong signal for those teams. But the key is, don't present yourself as looking for work, show you're interested in the same problem and have skills that will help.
One caveat: if you're expected in FAANG style TC, then you won't be able to find great teams. You can still get paid well and work on interesting stuff, but if you are addicted to very high TC then you're going to have to fight it out at large companies still.
I’m ex-Google. I quit because of the terrible culture of head count boosting and promotions. I’m personally happy with the compensation trade-off of making startup pay if it means I get startup culture.
I feel like the entire industry decided to just copy Google's career ladder in 2012 and now we have a bunch of titles pulled out of thin air. People talk about being a staff engineer like it's a concept that existed forever but it truly feels like a few influential companies just made up the term and willed it into existence.
How do you play "the game"?
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 :)
When I interview candidates using coding problems, I ask them to focus on finding the solution first before improving the code design, if it appears they are spending too much time up front in that area - in which case what I'm looking for is a candidate that takes the advice on board and completes the solution first and then talks about improvements; it's a red flag if they ignore my instruction and keep fiddling with the appearance of the code over solving the problem. Of course, basic type definitions are a good sign, unless it starts taking up too much time
That sounds good. I always try to solve the problem with decent code first, and often they ask what I might improve and will do a quick clean up then.
I interviewed a bunch and sometimes I saw folks attempting to write a perfect code snippet and it would almost always result in them not being able to finish the actual problem I wanted to see on time (which resulted in rejection). So after a few of those I started asking people to just get to the point first and then make it nice if there’s time
But presumably you should be testing for people actually being able to write code, and not to solve some arbitrary problem unrelated to what 99% of engineers actually do. Being able to solve the leetcode problem tells you how well they crammed for the interview , not how well they code.
And I say that as someone who is on the interviewer side of the table for the past few years at $FAANG
like so?
I can see where you're coming from and where the interviewer is coming from. I usually say "I like where your head is at, but unfortunately we have a limited time, lets pretend you did that and go back to x"... unless of course it's going to make things easier. Like tests, aliases to hang functions on, etc. And I give credits for what the candidate starts doing.
I agree. Someone writing type aliases to make the code safer and easier to reason about would be a big green flag for me. It also helps me see how you’re modelling the solution.
In day to day work this is much better aligned with the skills I care about.
I’m currently pretty exhausted by this stuff. I need a job but some days I get interviews I almost want to turn down because I discover I’m going to get grilled with leetcode problems. I’m so tired of it.
The biggest issue that I have with LC interviews, is that they don’t reflect the real world. They come from a perfect world, where every problem is solved in 50 lines or less, and will not need to be maintained.
I have known many folks that constantly practice these, and are extremely good at them. Many practice sites, optimize for target companies, advising on how to solve in a manner each is looking for.
They also frequently optimize for recent school graduates, as these types of problems are almost exactly how software development is taught.
In my case, I write code for shipping software, every single day (including weekends. Today, I am working on a backend admin tool for an app that has been shipping since the beginning of this year), and have been, for many, many years. In fact, my entire adult life, has been shipping software and hardware products. It hasn’t always been good, and it hasn’t always been successful, but it has always shipped.
Just about every single day, I am faced with at least one problem, that, if I don’t solve it, will mean that I can’t ship whatever I’m working on. Often, the solution requires that I learn something new, or unlearn something that I just know is The Right Way to Do It. So I’m usually humbled, every single day.
This also takes time; sometimes, quite a lot of time. I don’t really have the bandwidth to practice code that is irrelevant to solving my daily existential programming crises. Many times, learning the new techniques required to solve the issue, involves LC-style exercises, but focused on addressing a very real-world problem, so I guess I do practice.
But I am aware that today’s software industry isn’t really interested in folks like me. They want armies of uniform short-timers that will make relatively small contributions to massive codebases that will outlive them. I’m not particularly interested in that kind of work. I really enjoy what I do. I enjoy it so much, that I do it for free, as no one is interested in paying folks to do 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.
Realistically, if you're getting LC style questions, the interviewer is probably not choosing the interview format and is just reporting their feedback in the applicant tracking system.
> 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.
Staff software engineer is a title I see that means something that used to be "tech lead" (or is a promotion above "tech lead" in a single team, to handling multiple) in my opinion.
It is also used (incorrectly, imo) as a simple promotion above senior software engineer.
I think it's a different sort of job than being an individual contributor, more about growing people, growing the health of the engineering organization, technical liaison to other parts of the company, and promoting engineering productivity and quality.
I also think that, if you're a staff software engineer and you don't write code, it's kind of bonkers. The Staff roles I've been in have been very hands on - writing examples, documentation, prototypes, libraries, refactoring; and pitching in on projects that are critical or behind schedule. I usually talk about it as being an 80-20 or 60-40 role, with often the larger part of your time being on technical work and collaboration, and the other 20 or 40 on soft skills and organizational work, but I could see people organizing it the other way.
> it's a different sort of job than being an individual contributor
Well, I've never understood the IC thing either - and it is so horribly impersonal - why not just call them "components", or indeed "integrated circuits"?
And I think people should worry a lot less about job titles - for example, the whole "junior" and "senior" stuff is a bit worrying to me.
Basically, I think all this crap is just a way of paying people differently, regardless of actual worth.
Unfortunately, you don't get a job title created specifically for your social snowflake expertise, even if you're the only person who knows how to do some particular thing. That's a major red flag for legal and HR everywhere that screams "sue us for discrimination" because some disgruntled employee didn't get the title they wanted.
So, instead we get vanilla titles that apply to groups of people. Unfortunately, nobody likes to apply for or be called "junior", and "software engineer" is passe because the "senior" in senior software engineer doesn't refer to seniority at all.
IC also better describes the nature of the job requirements. You're not expected to lead, design or plan timelines. The expectation is that you make contributions at the individual level (write code, maybe spec out your own work) as opposed to planning work others will do or leading a team.
"Actual worth", as you say, is really quite subjective. Someone could be the lynchpin of the company by being the sole person that understands some component. They might be 10x more productive at writing code. That's actually bad for the company if they aren't able or willing to lift others up with them- they become a bus factor of one, and planning on them being around forever is just bad planning, period.
> you don't get a job title created specifically for your social snowflake expertise
I have never applied for a job based on anything "social" or "snowflake" - only on salary and tech stuff, such as "C++, Windows, some PM experience".
Generally agree, I am reminded of a possibly apocryphal story about Thoughtworks, which apparently back in 1999 only had one title - if you wrote software, you were a programmer. One of the clients got really mad, they wanted principal technical architects "not just a programmer" and someone had to point out that one of the "just a programmers" working on their project was in fact Martin Fowler.
I've always wanted to get a business card that said "Just A Programmer" on it.
The most accurate job description I ever had was when I worked at Middlesex Poly in the mid-1980s - "Analyst Programmer".
Where did all the "Analysts" disappear to? They could be useful. And all those "System Architects"? Much less so?
The article links to another one that has a breakdown in Tech Lead, Architect, Solver, and Right-Hand: https://staffeng.com/guides/staff-archetypes/
In lots of places, staff engineer is the next level up from senior.
OK, what is "senior"? And what is "next level up" in this context?
Obviously such things do vary across organisations. Usually these job titles reflect levels of trust and impact across the organisation. In my experience, a senior will be the backbone of a team while a staff engineer will have impact across multiple teams.
If you can't identify and communicate to the rest of the organisation about technical people who are providing a higher order of value, then it shouldn't be too much of a surprise if its hard to progress without going into management. I get that programmers tend to be slightly anarchic and distrustful of authority but these titles exist to support a technical career path.
Up from mid or junior. A promotion. Every profession has that, why do (some) software engineers have to act like it's strange.
How about:
"We really like the work you have done on ABC. Now, XYZ needs some help. We'd like you to work with them, and we'll give you a P% raise."
Happens all the time as a consultant/contractor - no need for half-assed job titles. Should work for non-consultants too.
Staff/principal/distinguished etc maybe ?
Yet more meaningless titles.
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)
well she's certainly right about one thing:
>Everybody defines Staff differently
I've heard a few roles define staff as mid level, and others define it as basically a founder/fellow level role. At that point it's probably better to read the job description first instead of assume what experience they require.
A lot of FAANG staff engineering is just navigating bureaucracy and making sure the product gets out the door on time. Or stuff that isn't complicated on an algorithms level but hard nonetheless because the codebase sucks, the packages are outdated, etc.
I don't think "hard" engineering gets you promoted reliably unless it's business-defining. Actually any work that has a one time benefit seems to vanish by the next performance review. You're better off (career wise) implementing a process that might help 10% of the time than a one-time savings of $1m in compute costs.
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.
At the peak of the meaningless hiring frenzy period in tech (when people were just shoveling bodies through interview funnels), I had to learn how to guess what the interviewer knew and thought was the correct answer. There's no greater liability in these type of interviews than actually knowing what you're talking about. If the interviewer corrected me with a wrong answer I learned to quickly apologize and pretend I was humbled and in the wrong.
Thankfully if you're a strong engineer there's more and more small companies out there that are solving real problems and understand technical issues. You'll probably find more success interviewing at one of these. Even most startups today have lost their lost for emulating big corps in interviews.
This happened to me years ago - I realized that the interviewer was expecting a very specific answer, but that didn’t apply to the specific system I was working on ( something like ‘ we dont follow best practice X because it’s a 25 yo app with a few million lines of code and a mountain of technical debt and this is very different from the greenfield project you’re working on ‘) - he somehow got angry so I stopped explaining.
I didn’t get the job, but learned a very good lesson !
You probably dodged a bullet! Also, doing a disservice to yourself and your community by not calling them out here, so we can avoid wasting our time by not applying at that hellhole!!
I guess that’s the risk of this non-leetcode kind of technical interview. I loathe leetcode interviews and really enjoy doing these kinds because I usually think it lets me highlight some of the softer skills (clear documentation, onboarding instructions, and other bits that would make it easier for a junior to join my team). But wow I guess this is the flip side where the reviewer is clueless.
At the very least this tells me if I continue to administer these kinds of technical interviews I will leave room for a back-and-forth with the interviewee and give an opportunity for an update.
The response you received reads like an AI wrote it.
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)
Well, in her defense, this wasn’t a blog post applying for a job.
I read it as:
* Spend time empowering others to write production code * Reporting to line manager doesn’t mean not making decisions. * Spend time empowering others without having to always know the latest greatest new ways of solving a technical problem. * Meh, might be the circumstances * If this is “limited scope” in terms of qualified for a job, really depends on the company. If “limited scope” in terms of qualified to author this blog post, as has been observed by other commenters, this blog post is out of date and practices have changed since 2020. Pretty sure the practices 6.5 years before she wrote it were so vastly different that the 10-30 years of experience wouldn’t have been able to write a better or worse summary
The existence of her blog and willingness to talk about this stuff as a resource for the rest of us is pretty powerful evidence she’d bring value to a company.
But YMMV
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"
I will admit that I kinda dread doing any traditional job search now. If anything, my current plan seems to be 'survive at X and build something of my own on the side'. In short, I think we can all relate to never wanting to interview 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.
> 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.
"Fun" story: years ago, I was interviewing for some position at a now-defunct startup that was then a darling of the SF tech scene. Several people worked there who had worked with me, as an engineer, at a prior company. It would have been trivial to verify my engineering ability by asking their existing employees.
Instead, as a screening interview I was given an at-home, timed, leetcode-style test in a UI with an abysmally bad web-based code editor. I quickly noped out of the terrible thing, opened emacs, coded the solution, and pasted it into the editor window. I submitted, the code passed whatever tests, and I was assured a response.
The next day I was summarily rejected, with only a vague comment about "lacking technical ability".
I'm not surprised. If you do this again, maybe put a disclaimer at the top. Simply mentioning emacs will likely get you points with many.
Sometimes you just have to take it on the chin and move on.
I noped out of intelligence test when looking in 2020. It was a series of extremely difficult word problems that go increasingly harder. There were more questions than you could solve. You were judged on accuracy and speed. I took a 15 minute practice test and after a few minutes called the recruiter. You wanna talk architecture, you wanna judge critical thinking with programming challenges sure. But this, he'll no.
> Sometimes you just have to take it on the chin and move on.
...or you just stop.
I basically stopped being an engineer and moved over to PM because I couldn't take the stupidity of tech interviews anymore. It's just such a myopic way of doing things, and it only rewards youth, inexperience and the "raw horsepower" dimension of the problem. I tried to imagine being 50+ years old with 30+ years of industry experience, and having somebody 2 weeks out of Foo Bootcamp judging me for not implementing some trending version of towers of hanoi quickly enough while tapdancing backwards [1]. It all started to feel like a sick game, designed to keep the rats fighting in the pit.
PM interviews certainly have their own problems, but they tend to be the sort that reflect the actual difficulties of hiring a human who has to work with other humans on hard intellectual problems. It's squishy and messy and hard to quantify, and you can't do it with an "objective" test. Bad people can fake their way through the process on occasion, but then again...I've seen plenty of terrible engineers who do well on leetcode questions, too.
I miss coding sometimes, but whenever I get the urge to go back, the thought of having to do the leetcode gauntlet annoys me enough to keep me away.
[1] Meanwhile, the CEO of the company is likely running the entire organization with minimal prior relevant experience; the investors/board of directors got their jobs because they were in the same fraternity; most everyone else on the executive team got there via glorified personality interviews (and a healthy dose of "who do you know?") Objective tests of competence are only for the little people, you see!
>Interviewing is an inexact, unfair process. Keep trying, doing as many as your sensitivity to rejection allows.
I have a pretty high tolerance, but this year just plain sucks, full of gaslighting about roles that dont exist and disrespect from recruiter gatekeepers.
>Leetcode exercises aren't fun and they're a time sink. You can and should practice for them.
I'm nowhere near you, but I think it's absurd that someone with 26 years would still need to pass some graph traversal trivia instead of anything actually relevant to their experience. Especially a staff/principal level that is probably super specialzied in a specific few topics.
I know they are too lazy to do proper domain questions, but you can do coding exercise without pretedning that Big O notation and solving some random "twists" in real time. If you have 20 years and can casually code up some for loops and branches in your given language, you probably prove your coding as much as some leetcode hard question. At most else, you may want to test pointers and memory management in as well, but "coding" 99% of the time is those above 3.
> I'm nowhere near you, but I think it's absurd that someone with 26 years would still need to pass some graph traversal trivia
Two more perspectives to this: 1) it's the ability to learn/prepare/improvise quickly that is being tested (... or have insane recall of past experience.) 2) to be respected by juniors and peers, everyone has to pass through the same gauntlet.
The job itself can be trivial for most candidates, but employees still need to have respect their for job positions and colleagues. It needs to feel like an achievement for everyone.
> It needs to feel like an achievement for everyone.
But that feeling won't be equal. There's code I was proud of as a junior that current me would tear to shreds with hindsight (even if I empahize with myself for the conditions it was made in). I thought it was neat some decade ago when I did my first LC hard with no assistance. Today that would simply be "well that was an odd puzzle, when would I be in this situation?"
It's also that your time/energy decades later is different from a would-be juinior studying fundamentals full time. Someone who may not even know what part of CS they want to be in yet, fresh out of their algorithms course. It's bad enough some companies expect you to keep up with projects outside of work, but they also expect us to study these brain teasers as well, to a point where you can solve them in 30-40 minutes in an interview setting?
That just tells me they either can't identify what they need for their job or that the actual role doesn't require 80% of all the fancy tools/systems/domain knowledge the job description listed and they just needed any kind of coder instead of an actual "staff" engineer. .
I agree with this from the perspective of the candidate.
From the perspective of the employer and current employees, picking randomly among a set of 50 candidates (who are all adequate relative the "real world" requirements) trivialises the job and the current staff. Requiring everyone do LC and other tests creates prestige, up-values the current employees, creates camaraderie, loyalty, etc.
When there is more than one adequate candidate, the selection process is a ritual that affects mainly the employees. It should be obvious in companies where there is no meaningful payback in a "long tail" of competence.
We use the LC exercises to screen people who can't program. They are on par with day 10 to 15 of advent of code exercises. An experienced, _practiced_ programmer should have no trouble with them.
I manage a devops team. We do ever thing from writing ansible, fixing broken services, to digging in to open source code and fixing sasl gssapi kerberos Auth.
You would be surprised how many senior people we talk to who can't don't code regularly. Building rock solid tooling is very much part of the job.
It really depends on what you're hiring for. Bit leetcode exercises can be practiced. You'll discover common patterns and themes. Being able to spot these and know how to solve them will save you time.
Also programming takes practice. I learned a ton of languages, but everytime I would use one I hadn't used in a while I needed to go to the docs. It was only after doing things like Advent of Code or forcing myself to code for an hour every weekend, that I became faster and more prolific.
This has only intensified as I moved in to management and my role shifted.
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.
That’s how LC sells it. And companies buy it. I know enough people, that deliver on very tight deadlines, but can’t do whiteboard coding during stressful interviews. Are these scammers or thrive in politics? Or just stress level is way too high during these interviews with 3 strangers in front of you sitting in unfamiliar office with unfamiliar computer.
They’re not though because they are totally out of context, there are no real stakes and ultimately you aren’t building anything.
If you like solving puzzles then LC is your jam.
Puzzles aren’t the same as Problems. The point of a puzzle is to solve the puzzle, in which case my brain just simply isn’t interested. The is no wider end goal.
The point of a problem is to solve an issue for a wider context and, untimely improve a system/process/organisation in some way. In which case I’m all in and my brain starts firing on all cylinders.
The are no puzzles in work, everything is a problem. LC is nothing but puzzles.
Uh, knowing when to use a hashmap, recursion and a loop is not a puzzle. It's table stakes.
Of course, and nothing in my comment suggests otherwise. You’ve highlighted tools and techniques that can be used to solve problems and puzzles. I don’t enjoy drawing for the sake of it but I’m happy to draw a sketch for a home layout or woodworking project, both require me to be able to use a pencil, but one I will do well in the other I would fail at.
My point is that there are far better ways to test that than LC. My favourite interviews have been “here’s a real problem, placed in context, how would you solve it?” And “here’s an app with a handful of bugs, please fix it”
No, but "failing" because you didn't use map.emplace instead of map.insert on a test that didn't let you look up documentation and you code in 4 other languages is definitely approaching gatekeeping instead of problem solving.
Nevermind that the parameters for STL maps are convuluted to begin with if you're not using them everyday.
Which is different though from LC being overly specific about how long you solution is allowed to take and how much memory etc.
>an excellent indicator of problem-solving ability
And completely devoid of how this works in the workplace. Instead, you are quizzed in a closed environment on a question you have no context for before the interview (i.e. no time to research the problem space). You are given a hard time limit to solve a problem perfectly with a proctor who can range from being a helpful teammate to a stone wall who just says "this is wrong" or "this isn't the solution I wanted". And if you pass that it says nothing about your ability to perform what was actually on the job description. Who wins here?
And the kicker is you may not even get a leetcode question in my domain to begin with. So all that trivia study could be wasted and you fail on some deep C++ deep dive or math questions or any other number of tooling questions. every company is different and they all treat these "problem solving" like we're still in high school and can "cheat" the answer.
From everything I’ve read, that seems to be the name of the game on anything beyond senior. Try to gather influence. Slap your name on projects that are going well, stay away from projects that are going bad. Say the right keywords that you’re supposed to say. It all seems so tiresome.
> stay away from projects that are going bad
We can’t tag all of them like that! Many times you build reputation by turning failures into successes
I imagine principal/staff level isn't quite high enough in many orgs to complete drive a project. You will just be arguing half the time with the director/product owner and forced to make compromises that were making the project fail to begin with