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

Sounds like they failed to have a plan to correct said behavior that caused the others to leave.

Sometimes it's just not correctable. Bad hires happen. Not everyone can do well in a given position. The idea of dragging things out until firing is a "last resort" makes it sound like it's a long process and that is a bad thing. It can create a poisonous working environment.

> The idea of dragging things out until firing is a "last resort" makes it sound like it's a long process and that is a bad thing.

"Last resort" does not mean "long process", it means, "only when there is no reasonable expectation of being able to improve fit to an acceptable level".

Whether it takes a while to reasonably determine that or not depends on what the problem that has manifested is and what opportunities there are to alter conditions to address the problem.

Why did the bad hire make it past the probation period? The purpose of that period is to weed out the bad hires.

Internal processes only take as long as you make them. Correct the issue in 2 weeks. Not solved? Let them go. It doesn't have to be some 6 month ordeal of trying to get things worked out. The point is to have a process to deal with these things rather than telling the employee to pack up their shit and get out.

It's not always easy. I was a bad fit for my last gig (FP/OOP culture clash, mostly), but it took 4 months for them (and me!) to see that. It could have been much quicker (a month), but neither my elder colleague nor me had the gut to tell our hierarchy we probably can't work together: I was still on probation, and my colleague approved my being hired.

Besides, if they did let me go after a month, I'd have resented them for not giving me a fair chance.

How did you get hired in spite of that, and how was it such a big problem that it needed a firing?

Well… it was a combination of that, and general downsizing. They would have put me in another team, but they were all shrinking. So they didn't keep me.

How they didn't see it coming… Well, we informally discussed the project, my OOP knowledge etc… But they didn't read my blog, where my biases are quite clear. Come to think of it, my colleague didn't read the coding style rules he asked me to write either. If he had, some issues would have been addressed right away.

I was also told I would work on equal footing with my colleague, participate in technical decisions… He was my elder, and in the project from the very beginning, so he wasn't really my equal. But I failed to treat him like my boss, and it turned out to be such a big problem that the hierarchy made it official 10 weeks after my arrival.

My first commits weren't object oriented, so my colleague deduced I didn't know OOP. I lost all credibility at that point.

Finally, I was too careful. My unwillingness to rush the next feature as fast as possible without any regard for technical debt was interpreted as "doing research". Sorry, I just can't work that way. I was told we would "rewrite the code 50 times over", which would indeed have compensated. In practice we never rewrote anything. The first version always ended up being set in stone. Even code we both agreed was a mistake.

On the bright side, I did adjust over time, and they even said so (to me and my hierarchy). Maybe that's why they kept me for so long. But it wasn't enough to keep me in the middle of a general downsizing.

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