7 ms·

Not only an excess number of managers, but an excess number of poorly performing and poorly trained engineers. 2018-2022 was peak shit eating time for managers

by ot1138 3y ago

Not only an excess number of managers, but an excess number of poorly performing and poorly trained engineers. 2018-2022 was peak shit eating time for managers. I had to put up with no end of candidates who couldn't pass even the easiest technical exams (and we intentionally made them easy to weed out only the pretenders). Candidates would ghost interviews and after receiving an offer, would lean on it for a higher salary for anyone else. They wanted $250-300k with just five years experience. It was the frothiest and least professional recruiting environment I had seen in 35 years.

eddtries 3y ago
This, I swear I had people interviewing for senior roles who couldn't FizzBuzz. I don't give LeetCode challenges to people but I do give them the first Project Euler problem which is summing ints that are divisible by 3 or 5 with the incredibly complex edge case of only adding numbers divisible by both values, aka 15, once. There was someone who applied who was really struggling so I hinted at modulo, then they mentioned they didn't really like to use if/else branches to avoid complex code.
- geodel 3y ago
  > with the incredibly complex edge case of only adding numbers divisible by both values, aka 15 Ah I love it, you are pushing them to reach peak human potential.
- corimaith 3y ago
  As a new grad who's currrently in the job market I have to say my experience is contrary to this. Pretty much every OA I've received from companies including non-tech companies like big banks are all asking pretty complex stuff such as writing a LRU Cache, Dynamic Progamming, etc. Most of these questions I would have had no idea how to do in the time allocated if I hadn't studied their specific patterns beforehand. Expectations are sky high, and it's only getting worse as time passes on.
  - eddtries 3y ago
    I had to face that grind when I was younger too, but I swore I'd never ask a question someone shouldn't be able to work out on the spot under the stress of an interview. My strategy is to take that question and expand on it in a fun way - touching different topics the candidate feels comfortable with. Make it concurrent? Solve it in the type system with Peano numbers? Etc... To me, tech is fun and I try to make the interview and fun and interactive as possible! But it does also help keep people out who literally can't code, which somehow still pass previous rounds.
op00to 3y ago
Allow me to play the tiniest violin for you. Funny how the tables have turned and you don't seem to mention the absolute unprofessionalism coming from recruiters who offer jobs and rescind them after candidates relocate, perform layoffs to pad the bottom line, and ghost the everliving fuck out of candidates like it's their job.
- j45 3y ago
  The only such thing as job security is the job security that one creates for themselves.
  - happytiger 3y ago
    There is no job security even then. Only wealth frees you.
    - j45 3y ago
      Yup, starting with earnings/revenue as a person or saas and ultimately what you keep/save
  - j45 3y ago
    Downvotes are welcome but lots of research out there. Financial literacy opens up more than one way for something to be true.
- ot1138 3y ago
  I've never once heard of a recruiter rescinding an offer after a relocation. Not once in 35 years. Recruiters also don't dictate layoffs. This is a function of Finance and layoffs are a part of life. And it is extremely rare for a recruiter to ghost a candidate. I don't recall ever hearing this happen, though I imagine it's possible under rare circumstances.
verelo 3y ago
I seriously struggle to tell the difference between certain types of low quality candidates during interviews and people that just bounce around looking for the next shiny thing. I say this as a manager/developer/founder that comes from a very hands on background. The obvious low quality candidate that is east to spot is the person that cannot answer the first question i always ask (write me a function, in any language, that takes an array of ints and returns the sum - half don’t ever pass this question the other 25% fail to consider or be able to discuss what might go wrong at runtime), the majority though sound very smart, can code, but put into a team just want to fixate on issues that serve zero value to the end user. Oh and i should add, when you tell certain developer personas things like: youre not here to decide what problems to solve, youre here to solve the problems the product team wants solved (they think about this all day, let them do their jobs) they get all upset and moody. I always encourage other devs to speak up about solutions and opportunity but we need to let each player in the team do their position, if we try do it all then this stops being a team. This to me feels like the reason we have a billion js frameworks and why no one wants to hand roll an api, but would rather fight with Apollo for hours. Being a developer has turned into a pseudo academic task, but with no interest in the process behind research. It’s such a shitfest out there, and frankly, I’m pretty over managing these folks. I’ve been doing contract work for about 12 months now and it’s been a fresh experience that I’m hoping continues for a while to come. Plug: if i sound like the kind of person you want helping with something feel free to ping me.
- xyzzy_plugh 3y ago
  I understand what you mean, and after several tours of duty across FAANGs and startups I think the bouncing-around tends to me less of an individual characteristic and more of a symptom of organizational dysfunction. For startups, the landscape within a given role tends to vary drastically year over year. Some folks like being employee #10 but don't want to hang around past employee #20. Other folks like being employee #1000 but out of 2000 or 3000 feel overwhelmed. Organizations these days hire, especially where employment is at-will, with the expectation that their staff are fungible (they're not) and can be rearranged at the drop of a hat (which happens often). One project can be a blast, and if the next one isn't then the grass is indeed often greener on the other side -- at least in our industry. Some of my best hires have been folks who have never stuck around at previous places for more than 6-9 months over the course of several years. On the whole, it's all a total crapshoot.
