Earlier quoted context omitted.
I have interviewed hundreds of candidates and worked for many projects over past 20 years. > Are these candidates truly incapable of doing the job, or are the understanding of what the job entails misunderstood by everyone involved? Yes. There is a lot of candidates who utterly incapable of doing their job. Let me share a story. I remember one day I wanted to pass driver's licence exam here in Warsaw, Poland. Poland…
> But I honestly believe most of these people simply can't program. What is even more interesting is that these people come mainly for senior development jobs (I don't interview junior developers) But how do you explain people who don’t know how to program being able to advance to senior roles? Maybe they are able to program but completely depend on IDEs or having reference code to look at in their daily work. Maybe…
First, we underestimate how difficult it is for managers to learn which employees are good ones and provide value. There is a lot of reasons for this.
Maybe they aren't very good engineers themselves in the first place? Maybe they have some skewed measure of what value is (for example they just count closed tickets or lines of code written or some other measure that has little to do with real value?)
Second, some people create a lot of shit that will come around as technical debt later. But understanding technical debt is incredibly complex task for the manager. I have never seen a manager that has good understanding of where their technical debt comes from, forget about pinpointing exact people that are causing it, except for very special situations (like me pointing out a PR and explaining line by line why this is poor development).
They can and do close tickets a lot. They do that because they feel insecure and need justification for them being there. But they will do quantity over quality and will tend to pick simple problems that will not expose their lack of capability.
You can solve a lot of problems by simple trial and error. Which tends to produce poor code.
Yes, they tend to close a lot of tickets. But they also tend to create more problems than they solve.
Most corporate projects I worked for do not require any complex coding. You can get by ctrl-c/ctrl-v-ing existing code. A difference between a good and bad employee will not be in whether they can produce a code that works now. The difference might be whether they can:
- produce code that will work correctly regardless of the changing circumstances,
- produce code that is as simple as possible but not simpler than necessary,
- notice problems with the codebase and take initiative to fix this on the spot (sometimes without anybody else even being aware of),
- notice opportunities for improvement that somebody else will be working on,
- drive communication to ensure the feature that is being built is really what the client needs (rather than what the client wishes), then to confirm satisfaction,
etc.
Additionally, these people tend to create an image of being overworked which looks plausible from manager's point of view. It does not help that other developers might be aware of this but will not say a word to the manager (as it might be considered "snitching" or they might feel they shouldn't do that which somebody else might do for them).
These things are not easy to understand when you are a manager and you are also surrounded by your team that guards every word they send your way.