> There's no reason at all why the interviewee cannot drive the direction of the interview, rather than being driven.

You know how they made a program pass the Turing test? They didn't make it smart, they hardcoded a conversation where the program drove the conversation to where it wanted it to be. That way the person interacting with the program was passive, so they never noticed that they were just interacting with a stupid program in the 5 minutes they had with it.

The same happens in interviews, if you take a person who don't understand tech, but have watched a lot of conference talks and read some papers and he can re-tell those, and he even remembers answers to common questions from the question parts there, but he doesn't understand much at all of what was said he just remembers conversations, then that guy will look like a world class expert if he gets to drive the interview. But once he starts working he didn't know anything at all, he just learned to talk about these things not do them. Some would say "just dive deeper into his knowledge!", but you can't always do that, if you aren't an expert yourself in his subject area you wont be able to drive down deep enough to find his flaws, and since he is driving the conversation most likely you wont be an expert on what he is talking about.

5 minutes isn't long enough to notice that the conversation switched topics every time you asked a deeper question.

If I accidentally hired a guy like that, I'd consider him for a marketing position. :-)

The person could have just learned to code in all that time spent watching conference Q&A sessions to con interviewers.

This does seem to be the threat model many interview processes are meant to protect against though.

I understand there are costs involved in hiring then firing someone, but maybe that should be reserved as a way to deal with the most outlandish fakers and let the rest of us have a quick Google or two during coding screens.

If you are smart and a hard worker then learning it properly is easier, yeah.

But if you are lazy and prefers talking to people and watching videos, so you spend your day talking about these conferences with your colleagues rather than doing work then you have the scenario I'm talking about. It doesn't require some genius conman, basically any guy who prefers to talk about things instead of doing things will more or less fit this description. The degree they lack real skills depend on the degree they prefer talking over doing, but such people will always over perform at such interviews.

Lastly since the talkers get rejected by all the leetcoding firms, you will have an abundance of talkers that can't perform in the hiring pool. So the problem with talkers is way worse today than 20 years ago.

When I have to game an obviously flawed interview because I want the job, I try to drive the interview. Make no mistake, this is a social skill. It’s not something I enjoy, it’s just a learned skill for me. But I do it because I want the job.

Often I feel like a con artist for doing this, especially if works to overcome a superficial interview. Sometimes it turns out my perception was correct and yet it turns into a better interview because I’m adding value to the interview where the interviewer had gaps…

What's really great is if you can get the interviewer talking about themselves. If you're lucky you'll spend the entire interview nodding and saying things like, "wow", "that's really cool. How did you come up with that?". At the end, if it's the kind of interviewer that will talk about themselves for an hour straight they're going to love you, just sat there and let them be the center of attention. The problem is do you want to actually work for someone like that.

This is how I got a job with a bunch of really smart folks in the early 2000s (they were all MIT grads and I was a graduate of a state liberal arts college in NY.) It was several rounds of interviews and a couple of the folks interviewing me (who clearly liked me) warned me that the interview at the end would be the hardest because the interviewer was an old non-nonsense engineer (MIT CS degree and MIT MBA.) It was intense for sure, but I had read somewhere that (as you stated) if you can get them to talk about themselves and engage them: A) they will love you and B) you'll run out the clock. I can't recall how I got him to talk about 'the good old days' of programming, but I did and I don't think I had to answer more than a handful of questions in that hour.

His feedback read like this: “Good culture fit, good soft skills. I really liked them. They seemed to understand and appreciate difficult and interesting topics.”

I assure you there are worse ways to behave in an interview. I’ve passed on people who were smart as a whip but nobody wanted to work with. And nobody wants a dead fish who just sits there waiting for the next problem to solve.

So that engineer was a full-nonsense interviewer :)

I suppose in my case he might have been less effective at assessing my technical abilities (there were multiple technical interviewers throughout the day.)

A word to interviewers:

Watch out for this. It is a real phenomenon. If you "enjoy" thr interview, you are more likely to think the candidate did well. And if you spend a lot of time talking about yourself, you are more likely to think the candidate did well. Don't be fooled. Have a rubric that you can objectively measure the candidate against.

I agree that an interviewee should be an active participant (though not being is fine too given the state of interviewing), however attempting to drive it themselves can really backfire if the interviewer isn't expecting it and/or is bound by policy to actually ask certain questions or go through some process. I still remember one guy who wanted to drive things a bit too strongly, which for most of my section was fine with me because I was still able to get the data I wanted out of it and hopefully he got some of his, though at a point I really insisted he actually code a working solution to a problem in the IDE setup for him (requires like 15 lines of code, it's embedded in the context of a larger program) rather than continue to whiteboard/pen-and-paper general thoughts. He did, and I gave him a positive recommendation. But in the after-meeting my coworkers were less happy with their sections (one of them even brought up the sense he was trying to 'run the clock'), and some of them were still new to interviewing and didn't know how to handle a more 'aggressive' candidate and apart from not enjoying the experience couldn't get the info they wanted, so the eventual decision was to say no to him. I still think he would have done fine, but hey, it's just another element in how broken our interviewing practices can be.

The interviewee doesn’t know what the day to day job will look like, so they may wind up talking about entirely the wrong parts of their skills & experience. The interviewer has a much better idea what they need to learn about the candidate.

Perhaps this is less of a big deal for a generic position that’s the same at every company, but if you are matching someone to a very different role than they’ve held before, you may be interested in only certain pieces of their resume.

Walter you (with your credentials) do realize you would never go through the "standard" interview loop like the rest of us nobodies would go through right? We are lucky to be forgiven for only solving 2 LC hard problems instead of 3+ in an hour whiteboard coding interview!

I didn't have any credentials at the time, which is why I felt the need to be proactive in the job interview.

I also interviewed at Microsoft (just down the street) a few years later, and got the standard interview treatment.

I know what quicksort is, and I've implemented it more than once over the years. But I could not implement it off the top of my head at the moment without doing a quick refresher on the algorithm.

I was once assigned the task of speeding up a program written by <famous programmer you've heard of>. In perusing the code I happened to notice that there were two custom bubblesorts buried in it. I replaced them both with calls to C's qsort and got a nice boost. Was <famous programmer you've heard of> a fraud? Not at all. Anybody's code can be made better. I've been found guilty of having hidden quadratic code many times.