Hacker News new | past | comments | ask | show | jobs | submit login

the #1 question you should ask in an interview is, how many people have left the team or the company in the last year as a percentage of the whole. That will tell you about the retention. In my many years of experience, I've noticed that people tend to stay at companies they like. If a company is loosing more people, it reflects quite poorly on the company.



There's a flipside to that. I work at a place where turnover is extremely low. While it makes for a very friendly workplace, there are downsides. I've been here a year and a half and I'm still the new guy. And naturally, there's no room for advancement.


In addition, this can also mean that they'll keep people who are a net-negative to the team. I have worked in such a place. Some folks really should have been fired and it dragged down the rest of the team.


How could you say such a thing? It seems like they’d need to be doing some pretty absurd stuff that you can say they should’ve been fired with such confidence


> ...they’d need to be doing some pretty absurd stuff...

No, the team would just have to be more productive if the should-have-been-fired people stayed home and offline on any given day.


I may be an oddball, but in over 15 years I have yet to work with such a person (as a team member at least; middle management is a different story). That includes almost ten years at ablarge defense contractor. I worked with plenty who provided little positive value, but everyone I worked with provided some.


> ...I have yet to work with such a person...

I have absolutely worked with bad architects who dreamed up giant frameworks that had basically all the features of an operating systems. In the end, the whole project had to be scrapped. And all the other developers had to be (slowly) retrained to learn that <smart architect> was wrong about many things.

I have absolutely worked with bad individual contributors that likewise wasted other peoples' time through shoddy work or a lack of empathy for other individual contributors. Often they ended up working on infrastructure groups, but they could work anywhere.

I have also worked with egotistical engineers that liked pedantry and debate over actual work. If you wanted to get things done, you basically learned how to avoid their input before shipping.

There are lots of other examples here. I didn't even go into different kinds of net-negative managers.


And even if it seemed to you that they weren't doing much, you'd need to know them very very well to say that with any confidence.


Don't underestimate the propensity for doing absurd stuff. Like, I know of a software developer who urinated on a coworker's keyboard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: