I really don't want to sound negative, but I find this difficult to believe. Sorry if I sound too harsh, but experienced engineers who don't perform better than recent graduates sure it's a thing, but 50% of the ones you have interviewed don't perform better than a recent graduate? Perhaps you were exaggerating? Or perhaps your interview process is really focused on what recent graduates know best (popular algorithms) and not in what experienced engineers know best (how to deal with real world codebases). Again, I don't mean to sound harsh, I think perhaps that "...at least half..." was just a way of saying "Dalia was really good" (which sounds more credible).

There's an adverse selection problem with interviewing, in that people who are good tend to disappear from the labor market and when they do appear on the labor market they get snapped up quickly. New grads don't have this adverse selection effect: there is a very good reason why they don't already have a job. This is why companies invest so much in internships: this will often be the only time to snap up a promising young developer before they start building a career at your competitor.

https://www.joelonsoftware.com/2006/09/06/finding-great-deve...

Doubtful. There is constant churn in tech, as the best way to get a raise is to switch jobs. It's well documented that junior/senior engineers (and beyond) switch jobs, on average, every 2-3 years. Longer tenures are generally favored due to vesting schedules (though I've had several friends ditch Amazon before the [iirc] 4-year cliff).

(Or alternatively, you find a fast-growing startup that's growing faster than the wealthiest companies in your industry, hop on the ground floor for stock options, and ride the stock up. Once that happens you don't need money, though.)

You switch jobs every two years, applying to four companies, getting two offers and taking the one that most closely doubles your salary, then you’re gone from the market again.

Meanwhile the other 1000 guys who applied for that gig you took are still out there looking. They'll apply for 50 jobs this week, 50 next week, and 50 more every week for the next two years. They’ll be your competition again next time you’re on the market.

Now think about how many of “you” it will take doing your four interviews every 2 years before you are anything but noise in the process from a hiring perspective.

It’s the reason guys like you get offered nearly every job you apply for. Because the person in charge of hiring is amazed to have found somebody capable of programming computers at all.

As a result, my interviewing skills have deteriorated significantly. I wouldn’t be surprised if a talented programmer straight out of college could out-interview me even though I have much more experience.

I put problem in quotations because it is very hard to complain about being paid too much :(

In developing countries your story is a bit more common but even there you can accelerate things by switching companies once every few years (somewhere between 3-5). After a while you probably want to stay put to get promotions.

1. You have to solve a problem immediately (whiteboard or now in a webbrowser)

2. It's often frowned upon to research via google search something, although in real life most people do it all the time.

3. you have only an hour to solve a problem, and what if you don't see the 'right and easy way' to do it? In real life things aren't so simple.

4. Don't forget it's a performance! You have to be on your best, sharpest most intelligent and witty behavior, think through things, it can be exhausting.

These are just a few of the ways that interviewing is artificial.

I was looking last year, I flunked my few interviews. Then I paused and spent a few weeks working through CtCI. After that I was easily getting offers. Was I a better programmer than before? No, of course not, I had just learned how to put on a show, and I forgot it all the moment I had an offer I was happy with.

We're in our early 40s. About half have been at their current place of employment for close to 10 years now. The other half seem to change jobs every couple of years, although some of those had a long tenure before the recent bought of job swapping (they haven't found a new place they like).

What a shitty thing to do.

Companies sure as shit don't care about you, and you caring about them gives them a leg up, not you.

I don't see a big problem with it. While it may 'waste' some time on the company's part, it also sends a signal of, "hey, you could get some of these really high quality engineers if you were willing to [pay more/offer more vacation/offer remote work/etc.]".

Now, if you're unwilling to accept an offer from a particular company even if their terms blow you away, then yeah, that's a dick move.

I think it's a smart strategy to pick 1 or 2 companies you'd never want to work out, including for low pay, and do your practice there. You should tell them if you pass why you don't want to come there, including for the low pay.

1) someone coming from a big corporate job where they were undervalued/underutilized

2) someone coming from a different region, different country, where they have no local network

Only inside a community, not coming from outside.

I’ve had it happen to me and done it for others.

My favorite is businesses and colleges that don't take applicants from PO Boxes.

We need better proof and better data than a 2006 blog post.

She cleared interviews at both Repl.it and Google. She implemented an assignment based on operational transformations and having studied this myself it’s far from trivial. If you folks ever retire this question Id love to have a crack at it.

She also cleared the Google interview which goes deep into algorithmic aspects and system design. Which means that she’s brilliant at both abstract design and execution.

To be able to do both while graduating does place someone in the upper brackets of engineering skill. Some don’t fulfill it because of other reasons but that’s another matter.

It’s not like the bar is being lowered. They’re held to the same bar as Stanford and MIT grads who apply and they come from a third world country with only a bit of remedial coaching. It’s what top school grads already know from their campus coaching and tips from their seniors.

People who say this is akin to gaming the process you too can easily get the same by dropping a trivial amount of money on CTCI, EPI and Pramp for mock interviews.

I wrote this a little bit too much in frustration but I’m tired of these assumptions that people from the third world cannot show incredible potential sometimes exceeding their first world peers and are only held back by bad systems and politics.

There are untold depths of genius all over the planet. We haven’t even come CLOSE to most people on earth realizing even a fraction of their potential.

“ I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops.” - Stephen Jay Gould

> taking away from an incredible achievement here

> held to the same bar as Stanford and MIT grad

> you too can easily get the same

> assumptions that people from the third world cannot

These have nothing to do with the discussion, which is that it’s disingenuous to call a new grad better than an experienced engineer in that the interview process is obviously biased towards new grads.

No one is complaining that she got the job. We all know how to “game the system.” Whether from Stanford or community college, anyone with Leetcode and a few weeks can easily pass these interviews. So I am not sure why you are implying that people are bitter about some perceived inability to get such a position.

People are just pointing out how disingenuous of a statement it is for the OP to say “better than an experienced engineer” when they have literally no metric to judge this. And no, system design interviews don’t really count. A few days with the System Design Primer will solve that.

>These have nothing to do with the discussion, which is that it’s disingenuous to call a new grad better than an experienced engineer in that the interview process is obviously biased towards new grads.

From root comment: “Dalia and the other youngsters from Palestine performed better than at least half the experienced engineers I've interviewed in the past.”. There’s nothing disingenuous about the interviewer’s belief.

From Dalia’s article: “repl.it’s interviews were really different. First they gave me an operational transformation homework assignment.”, “For my second interview, about two weeks later, I had to prepare a presentation with ideas to improve the product.”.

You are making stuff up about Leetcode and whatever - the article itself has facts that show your assumptions to be wildly incorrect.

That is, of course, if your resume doesn't get tossed out for not being diverse enough [0][1].

[0] https://www.theverge.com/2018/3/2/17070624/google-youtube-wi...

[1] https://www.wired.com/story/new-lawsuit-exposes-googles-desp...

That anyone reasonably clever which spends months studying CTCI, EPI and Pramp and whatever else and doing mock interviews will pass the interview, while an experienced programmer will not just by virtue of their skills and knowledge.

Spoken like someone who has never interviewed at Google.

I have 6 years experience, a M.S. in CS, have worked at SV unicorns, and studied for 2 months for my Google interview and still failed. Am I an idiot? Possibly, but more likely that the interviews are hard and there is a lot of randomness.

Until you actually study and try yourself, don't talk about how easy it is for anyone "reasonably clever".

I have performed a lot of coding interviews (probably 400+), I'm painfully aware of how limited the signal is that I can reliably read from 45 minutes with a candidate

I deliberately ask a question that has no algorithmic or data structure component to it (and tell candidates that) it's just a simple problem solving coding question which allows some insight into general coding and engineering chops

I still see experienced engineers struggle. It is hard to pinpoint exactly why, but lack of preparation/practice definitely seems to be a problem

Covid appears (at least for me) to have killed off the whiteboard

I've seen experienced engineers who I know for a fact can code and solve problems decently completely freeze and blank out during easy live coding challenges.

I think interviewing is a stressful situation. It's hard for reasons outside an applicant's knowledge or intelligence. Interviewing seems to be a skill in itself. I know I hate it... :(

I don't know if that's still a problem at Google, but it could explain why some people don't pass the interview process even though they are reasonably clever.

I did it a little while ago, this is the question: https://otcatchup.util.repl.co/

Read the post if you haven’t because it touched on our process. And watch this video to learn more: https://youtu.be/kABh44IVWMo

I do a lot of hiring at a "big n" company and I'd agree with this

My experience lines up exactly with what the GP said. The overwhelming majority of experienced engineers that are interviewing simply can't write useable code. I understand it's hard to believe, but it is the reality whether you believe it or not.

Interview processes are significantly biased towards seeing large numbers of non-hire-able people over hire-able people. It's not surprising that someone with few connections and just starting their career could perform well against the biased view of an unfiltered interview pipeline.

oh, nostrademons beat me to the punch.

A real on-site interview should be:

1) give vague instructions on a fixing/modifying a moderately complex piece of software

2) have them ask good questions until they get to the heart of what they are supposed to do.