ravenstine 3y ago
I agree that it comes down to both poor management and poorly performing/trained engineers, but I've also seen a TON of dysfunction created by engineers that are perceived as competent. I'm not sure whether you might have actually been referring to that, but I'll continue assuming I'm referring to something slightly different. At nearly every company I've worked for, there's usually an "inner-circle" of highly regarded staff engineers whom are considered to be always correct by both management while the rest of engineering are treated by both groups as peons. On first glance, this might seem like a normal dynamic that occurs in any hierarchy based on competency and experience. Indeed, some people will be given more say than others because reasons. That's okay. What's not okay is when the gap between the inner-circle and the peons is so hollowed out that there's virtually no power structure to keep the inner-circle in check. I've seen this first-hand and second-hand when a company chooses its inner-circle based on a combination of nepotism, whomever has been around the longest, and whether an engineer has some kind of name for themselves outside of the company. It's not that these factors can't or shouldn't be a part of the equation, but they lead to rampancy when competency isn't thoroughly checked. Just because a person is vouched for doesn't mean they should be handed the "key to the city", and neither does whether the person stuck around and managed to survive every layoff, or whether they have a well-known blog or are considered a guru in some web framework. By that "key", I mean the metaphorical one they are given that allows them to dictate every level of engineering process, which sometimes goes as far as forcing every engineer to use the same IDE. Maybe they can have that key once they've proven themselves at the present company, but not merely because someone has an existing opinion about them. When a company gives their inner-circle way too much power and makes the rest of their engineers peons, this is where developer experience can decline and the amount of wasted resources increases. Most of the problems I've seen that make work a nightmare for engineers isn't even caused by management. Management notoriously asks unrealistic things of engineers, and this is a pain to deal with, but I've hardly ever seen this impossible to work with; it's the nature of the beast for engineers, more or less. The breakdown in engineer performance, from what I've seen, comes from the amount of bullshit that inner-circles add to the engineering process in order to solve problems. What the "staff" engineers whom are part of these inner-circles often fail to consider is that every link you add to the chain adds a new opportunity for the chain to break. This is engineering 101, but too many engineers with godlike clout either fail to consider it or pretend that it's not a problem. Maybe it's cognitive dissonance, or maybe it's ego. The rationalization is usually the idea that all of these checks and "standards" will protect the codebase in some way. Whatever the case, what we get are these humongous toolchains just to build a fucking JavaScript application that runs in a browser. What we get are CI tasks that randomly break because someone believed that a bajillion tests relying on third party services would reduce the amount of bugs. What we get are tests that run incredibly slow and are unpredictable. What we get is outdated documentation because someone in the inner-circle thought it was a great idea to host the documentation as a full website, and of course only they have the knowledge and ability to deploy that thing. What we get are engineers frequently making "mistakes" and holding up code review because there's constantly new "best practices" being silently handed down by inner-circle engineers who want to write code and can't be bothered communicating effectively. What we get are so many lint rules, checks, and pre-commit hooks frequently added and modified that the engineers outside the inner-circle are afforded no creativity and must spend extra time fixing errors that aren't even real errors with the code, but are errors based on someone's opinion. Ultimately, more time is spent fixing self-inflicted issues and far less time delivering value to customers. And software isn't even better today. I've spotted more glaring problems with both websites and native apps in 2023 than any other year prior. The quality of our output is a joke, but the world has accepted that all software is broken. The best thing tech companies can do is to break up their inner-circles of genius engineers, separate the wheat from the chaff, hire staff engineers who are averse to adding complexity, and give power back to the rest of their engineers. Engineering shouldn't be a combination of bureaucracy and implementing demands in the form of code; engineering should be about working on real problems. As an example, frequently baffling your engineers with uninformative errors caused by a custom in-house syntax transpiler that only one or two people seem to understand is not solving a real problem. That's called bullshit.

