One time I sat down with a potential hire and went over a trivial PR. Nothing hard just some code to look at on GitHub to provide a familiar environment.

Why? To use it as a way to just look at our tech, get completely off track, and go down the tech rabbit hole. Good devs get really excited and talk about what they're using, what libraries they like, what they'd like to work with, etc.

Best hire I've ever made.

"Puzzle solving" is a nice way to dumb down the importance of good software engineering vs good coding skills. This is especially important at the big 4 or 5. They don't really, truly care what languages you know or what stack you know. They will give you the environment to use whatever you want.

What they need is someone who is good at solving problems, which ties into your comment about dealing with bad situations. This is something startups eventually adopt once they mature past needing a web developer to just throw together a website for them, and on to someone who is more flexible and loyal.

So please don't reduce the importance of good engineering down to "puzzles". They are a good indicator of someone who has all those qualities you describe.

And i wouldn't limit anyone to the big 5. If you believe Google's interview is pure memorisation and no problem solving, don't interview with them. My point is a good interview knows the importance of problem solving, whether solved correctly or not, is about how you solve the problem, and so they design their interviews thusly. That's my point which is contrary to the common sentiment here that "puzzle" interviews are a waste of time..

This is especially true when really wealthy companies will teach you the technologies you need to learn. You simply can't teach a good problem solving skillset, though.

Good engineering is important. But solving a problem on a whiteboard isn't "good engineering". The ability to solve whiteboard puzzles in a time boxed adversarial setting, is nothing at all like solving large complex engineering problems through "good engineering" practices.

I know plenty of capital E Engineers. None of them have whiteboard interviews. They are expected to solve problems, but none of them are expected to draw schematics for a bridge while someone watches over their shoulders.

No other non-performance based industry has this kind of weird hazing ritual. Whiteboard interviews are nothing more than the current fad--they definitely aren't necessary requirements to hire "good engineers".

^this. Somehow companies got confused into thinking that something between an algorithms test and an ICPC contest on a whiteboard was a sensible way to interview people. Google takes a similar approach with Code Jam (a recruiter contacted me because of it apparently.) At least they don't make you do Rubik's cubes anymore.

Do you think the school system also isn't a good way to vet people, then? Since exams are basically just "whiteboard interviews".

1. Unless you are in a performing arts program, exams aren't really anything like whiteboard interviews. They are much more limited in scope. You generally have more time. There's no one watching your every step. You don't have to talk while solving a problem. They tend to be written by people with at least some formal training in pedagogy. They don't tend to be written and administered by 24 year olds who are trying to prove how smart they are. Your job while in school is to study for exams, so you tend to have more time to do so.

2. This part is more important. School is about a lot more than exams. Projects were usually about 50% of the grade in CS classes.

If you made it through 4 years of the CS program I went through, you know how to program, or you paid someone to go for you for all 4 years.

So yeah I'd take a B average from my school as proof that you know how to program.

But I wouldn't make it a requirement.