3) work with someone to accomplish this task. Use google or whatever else you need to finish it.

This interview should be 5 hours long including lunch. This is your best indicator of success.

My wife just interviewed and got a new job in the past week, for a proposal writing job at a decent-sized tech consulting firm (300 employees) where she'll be making six figures.

To get this job, she spent about two hours of preparation learning about the company and hunting down samples of past proposals (this is her standard process for preparing for an interview, by the way), then had one 30 minute interview with her would-be boss, and one 30 minute interview with three would-be coworkers (at the same time). She had a job offer a few hours after the second interview.

Now she's had several years of prior experience for some pretty large companies and worked on very large proposals in the past, but the difference seems to be in her industry they trust past experience, whereas in tech it has almost zero value, they just care about whether you can past their coding exercises.

The programmer/software engineer interview process is just so broken. I have to grind toy algorithm coding problems and rewatch algorithm lectures for weeks just to psyche myself up to go through the interview gauntlet again.

I've even neglected getting back to pings from recruiters just because I wasn't feeling up for going through the whole process at that point in my life and/or I knew I wouldn't have enough time to prepare myself for the interview to even have a chance to make it through it and I'd be wasting my time.

I get that employers are getting inundated with people that they at least feel they couldn't code (I bet they'd think that about me as well if they brought me in to interview today, even though I've been basically a one man dev team for startups before and currently developing and supporting software that services millions of customers) so they feel the need to verify the skills.

I just find verifying skills in the midst of the interview very difficult, especially if it's testing knowledge I haven't used very recently, since my brain is constantly context switching out technical details and platforms and apis based on my current work needs.

There needs to be a good way I can prove "Hey, I really can code" outside of an interview, once, that's somehow trusted. I thought that's what a degree in Computer Science was supposed to prove, but apparently that was a waste of money.

Some people say this is what fizzbuzz is supposed to do. Others, particularly people outside the USA, say the solution is engineering licensure. A lot of people in hiring think that's not enough. But what is definitely lacking is institutional trust between companies outside the FAANG bubble, and perhaps blue chip companies like IBM.

The problem of low institutional trust means that working for Company A as a programmer for years means nothing to Company B, and you have to prove yourself all over again if you have to interview for Company B even if your GitHub is loaded with open source side projects. So the problem is not proprietary code or not being able to show your work to a new employer, it's trust.

Anyway, the developer interview culture is severely broken, and it's been discussed a lot elsewhere on HN, yet nobody has been able to solve the problem. We have smart thermostats, can order books with our voice from the couch, and 3D print a house, but we can't solve hiring and just have to accept the status quo if we work in tech.

I'm of two thoughts.

One, the hazing ritual (reversion to mean) is because we forgot how to interview properly and can't think of any other strategies. For this, I mostly blame corporate HR wankery and failings.

Two, some Mensa style geeks do a weird bully flex, probably out of insecurity. And per our common negative attribution bias, these few "bad apples" are the ones we remember.

I once interviewed at a place that was almost two solid days of 30 minute interviews, one after another. By the end of the second day I completely didn't care about anything they wanted to ask about or what they thought about my responses. I think this stamina crushing test was actually part of the evaluation. Not kidding about that.

It was just merely stating a fact that Dalia and her acquaintance perform better in the hiring process than at least half the experienced engineers he has ever interview.

If anyone is jumping to conclusion its you guys

I don't know who "you guys" is.

* Experienced engineers will perform better than graduates in general

* The distribution of experienced engineers who are poor performers won't over represent application to one particular company unless they are an outlier (Repl.it is not Google)

This makes me wonder what Repl.it's hiring process is and why it is not doing well at attracting good people.

In my experience there are a lot of experienced engineers that are very low quality, and it isn’t uncommon to have experienced engineers that have negative productivity (working with them costs more than they produce). See https://thedailywtf.com/ . Starting with recent grads (filtered for potential) can easily be more productive over time, because you can teach them good habits.

> The distribution of experienced engineers who are poor performers won't over represent application

Hiring being inundated with poor quality candidates is a common problem due to adverse selection: https://news.ycombinator.com/item?id=26254114

"other youngsters from Palestine performed better than at least half the experienced engineers I've interviewed in the past."

This comment caught me a little off guard. You are saying that these young people with no experience perform better than half of the experienced engineers you interview.

My question is what is wrong with your hiring process? It sounds broken.. What part of the process are the experienced developers failing in? What are you asking for in candidates that these experienced developers lack but can be found in this group of inexperienced engineers? Curious about salary, would you say Dalia friends makes the same as an experienced developer?

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.

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.

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

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.

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

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

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.

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.

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

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