I don't think I'd ever ask these algorithm questions in an interview. Much better to sit down with a candidate and do some pair programmer. Add some unit tests to some code, add some small new features. Can they grok an existing code base easily. Do they understand why we are writing unit tests. Etc..
I would love these kind of interviews to happen, but it comes to this question - does the interviewer or the candidate is willing to spend this much time? I'm in university, and it would be hectic to give every interview this way.
I see this work better with non-entry level positions, assuming candidates apply to fewer companies and companies have fewer candidates to interview.
I interview for fun as a habit, and pair programming is definitely my favorite kind of interviewing. Like I still get nervous even for interviews I have no intention of following up on, but a lot of those butterflies go away when they mention there will be pair programming. It's just more fun, I get to meet a specific engineer at their company, and I feel like they get their answer way better than if they'd used another technique. Answer as in "is this dude who we're looking for?".
I started "practicing" my interview skills a few years ago by... interviewing with companies. Interviewing is great for keeping your skills fresh, for learning new things, and for meeting cool people working on cool projects. It's a lot of fun! And it has the added benefit of giving you opportunities at new companies, if you end up finding a better position than the one you're in. Just keep it on the DL from management at your current company. For some reason, they don't like it when employees do that.
