<i>"Past performance is no guarantee of future results."<p>I'll predicate this with: there are lots of shitty interviews, but I don't think it's because they ask you to reverse linked lists. It's because the interviewers don't know what questions they're trying to answer.<p>I'm coming up on 15 years of experience. I also feel like linked lists isn't really that relevant for my day-to-day. However, I still think coding interviews can make sense no matter the level.<p>If I only asked you about the past, I would miss out on at least three crucial pieces of information for the general full-time software engineer:<p>1) Are you still able to do the gritty work? Perhaps you wrote a great piece of FOSS ten years ago, but you completely lost it after that got going. Now you're managing PRs, but externally, it looks like you're still doing it yourself, because you're announcing the releases. This is useful even if I'm hiring you as a senior, and expecting you to mentor/guide those who are just starting out with the gritty work.<p>2) </i>How* did you do the work? Was it luck, experience, genious? (Did you call a friend?) Can I give you a problem to solve, and feel confident you'll ask if you don't understand or think it's a bad idea? I.e. how do you react to the unknown?<p>3) Can you communicate with others around you about new topics? Are we speaking the same language? Can I feel confident you understand when I tell you a linked list is a bad solution. If I hire you as a domain expert, this is obviously less crucial. Again, the question is about the daily unknown, not the story you've had the chance to rehearse. (And if your job is simply to reiterate the same things over and over, I should probably just buy a book.)<p>You can use technical expertise in two ways: getting things done yourself, or building rapport with those who do. I have interviewed "seniors" who I wouldn't have wanted as mentors myself, because all they could do was talk. Lacking reasoning skills, or inclination to work together to get something solved.<p>That said, the focus should never be on the problem itself. It's ephemeral, as everyone keeps saying. There shouldn't be any gotchas or trick questions. The problem is just a way to get the conversation going. It must be small enough, and easily explained. When I only have 45 min at a Google interview, I don't have time to explain a problem I'm <i>actually</i> working on. There's too much domain knowledge required. Instead, I have to distill a problem I had in the past to something that's interesting, but simple. That's why we end up with reversing linked lists over and over again.<p>It shouldn't matter if the problem is fully solved or not in the end, as long as the method is sound, and we understand each other. It doesn't matter if we go on a tangent, as long as it's enlightening. Also, I'd add that I don't think programming interviews should be the only thing that's happening, especially not for people with experience. They just happen to be the most contentious, and come up a lot in discussions.<p>(As someone who helped build Spotify's tech recruitment pipeline, and having interviewed SRE/SWE candidates at Google.)