by ot1138 3y ago

eddtries 3y ago

This, I swear I had people interviewing for senior roles who couldn't FizzBuzz. I don't give LeetCode challenges to people but I do give them the first Project Euler problem which is summing ints that are divisible by 3 or 5 with the incredibly complex edge case of only adding numbers divisible by both values, aka 15, once. There was someone who applied who was really struggling so I hinted at modulo, then they mentioned they didn't really like to use if/else branches to avoid complex code.

geodel 3y ago
> with the incredibly complex edge case of only adding numbers divisible by both values, aka 15 Ah I love it, you are pushing them to reach peak human potential.
corimaith 3y ago
As a new grad who's currrently in the job market I have to say my experience is contrary to this. Pretty much every OA I've received from companies including non-tech companies like big banks are all asking pretty complex stuff such as writing a LRU Cache, Dynamic Progamming, etc. Most of these questions I would have had no idea how to do in the time allocated if I hadn't studied their specific patterns beforehand. Expectations are sky high, and it's only getting worse as time passes on.
- eddtries 3y ago
  I had to face that grind when I was younger too, but I swore I'd never ask a question someone shouldn't be able to work out on the spot under the stress of an interview. My strategy is to take that question and expand on it in a fun way - touching different topics the candidate feels comfortable with. Make it concurrent? Solve it in the type system with Peano numbers? Etc... To me, tech is fun and I try to make the interview and fun and interactive as possible! But it does also help keep people out who literally can't code, which somehow still pass previous rounds.

op00to 3y ago

Allow me to play the tiniest violin for you. Funny how the tables have turned and you don't seem to mention the absolute unprofessionalism coming from recruiters who offer jobs and rescind them after candidates relocate, perform layoffs to pad the bottom line, and ghost the everliving fuck out of candidates like it's their job.

j45 3y ago
The only such thing as job security is the job security that one creates for themselves.
- happytiger 3y ago
  There is no job security even then. Only wealth frees you.
  - j45 3y ago
    Yup, starting with earnings/revenue as a person or saas and ultimately what you keep/save
- j45 3y ago
  Downvotes are welcome but lots of research out there. Financial literacy opens up more than one way for something to be true.
ot1138 3y ago
I've never once heard of a recruiter rescinding an offer after a relocation. Not once in 35 years. Recruiters also don't dictate layoffs. This is a function of Finance and layoffs are a part of life. And it is extremely rare for a recruiter to ghost a candidate. I don't recall ever hearing this happen, though I imagine it's possible under rare circumstances.

verelo 3y ago

I seriously struggle to tell the difference between certain types of low quality candidates during interviews and people that just bounce around looking for the next shiny thing. I say this as a manager/developer/founder that comes from a very hands on background. The obvious low quality candidate that is east to spot is the person that cannot answer the first question i always ask (write me a function, in any language, that takes an array of ints and returns the sum - half don’t ever pass this question the other 25% fail to consider or be able to discuss what might go wrong at runtime), the majority though sound very smart, can code, but put into a team just want to fixate on issues that serve zero value to the end user. Oh and i should add, when you tell certain developer personas things like: youre not here to decide what problems to solve, youre here to solve the problems the product team wants solved (they think about this all day, let them do their jobs) they get all upset and moody. I always encourage other devs to speak up about solutions and opportunity but we need to let each player in the team do their position, if we try do it all then this stops being a team. This to me feels like the reason we have a billion js frameworks and why no one wants to hand roll an api, but would rather fight with Apollo for hours. Being a developer has turned into a pseudo academic task, but with no interest in the process behind research. It’s such a shitfest out there, and frankly, I’m pretty over managing these folks. I’ve been doing contract work for about 12 months now and it’s been a fresh experience that I’m hoping continues for a while to come. Plug: if i sound like the kind of person you want helping with something feel free to ping me.

