the most stressful part of this entire industry, and i know this from experience, is fixing other peoples' problems on-demand. whatever form it takes, that's the absolute worst fucking job in this entire field, because you get blamed for problems you did not cause, and blamed a second time for not fixing it fast enough.
Curious - does this take into account their warehouse employees who are not FTE's and are seasonal or only FTE's?
Keep in mind that can be somewhat misleading, if you have 3 positions and for 2 of those you have people who have stayed there 5+ years but for the other one you have had 5 people cycle through at a year each the median tenure will still be just 1 year. Even so, that's a pretty scary stat.
Well, that makes me fell better about being rejected. :/
I have been downvoted on reddit for saying this, but my opinion is that a company should be confident enough in a "no" that they won't reconsider that person for a substantially similar role.[1] If they aren't, they need to fix their hiring process so they are.
As an aside, the other thing that really pisses me off is to hear about how in-demand "software engineers" are while still having to deal with this crap. Seems like a self-imposed problem to me.
[1] "Substantially similar" here means same level, same stack, and same team, as appropriate for a particular company. IMO level should largely be irrelevant at larger companies because a candidate should be judged on hireability into any level and an offer made at the highest one appropriate. If there isn't one appropriate but a slot opens up within a reasonable amount of time, an offer should be made to previous interview candidates who passed that bar but failed the higher one, without the need to re-interview.
One of the biggest problems is that it's just very difficult to gauge someone's competency well (even broadly) in a short amount of time. Worse, most folks who do interviews are unwilling to acknowledge how difficult a task it is and how bad they are at it. And the high level of legitimate rejections makes it easy to imagine that all of your rejections are legitimate.
It's very unfortunate because hiring is one of the most important things anyone does at a job, and hiring well (especially finding competence that other companies have passed over) is a major competitive advantage.
> You get maybe 1 in 10 people that you can pass from one stage to the next (i.e. resume review to phone screen, phone screen to interview, interview to job offer).
Where I currently work I have not been involved much in the early screening. My understanding is that resume to screen is about 1:4 and screen to interview is about 1:10. I have been involved with the interviews, and our interview to offer is somewhere between 1:2 and 1:3. Our screen includes a 2-hour timed coding test, though, so I think it is fairly effective at filtering the poseurs. Prior to this I didn't have any visibility into the results.
This is tangential, but I often wonder how much of the phone screen and on-site failure rate has as its root cause a poor resume filtering function. When you say you only screen the top 10% of resumes, are you really screening the top 10% of candidates? I know it's a really hard question to answer, but it seems like many companies don't want to try to answer it.
> Worse, most folks who do interviews are unwilling to acknowledge how difficult a task it is and how bad they are at it.
This is one thing that really bothers me about this industry. So many companies think it is acceptable to just yank semi-random engineers out of their daily routine to go interview a candidate. I came from the traditional engineering world, and we got training before we were assigned to interviewing candidates. Furthermore, for our first interviews we were always paired with another interviewer who had significant experience.
> It's very unfortunate because hiring is one of the most important things anyone does at a job, and hiring well (especially finding competence that other companies have passed over) is a major competitive advantage.
What is ridiculous is the number of people who treat hiring as a distraction from their real job. If you want any sort of management responsibility, hiring is part your job.
Also, when I was working there I had a difficult time reconciling myself to how bad it was to work there. On paper it doesn't seem so bad. You get to work on pretty interesting stuff sometimes, you make good money, typically you only have to work 40 hour work weeks, etc. I convinced myself to walk away from a good chunk of money just in bonuses to get out of there, some people might be able to stick it out longer or find the money harder to leave behind.
The problem is that having such a huge portion of the economy being involved in knowledge work is a relatively new thing, and we don't understand the differences between knowledge work and physical work. And especially we don't have thoroughly established standards on what constitute good and bad conditions for knowledge work. We tend to think that sitting in a chair for 8 hours a day is "easy", but it very much is not. A stressful working environment for a knowledge worker is just as bad if not worse than a physical stressful job working extended hours. I only spent a year at Amazon, and most of the time I probably didn't even put in full 40 hour weeks, but I hated it there. In comparison I view the time I spent years ago doing data entry at sometimes up to 70 or 80 hours a week during peak times as comparatively inconsequential. Depending on the team you're on and so forth, working at Amazon can be a painful and stressful experience.
Take being on call for example. In theory this isn't so bad, it's good to give devs exposure to how the ops side of things works, and it's in theory good to give them ownership of their own mistakes so that they have incentive to write good code. The problem is, you're not in charge. You're never going to get permission to dump the resources into making everything run well, ever. Most teams have other priorities and they don't have enough resources to spare to allow you to properly fix the code you're responsible for. Worse, it's not even your code, it's code that was written by someone else years ago who also left years ago. And the next person is just going to get whatever mess you leave behind when you leave. So in the average case you can't actually work to improve things, so being on call is going to always be an extra pain, and a significant intrusion into your theoretically off-work life. Worse, it'll push you behind on all the other stuff you need to deliver.
Meanwhile, you have all the typical office BS of politics, ranking, bad corporate culture, reorgs, etc. that you have to deal with day to day. Some people manage to find good teams in that mess, and others manage to just turn off whatever makes people care about work and just suffer through it for the paycheck. But for a lot of people, more so the more you care, it'll be a stressful nightmare. And the easiest way to avoid dealing with all those problems is to just leave, which lots of people do.