Comment by obviouslynotme | Hacker News Reader

Comment by obviouslynotme | Hacker News Reader

In my decades experience hiring, there are only three archetypes you want to avoid:

- Someone who has no clue. This is rare but it does happen. I have seen some fly through interviews and then literally do nothing until they leave for another company as we are set to fire them.

- Assholes. Everyone is nice in the interviews. Not everyone is nice during code review. There is a sub-archetype of asshole called The Complainer. They can live in pairs, but if there is no Assholes, a true Complainer will find a way to turn someone into one. They are two sides of the same coin.

- My way or the highway types. Your team uses Design Patterns and Unit Testing. Bob says that is overengineering and refuses to be a team player.

Interviews focus on the first one, which is honestly simple for a relatively experienced interviewer to weed out. I don't believe in 10X rockstar ninja programmers. Either someone has the ability or they don't.

The real keys to great hiring are good managers and cheap firing. Good managers are hard to come by, but they can be built fairly easily. Cheap firing is usually easy, if that is your goal. Some locales restrict this legally, but there is always a loophole.

Firing is dangerous, it can demoralize the team extremely quickly. My rough rule of thumb is that for anybody who was even marginally liked who gets fired, expect one of your best people to leave.

On the other hand, if there is someone who people don't like, who visibly avoids work, and the rest of the team resents them, then firing is actually a really positive thing.

> Firing is dangerous, it can demoralize the team extremely quickly.

Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work. I don't mean junior folks who get it but are building experience. A company I worked for hired a junior against the advice of the team (red flag anyone?). We spent 6-8 months with this individual spinning their wheels. They just did not get it. It created more work for the rest of the team to help them, redo the work correctly, etc. Did they fire him? Nope...they transferred him to another group within the company. And of course he's not doing well in that group either. Why should people work their butts off if it seemingly makes no difference?

I've since left that company - this wasn't the primary driver, there were lots of other supporting reasons, but ultimately it came down to my loss of faith in management's ability to steer us in the right direction.

The obviously clueless are rarely controversial fires. The problem is when leadership have a different opinion of the employee than workers.

