3 ms·

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

by phibz 2y ago

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.

johnnyanmac 2y ago
>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.
- yobbo 2y ago
  > 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.
  - johnnyanmac 2y ago
    > 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. .

by phibz 2y ago

johnnyanmac 2y ago

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

yobbo 2y ago
> 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.
- johnnyanmac 2y ago
  > 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. .