4 ms·

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

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 is known for having one of the most difficult exams in the world. There was a group of people standing there that seemed to be already knowing each other. One new person came, greeted them and said they just blew the exam. So they ask him "Where did the guy fail you?". It is difficult to translate, but the assumption in the question was that it was the examiner's decision rather than examinee's fault. Then I learned that he made some stupid mistake and that this is 25th attempt at the exam. Then they started discussion about how unfair entire process is and how impossible it is to pass it. I went and passed on the first try because I have honestly prepared. It is the same with software development. A lot of people just keep complaining and complaining about unfairness of it while they are doing absolutely nothing to get better and effectively have the same level of competence as the people in the story. And all the while they also earn a comparatively very good salary (at least here in Poland if you are software developer for a foreign company you are already getting more than average salary that most non-developers need many years to achieve). My every other interview is a person that cannot answer any of the questions I give and then, can't write a simple piece of code I ask them to. It is possible that a small percentage of these people are truly stressed and I try to employ stress relief tactics to help this on an interview. 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) and that they come through agencies that supposedly screen them and some even hire them and bring them forward as contractors. > Sounds like an extreme outlier. Even companies like Google who are notorious for having long drawn out interview processes mostly just have long wait times in between rounds and recruiter calls. They don't involve 24 hours of talking to Googlers. I summed up the actual length of zoom meetings I had and it added to more than 24 hours. Yes, I am an outlier. But it still does not change the fact that I was looking to change jobs and was willing to go through a lengthy process (actually it was fun talking to intelligent people and I wouldn't mind even if I did not get the job). For me, personally, I am happy to have more time to convince the interviewers that I am the right guy for the job and my good first impression is not just a fluke. The more time I spend on the discussion the better starting point for negotiation I have. I assume that if they spent a lot of time talking to me and are very happy with my answers they would be willing to pay more than if I was just random person off the street that just lucked out giving couple good answers on a very short interview.

jameshush 5y ago
"The more time I spend on the discussion the better starting point for negotiation I have." Ding ding ding ding! You discovered the same thing I have. Put me though six rounds of interviews. I have plenty of time. If I didn't think the job was a good opportunity I wouldn't have applied in the first place. But I know after the sixth round if you still like me, there's a close to 0% chance you have any other candidates waiting around. You have a lot of leverage as a candidate if you go through a long interview process. It also buys you time to interview at multiple other places in parallel.
exBarrelSpoiler 5y ago
> 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 they are in roles that are mostly managerial but not technical. Maybe, again, there’s massive resume lying going on. If something rotten is going on in the heart of our industry, it merits study.
- lmilcin 5y ago
  I spent a lot of time trying to figure it out and I have some theories. 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.

jameshush 5y ago

"The more time I spend on the discussion the better starting point for negotiation I have." Ding ding ding ding! You discovered the same thing I have. Put me though six rounds of interviews. I have plenty of time. If I didn't think the job was a good opportunity I wouldn't have applied in the first place. But I know after the sixth round if you still like me, there's a close to 0% chance you have any other candidates waiting around. You have a lot of leverage as a candidate if you go through a long interview process. It also buys you time to interview at multiple other places in parallel.

exBarrelSpoiler 5y ago

> 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 they are in roles that are mostly managerial but not technical. Maybe, again, there’s massive resume lying going on. If something rotten is going on in the heart of our industry, it merits study.

lmilcin 5y ago
I spent a lot of time trying to figure it out and I have some theories. 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.