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

Almost every company is terrible at firing ineffective engineers. Even some of the companies that are famous for doing so ("'meets expectations' earns a generous severance package!") don't necessarily manage to accomplish that in less than a year. This stuff sounds very simple on message boards, but is much harder to do in real life.

The first N months of a developer's tenure at a job is difficult to measure because of ramp-up and calibration (even good developers might hop to different teams after getting hired based on work style fit issues). Whole projects can flounder and need rescuing so that attention to ineffectiveness gets deflected to group leads. Most good development shops will try to make things work for a new hire that isn't performing at the 6 month mark, and that process takes a few months.

Once the decision is made to fire, most big companies will PIP rather than fire. Sure, once you've hit the 7-8 month mark of poor performance, your severance from the firm may be a fait accompli. But the ultimate process to make that happen can easily be made to take more than 12 months.

Once you have a year-long stint at a company on your resume, you can bank that "experience" on your resume.

And that assumes a relatively well-run companies. Most companies aren't well run in this regard, and you can be a terrible developer but last 2+ years in most jobs. If you can reliably put more 2+ year jobs on your resume than 1-year jobs, you will end up with what will appear to most companies to be an extremely attractive resume.

Remember, many management-track developers only write code for ~8-10 years. Once you fail up to Dir/Eng, you're basically tenured.

Since almost nobody qualifies candidates effectively, failing up is a super powerful strategy for this field.

Why are the terrible engineers terrible, leading to them being fired (after 1-2 years?)

I've not hired anyone who turned out to be bad at coding, but I have hired people who had other performance related issues, which were difficult to suss out during an interview.

From my own personal performance, my approach to interviewing has led to far more true positives, than false positives, so I am biased towards continuing.

> other performance related issues

What are some examples of these?

Typically it's patterns of repeated performance issues, such as providing estimates then routinely not completing work on time.

Or, failing to complete tasks they've taken on, requiring other teammembers to step up in order to meet deadlines.

There are more extreme cases, like insubordination, theft etc, but they are pretty rare.

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