The trouble for FB is that best developers have free choice of where they are going to work.

Yes, when you need to pay your bills and FB is going to pay a shit ton of money, most people will rationalize, bend and accept FB's offer.

But when people have basically free choice of where they can work this is when most of them actually start paying attention to non-financial aspects of their decision.

FB's model requires them to be able to hire a lot of really good developers. It may take some time, but if they have trouble hiring really good developers they may start a vicious circle with end result that they will be open to being caught by competition.

You say "free choice" like companies are just throwing out job offers for free. They do not and you can find tons of posts on here complaining about how the interview process sucks, does not measure true capability etc, etc. Many people may just not have the time to grind Leetcode juggling a job to pay bills, kids and family. Sorry, but this "free choice" argument is bunk IMHO.

> You say "free choice" like companies are just throwing out job offers for free.

Not for free, you still have to honestly work there. You get salary for value you provide.

In general companies set up hiring processes with intention to hire people. (I know this sounds like a heresy to some ears here on HN). They interviews are set up with intention to hire people while but also filter out people who will not be productive. That these processes are frequently badly designed is another matter.

If you are genuinely good -- they want to hire you. Trust me on that.

The issue is that, sadly, unfortunately, a lot of candidates simply can't do the job. And, tragically, they don't even understand how bad they are and they apply to tens if not hundreds of places making them overrepresented in the candidates' pool. Then they come back to HN and complain how badly these processes are designed, completely missing the point.

Somebody will finally hire them, but why does it have to be me? Could I do something to prevent these people from even applying? Could I do something that, if these people apply, they have no hopes of getting the job?

Sure, some good people who would be able to do the job will be collateral damage but guess what, it usually costs much more to hire a bad apple than accidentally not hire a perfectly acceptable candidate.

The length of the process is supposed to discourage these people from even trying. If you only apply to one or two places, couple of hours of interviews is nothing compared to years of work you will spend there, but if your plan is to shotgun the interviews you can't attend ones that require some preparation, multiple rounds of interviews, maybe a trip onsite, etc.

Believe or not, I just changed jobs and I only "applied" to one company and I spent over 24 hours total talking to representatives of the company over multiple sessions.

If you are good at what you are doing, longer interview just gives you more occasions to prove that. And also learn more about the company.

In my experience even with badly designed processes, good developers will still be better at navigating them than bad ones.

Think about it: you attend an entrance exam where you know only 2% candidates will be accepted. Does it matter how difficult the exam is? No it does not, it only matters if you are better than 98% of applicants.

> The issue is that, sadly, unfortunately, a lot of candidates simply can't do the job. And, tragically, they don't even understand how bad they are and they apply to tens if not hundreds of places making them overrepresented in the candidates' pool.

How did it come to this? You don't see this in other engineering industries. There's not a ton of incapable civil engineers bouncing from interview to interview. You don't hear about how bad aerospace hiring processes are.

Are these candidates truly incapable of doing the job, or are the understanding of what the job entails misunderstood by everyone involved? On the other hand, is something wrong in how software engineers are educated to cause this surplus of incompetents? Does there need to be better training in this industry?

Saying "a lot of people are just bad" without investigation the situation seems rather unscientific.

> The length of the process is supposed to discourage these people from even trying.

The amount of effort invested into the Leetcode prep industry would suggest otherwise. A lot of people are playing the game even if they are under-qualified. Maybe that process will make them better coders. Or maybe, they will just appear to be better coders to you the interviewer.

> Believe or not, I just changed jobs and I only "applied" to one company and I spent over 24 hours total talking to representatives of the company over multiple sessions.

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.

> Are these candidates truly incapable of doing the job, or are the understanding of what the job entails misunderstood by everyone involved? On the other hand, is something wrong in how software engineers are educated to cause this surplus of incompetents? Does there need to be better training in this industry?

Yes, yes, yes, and yes.

Pretty confident that the lack of in-house training has been mostly facilitated by that highly skilled computer people tend to take care of that on their own accord (since that’s how most got there in the first place).

I wanted to say that this echoes my experience perfectly.

After interviewing several hundreds of people, two surprising things stood out:

- a large percentage of technical applicants cannot program even in languages where they claim multiple years of work experience

- this holds true for non-technical applicants too

I think this is a combination of poor applicants being overrepresented in the applicant pool (good ones get hired), the fact that modern job complexity has grown compared to previous generations, and the desire for people to "hit the ground running".

I don't know what's the solution. Fields that require certification don't seem to be suffering as much, but that has significant side effects too. What I know is the times where people would work for the same company for 30+ year, where they'd get taught what they needed on the job, are not coming back.

But then how do these applicants manage to amass experience they claim to have?

Massive lying and resume inflation? Performance anxiety leading to bombing interviews? Maybe the roles they were in didn’t actually require as much programming, or deep understanding of programming as people would expect?