xyzzy_plugh 3y ago
I understand what you mean, and after several tours of duty across FAANGs and startups I think the bouncing-around tends to me less of an individual characteristic and more of a symptom of organizational dysfunction. For startups, the landscape within a given role tends to vary drastically year over year. Some folks like being employee #10 but don't want to hang around past employee #20. Other folks like being employee #1000 but out of 2000 or 3000 feel overwhelmed. Organizations these days hire, especially where employment is at-will, with the expectation that their staff are fungible (they're not) and can be rearranged at the drop of a hat (which happens often). One project can be a blast, and if the next one isn't then the grass is indeed often greener on the other side -- at least in our industry. Some of my best hires have been folks who have never stuck around at previous places for more than 6-9 months over the course of several years. On the whole, it's all a total crapshoot.

ravenstine 3y ago

I agree that it comes down to both poor management and poorly performing/trained engineers, but I've also seen a TON of dysfunction created by engineers that are perceived as competent. I'm not sure whether you might have actually been referring to that, but I'll continue assuming I'm referring to something slightly different. At nearly every company I've worked for, there's usually an "inner-circle" of highly regarded staff engineers whom are considered to be always correct by both management while the rest of engineering are treated by both groups as peons. On first glance, this might seem like a normal dynamic that occurs in any hierarchy based on competency and experience. Indeed, some people will be given more say than others because reasons. That's okay. What's not okay is when the gap between the inner-circle and the peons is so hollowed out that there's virtually no power structure to keep the inner-circle in check. I've seen this first-hand and second-hand when a company chooses its inner-circle based on a combination of nepotism, whomever has been around the longest, and whether an engineer has some kind of name for themselves outside of the company. It's not that these factors can't or shouldn't be a part of the equation, but they lead to rampancy when competency isn't thoroughly checked. Just because a person is vouched for doesn't mean they should be handed the "key to the city", and neither does whether the person stuck around and managed to survive every layoff, or whether they have a well-known blog or are considered a guru in some web framework. By that "key", I mean the metaphorical one they are given that allows them to dictate every level of engineering process, which sometimes goes as far as forcing every engineer to use the same IDE. Maybe they can have that key once they've proven themselves at the present company, but not merely because someone has an existing opinion about them. When a company gives their inner-circle way too much power and makes the rest of their engineers peons, this is where developer experience can decline and the amount of wasted resources increases. Most of the problems I've seen that make work a nightmare for engineers isn't even caused by management. Management notoriously asks unrealistic things of engineers, and this is a pain to deal with, but I've hardly ever seen this impossible to work with; it's the nature of the beast for engineers, more or less. The breakdown in engineer performance, from what I've seen, comes from the amount of bullshit that inner-circles add to the engineering process in order to solve problems. What the "staff" engineers whom are part of these inner-circles often fail to consider is that every link you add to the chain adds a new opportunity for the chain to break. This is engineering 101, but too many engineers with godlike clout either fail to consider it or pretend that it's not a problem. Maybe it's cognitive dissonance, or maybe it's ego. The rationalization is usually the idea that all of these checks and "standards" will protect the codebase in some way. Whatever the case, what we get are these humongous toolchains just to build a fucking JavaScript application that runs in a browser. What we get are CI tasks that randomly break because someone believed that a bajillion tests relying on third party services would reduce the amount of bugs. What we get are tests that run incredibly slow and are unpredictable. What we get is outdated documentation because someone in the inner-circle thought it was a great idea to host the documentation as a full website, and of course only they have the knowledge and ability to deploy that thing. What we get are engineers frequently making "mistakes" and holding up code review because there's constantly new "best practices" being silently handed down by inner-circle engineers who want to write code and can't be bothered communicating effectively. What we get are so many lint rules, checks, and pre-commit hooks frequently added and modified that the engineers outside the inner-circle are afforded no creativity and must spend extra time fixing errors that aren't even real errors with the code, but are errors based on someone's opinion. Ultimately, more time is spent fixing self-inflicted issues and far less time delivering value to customers. And software isn't even better today. I've spotted more glaring problems with both websites and native apps in 2023 than any other year prior. The quality of our output is a joke, but the world has accepted that all software is broken. The best thing tech companies can do is to break up their inner-circles of genius engineers, separate the wheat from the chaff, hire staff engineers who are averse to adding complexity, and give power back to the rest of their engineers. Engineering shouldn't be a combination of bureaucracy and implementing demands in the form of code; engineering should be about working on real problems. As an example, frequently baffling your engineers with uninformative errors caused by a custom in-house syntax transpiler that only one or two people seem to understand is not solving a real problem. That's called bullshit.