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.
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.
What are some examples of these?
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.