I'm on my notice right now. I started hunting a new job after the company fired their recently hired well-liked VP Product. Most of the organisation believed this guy had made a substantial positive impact, and the firing reasons were concocted. They weren't entirely unjustified (he was too expensive, and focus wasn't aligned), but I still disagreed. I've heard both sides independently, and nowhere near enough effort was made to find a better way.

When people see good people fired for weak reasons, they become concerned for their own role. As a senior engineer, this is particularly worrisome. A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases. If I see people getting fired like this, then my career becomes a factor in my decision making.

Ultimately, this firing has cost a small engineering team both it's senior engineers. I'm gone, so is the other senior (for the same reason). The CTO is management focused. There are a few other reasons I won't go into, but this team is in a very difficult position.

“Weak reasons” obviously heavily dependent on priorities at the time, which can change quickly. On small companies it has a massive impact on others and that shouldn’t be taken lightly.

I had a previous boss that hired someone senior to do X but their expectations of the role quickly changed and they were fired for not performing well enough. They jumped from a good job stable job and took a risk, asking all the right questions about the role but CEO/CTO never lived up to their side of what the role ended up being.

This same CEO also admitted to me part of their management style was “push people to breaking point, and back off a little” to get the most out of people. I left soon after.

I don’t know how to avoid working with this kind of leadership personality in the interview process but has definitely made me more cautious.

> A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases.

This paragraph should be a great frame for so many problems. Engineers are people whose identities are wrapped in the perception of their intelligence. But value is created when we disagree and "the right" person wins.

> Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work.

I think this is only true in the most egregious of cases. A somewhat counter-intuitive thing I've learned is that highly productive programmers like working with less productive programmers. They've spent a lot of time with this person, maybe got to like them on a personal level. But beyond that, they don't have to butt heads all the time, it's one more person to stamp your diff without excessive nitpicking, someone to bounce ideas off of, someone to handle the more mundane coding work, someone to share blame with. Almost like an assistant programmer. A backfill will have to trained and knowledge-transferred again from zero.

This isn't to say the organization is best served by keeping low-performers around at full salary to keep their high performers happy. That depends on higher level organizational goals. My point is to support GP's quoted statement in your post, that firing is dangerous and can demoralize teams.

Any non net-negative developer being fired risks demoralizing the team. If they are net 0.1% as productive as a typical developer, but not preventing anybody else from getting their work done, they are a cost to the company, but not to the remainder of the team.

Agreed. This individual was a net negative. They could not get their work done, and thus required other engineers to pick up their "slack". Everyone pitched in to help mentor the individual, without much success. Compared to other similarly skilled/experienced developers we'd hired around the same time - who became productive in a few months, this person made zero progress.

Not firing this person was demoralizing to the team. Moving them off the team to another group seemed to upset people even more than keeping this person around (I'd moved on by this time, but kept in touch with the team). Rather than doing the right thing for the organization (firing them) - management decided to make it someone else's problem in the organization. Yes from management's perspective they 'solved' the team's problem but the optics of what they did created resentment towards management.

They are a cost to other developers as well. If one person is not able to (or choose not to) handle the tasks he is assigned to then he is a burden on others. Not to mention others' tasks can have dependency to that person's.

In my experience (I think I had two people that intentionally slacks around and wants to get fired) the companies often put such persons on low prio tasks that barely matter. And be a bit more pessimistic with their estimates

As a hiring manager, the hardest people to fire are the ones that try hard, always show up on time but still end up doing terrible work. The best way I’ve found to do this is 9 box them, unfortunately point out how they’re holding back the team to the other people on the team (ie talk shit) and then formal review followed by firing.

What is 9 boxing?

Basically a matrix between potential and performance. It’s easier to look up.

https://www.aihr.com/blog/9-box-grid/

> point out how they’re holding back the team to the other people on the team (ie talk shit)

It is terrifying to think that you are in any kind of leadership position. I instantly lose respect for anyone who "talks shit" about team members, especially leaders. If I found out anyone was talking shit, especially someone in a leadership position in my company I would fire them on the spot. Well, I would first ask to speak privately so that they could still have the dignity they were denying their former team.

There are no bad teams, there are only bad leaders.

There are team members that are beloved for characteristics besides what they’ve been hired for. It’s explicitly why I pointed out it’s a hard decision to make but ultimately the right one. Pointing out how they are bringing down the team is not easy but necessary and part of what makes the job hard. This is after several quarters of speaking with privately and many attempts at coaching and external training with no change, which is how we get to the 9 box rating in the first place.

Sounds like you have never been in a spot when resources were scarce and you can't afford to keep around people who are nice, but useless.

Everyone's a humanitarian when the sun is shining.

Did you ever consider mentoring the person? Seems better than back-stabbing. The worse part is you're ok with it!

Yep. My company seems to fire fairly regularly. Always a whole bunch of people who depart right after.

I would argue not firing is dangerous and demoralizing. Who wants to work on teams full of dead weight?

Oddly at many large organizations it's not the dead weight that's getting fired. In fact, the dead weights are usually the safest. Anyone that's managed to be dead weight at a Fortune 500 company for more than a couple years is very good at it. Think of Wally from Dilbert.

I have a guy in my team who hasn't produced anything meaningful. 3 months ago I told my manager and the product owner that I can not include him into our sprint plans since he can not deliver anything. He still shows up in the scrums and tells us he is "working on errors". No one has any clue what he is supposedly doing. We wish our manager would just fire him.

Currently our suspicion is that he is related to some higher up.

I've learned to run from anyone who blames everyone else for their problems. Sooner or later they'll blame me.

There's a 4th type, the competent but lazy engineer. They do great in the interview, then it's rest and vest time. They thrive in remote positions where they spend most of their time at the doctor, dentist, and vet.

As long as they do the work they’re asked to do - I don’t see the issue?

Reply on news.ycombinator.com