It could just be that a massive amount of work in the software industry is really code monkey work. “Gluing together APIs.” Refactoring existing code. All things that can be accomplished by referring to Stack Overflow copypasta or the existing codebase itself without requiring the coder to have any deep independent understanding of the code or the language they claim to know.

And, if that gets the job done- how high should engineering standards even be if so much of the work is menial? Either able to be outsourced, or one day Autopiloted away?

In almost every industry the bottom is subject to shifts while the top with most ability and experience tends to be secure in their jobs.

If the industry shifts needing less developers (for whatever reason), companies will just set higher expectations when hiring meaning a lot of people will not be able to find a job.

But I don't think this happens. Copilot is not going to solve development problems same way stack exchange and google did not. We got google and se and number of developers only grew.

I am interviewing candidates a lot (I would say on average 1-2 per week for the past 20 years).

At least in case of software development jobs I think there is couple additional factors:

- people who are absolutely unable to do it but have strong desire to get well paying job regardless. I have actually seen this work. Ie. a person that can't program at all be called a principal developer and for years successfully hide the fact she can't program anything more complex than a simple loop.

- young people who tend to completely mistake what the job is about. They think software development is about coding when it actually is about building stuff and coding is just one tool to do it.

- people overpromoted very quickly (most likely to keep them and or avoid salary raise), having very unrealistic expectations. A lot of candidates I am getting are calling themselves senior developers even though they have 1-3 years of experience and are still learning to program. And have no real world experience beside 1-2 projects they worked for. They could potentially become better developers in future. But they are impatient with their careers and are skipping the part where they should be getting experience.

- people who cod do it but don't care. They don't care about development but are intelligent enough and want good salary. The issue is, people do not learn things well if they don't care about them. Halfhearted effort at learning results in mediocre results. In my lifetime I think I saw only a single good developer who did not care about development but he was such a professional trooper that he forced himself to do it well by sheer power of his will.

As to working for the same company for 30+ years, I got to know some people who worked 20+. They usually don't stay in development job and are getting promoted thus removing themselves from the developer candidate pool.

I also don't think it is healthy for your experience nowadays to stay in one place for so long. I think having varied development experience, seeing different kinds of projects with different kinds of abnormalities, is important to be able to understand what is going on in your project on a larger scale. And this is important if you want to advance to something like tech lead or an architect.

Your observations match mine, too. Especially the first bullet point. There are a lot of developer candidates who simply can't develop--even the most basic FizzBuzz level program. But, boy can they talk... and talk... and talk... and self-promote... and charm... and flash a big, beautiful consultant smile... and make the non-technical higher-ups feel great about hiring them. I think a lot of us work at companies where the technical screen is a deal-breaker, but there are many, MANY tech companies out there where, if a candidate impresses the VP with their smooth talking Ivy-league sounding charm, the VP will override the tech-nerd's evaluations and hire them. And then, the impostor can use their charm and political savvy to mask their lack of work output... sometimes for years.

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.

> 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.

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.

Thank you for sharing your detailed experience and insight into the problem. It sounds like this field has a long way to go to produce better engineers. Perhaps the way software engineering education and training needs to be completely rethought. It’s ironic that despite the name, so much of the creation of software lacks the craftsmanship attributes that other engineering disciplines possess.

"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.

> You get salary for value you provide.

Salaries are not tied to value, otherwise developers would be making 7-8 digits not 5-6. Salaries are determined by "market rate" which is a synonym for market fixing. It does not matter what value you provide, only matters how low you will agree to get paid.

> The trouble for FB is that best developers have free choice of where they are going to work.

Thats in most companies no? The builders build from their heart. Until they get convinced to move somewhere very important as victims of their success and burnout. But you get 2-3 years of people giving their hearts out. Its what I call 'paying with love'. You know how they say 'do what you love and never work a day in your life', but what they dont say, is that you consuming that love, little by little, some day you will make a compromise, like an artist forced to paint something they dont agree with, and then again, and again.. until you start hating your brush.

> FB's model requires them to be able to hire a lot of really good developers. It may take some time, but if they have trouble hiring really good developers they will be starting to slide a slippery slope to mediocrity when they can easily be caught by competition.

I am not sure I agree with that, I dont think anybody's model requires constant input of really good developers, most things will work with ok devs, some sharded mysql, lots of ram and a bunch of materialization jobs.

> FB's model requires them to be able to hire a lot of really good developers.

It really doesn't. They need to hire a lot of developers, but they don't all (or even most) need to be really good.

They've got lots of stuff to reduce the blast radius of poor developers. Extensive testing and automated regression. Extensive code reviews (although I don't know how effective that is). Lots and lots of layers that make it harder to do things wrong (but also harder to do things period). Gobs and gobs of meetings so nobody has time to get much done anyway.

Some parts of that need really good developers, but you don't need a lot.

> Worse case, you get survivor bias of people without moral compass, as anyone who cares leaves

Conversely, perhaps that's precisely what needs to happen for the legal banhammer to come down?