I didn't say it did.

I wasn't saying that new grads are, on average, better than experienced hires. I was just saying that experience is not everything.

An experienced hire will outperform a new grad on a "build this project in 3 hours" test. But the new grad might actually be a fundamentally better engineer - they might be smarter, more careful, etc. Given 3 - 6 months of training, the new grad might actually make better technical decisions.

Obviously, the reverse can also happen: the experienced hire might be not only more knowledgable, but also smarter, more careful, etc.

The problem with the "build a project in 3 hours" test is that it weights experience and knowledge so heavily that you end up eliminating people who could be great, with a little bit of training.

Again, a new grad could also be a fundamentally terrible software engineer (there are fundamentally terrible software engineers with experience and with no experience). And in 20 years, they'll be a terrible software engineer with 20 years of knowledge and experience. They might be able to build a 3-hour project better than some smart inexperienced coder but I'd still rather hire the smart inexperienced coder (assuming I have some time to train them).

Ultimately, ALL hiring processes are flawed.

A hiring process that can be gamed by reading a book sold by the process giver is especially flawed and morally corrupt.

A hiring process that acts as if years of experience mean nothing and which reduces your career to a score on a web page generated by a terrible constructed test is especially flawed and inhumane.

The companies that sell these products are profiting from hurting people.

> A hiring process that can be gamed by reading a book sold by the process giver is especially flawed and morally corrupt.

Hahaha, please tell me another one Mr. Trump.

> A hiring process that acts as if years of experience mean nothing and which reduces your career to a score on a web page generated by a terrible constructed test is especially flawed and inhumane.

Being old is not an indicator of success.

You seriously seem to live in some wonderland where the quality of a candidate just magically appears out of thin air.

I want candidates to have studied. Studying isn't gaming. Studying is being smart. I want candidates that studied. Those that didn't I don't want. They don't want the job badly enough.

I routinely test older candidates who can't program anywhere outside of the little box they made for themselves, and freak out when they see a programming language that isn't the one they've used for the last 20 years. Is that inhumane?

Gayle is awesome. Cracking the Code Interview is a really great book, and I credit it for getting me through some of my interviews. Everyone here poking at her are people shooting the messenger for delivering the inconvenient truth.

I have no idea why I am being compared to Donald Trump.

> Being old is not an indicator of success.

I didn't say it was. A history of success is an indicator of being successful though.

> You seriously seem to live in some wonderland where the quality of a candidate just magically appears out of thin air.

You seem to love in a wonderland where a candidate's aptitude can magically get turned into a score on HackerRank.

> They don't want the job badly enough.

Yeah, fuck them for not wanting to waste time on your startup that will likely bomb in a year. How dare these people want a personal life.

> I routinely test older candidates who can't program anywhere outside of the little box they made for themselves, and freak out when they see a programming language that isn't the one they've used for the last 20 years. Is that inhumane?

And I've met hotshot new grads who think they're the best thing since static typing, yet can't benefit from years of experience in how software is made in the real world.

> Gayle is awesome. Cracking the Code Interview is a really great book, and I credit it for getting me through some of my interviews. Everyone here poking at her are people shooting the messenger for delivering the inconvenient truth.

I only now realized the user who I am going back and forth with elsewhere in this thread was the author of these books. I am pointing out the flaws in these types of interviews and how they are very overvalued. The book's ability to get you through interviews means nothing about how those interviews select for people who can do the job, only that the book was designed to help you get through interviews.

People don't consider that not only does the software engineering process weed out those that don't know algorithms, it also weeds out those that don't have the discipline to sit down and study for a couple of weeks.

I did not create this process.

I also don't think companies should dismiss years of experience. That is valuable. It's not everything -- you can, of course, have bad but experienced engineers. But experience is certainly valuable. It makes you a better engineer.

If a company entirely relies on coding interviews, they are making a mistake.

Essentially younger are better amiright? Otherwise why are they smarter than someone who actually has real world experience? Is your new grad smarter than Jeff Dean? Or Rob Pike?

Nope. Not even close to what I was saying. In fact, I repeatedly said that I am NOT saying that inexperience people are better/smarter. I'm not sure how you got to that, other than pure determination to believe I was saying that.

This is pretty simple.

Experience makes someone a better software engineer. Smartness also makes someone a better software engineer.

Some experienced people are smart. Some are not. Some inexperienced people are smart. Some are not.

All else being equal, I'd prefer to hire experienced over inexperienced, and smart over dumb. But, sometimes, all else isn't equal.

Given two candidates (P = smart but inexperienced vs Q = dumb but experienced), who would you rather hire?

I, personally, would rather hire P. I can train P and turn them into a pretty good software engineer -- and P will only get better with time.

A process that is a "build this project in 3 hours" test will favor Q. If you prefer Q over P, then that's a great process to have.

If you prefer P over Q, then this probably isn't the right process for you. You might do better with the whiteboard coding/algorithms process -- or some mix of different things.

And, you know, that's okay. All interview processes are flawed. A company should pick one that is the least flawed for their situation, be aware of the weaknesses of their process, and do what they can to mitigate it.

Tech companies are generally aware that one of the weaknesses of the algorithm-focus is that good people sometimes do poorly do to lack of preparation, and that's why they encourage preparation.

Experience tells me you are wrong. Experience will also tell the young ones why they are wrong.

Wrong about what? That all hiring processes are flawed? That some new grads could be better than some experienced hires, 6 months down the road? That build-a-project-in-3-hours doesn't weight experience heavily?

How does repeating the same tasks every day for 20 years make someone a better software engineer?

There are better and worse candidates in either camp. I developed software professionally for about two years before graduated. Is it 20 years? Nope. Conversely, it's more experience than many college grads. Working with super talented individuals with an express focus of learning/improving also gave me a hell of a lot more than "a fresh recollection of algorithms."