I've interviewed hundreds of "experienced" engineers who could not code for the life of them. Not sure why you assumed the process is broken without first asking about it.

I agree with this (maybe not the "you sound bitter" part), but it still seems like there's something interesting going on. Why are Palestinian youngsters outperforming experienced engineers from elsewhere? Presumably we would expect Palestinian youngsters to perform on par with youngsters elsewhere unless they had access to additional relevant education or experiences, right? Maybe there's some selection process that filters out all of the under qualified Palestinian youngsters before they enter repl.it's pipeline?

Hi all, jumping in here as the CEO and co-founder of Manara just to say that all the Palestinians that Repl.it interviewed came from Manara (I think). We have in place a very intense vetting system and a training program to teach these CS grads how to interview effectively. At Google our referral-to-hire rate is 67%. That probably explains this experience.

The talent in the Middle East & North Africa is very strong. We believe it's the next Eastern Europe, which used to export refugees and is now a hub of world-class talent.

It's simply selection bias. Anyone can write up a resume and land an interview. Most great people have jobs and aren't interviewing, so the talent pool of 'active interviewees' is limited to those who either couldn't land jobs elsewhere or are new. It's rare, but sometimes someone takes time off.

The quality of folks coming from a very selective program in a different country, however, has selection bias in the opposite direction; nearly everyone from there is going to be better, on average, than the 'average' interviewer, because as mentioned elsewhere, roughly half (likely a bit more) of people we interviewed could not pass FizzBuzz, despite having stellar resumes.

We saw the same thing with MEET, which I helped teach a decade ago too.

Exactly. I was reflecting on this topic as well and for lack of a better word I started calling it "code fluency" [1].

These kind of programs select developers with much higher code fluency, which is usually the result of a deeper dedication to coding, either in a previous work experience, in their free time or taking part in additional training.

[1] https://thomasvilhena.com/2021/01/code-fluency

You've either have interviewed "hundreds of experienced engineers" who truely couldn't code well

Or

You've interviewed hundreds of experienced engineers who are bad at coding during interviews and under the problems you're asking.

There's a person on the other end of that table. They haven't had the time to think about the problem that you have had.

you probably mean Leetcode, right ?

Can you please omit personal swipes from your HN comments? Your post would be fine without the "you sound bitter" bit.

https://news.ycombinator.com/newsguidelines.html

Done. Thanks for the feedback.

I was taken by that statement that more than half of the people you considered experienced engineers you also judged them to have no ability to code.

But you said I shouldn't assume your process is broken. If those are your results the process is broken.

Either your pipeline of experienced engineers needs to be fixed.

Or your ability to judge either who is experienced

Or your ability to judge who can't code for the life of them.

Your comment made it sound like 51% of experienced ngineers looking for a job can't code when the truth is 51% of your experienced candidates can't. It is broken..

This is not a random sampling of youngsters; it's presumably an interested, motivated, and exceptional group.

This is trite, but I am replying for the sake of learning how to phrase it. A candidate can be broken down into a lot of characteristics:

1. Base technical skills - typing (yes, typing), ability to recognize and solve standard problems, and ability to process information quickly.

2. Familiarity with specific technologies (.NET, Angular, SQL, whatever you are working with). This is vastly underrated for line of business applications.

3. Architectural patterns - DRY, SRP, dependency injection, inversion of control, queue/msg based patterns, etc.

4. Domain knowledge, perhaps company specific

5. Social skills, etc

A lot of senior devs ride out their career on number 4. For a new hire, especially for a junior position, #1 is critical, because there is no #4 to speak of and #3 and #2 are handled by other devs.

From that perspective, it makes perfect sense.

Might it be pay?

100%. Younger devs are more eager to work and prove themselves as well, and that's very valuable for a lot of the lower level work. Those are definitely the reasons for perceived and actual ageism.

Most interviewing is broken and assesses your skill at “programming interviews” and not “programming.”

Experienced engineers can help unfuck a massive complex system. They might not nail your napsack problem right out the gate.

But if you want someone who can nail napsack for you, look no further than fresh grads.

If other people's hiring and firing processes are broken, it might be the case that experienced engineers aren't that skillful.

I'm sure many people's anecdata agrees :)

Skillful judged in broken system is like not being judged at all. If I select who is hired based in their birth month what are we really judging?

The pool is already pre-vetted through another company so in essence they are going to two sets of interviews. If you've already passed one set of interview then the probability that you pass the second one is much higher. That's how you can have a situation where a group of inexperienced candidates perform better than experienced interviewees.

Hit the nail on he head. You could do that with nearly any group. Coal miners, orphans, community college dropouts, deaf people, whatever. As long as your pool is large enough and you select the top handful out of that pool.

I would assume that the employer has to take the statements of these experienced engineers on faith until interviewed where as the student may be a more easily known quantity in advance.

Hard(er) to fudge your knowledge when your standing (even virtually) in front of someone.

Why trust the employer can judge talent?