I'm not sure you're going to get what you want out of that quiz.
I'm figuring that a significant majority of the interviews out there fit a profile of:
- a manager or the hiring manager is somewhere close to first in line for the interview
- you may interview with a secondary manager who is a peer to the first, or the manager's manager (depending on the organization's process)
- you may, after some number of managers, have a peer interview or a team interview
Certainly, there are companies that break this model, and do peer interviews first or something even more creative. But in my experience, the list above is pretty typical. Dealing with the overhead work of initially finding candidates is often relegated to mid level managers since they can make the context switch easily and have a pretty good basis for judging what they want and need.
I point this out, because I don't know about you, but I don't see is as ideal for my boss to know as much if not more about the nitty gritty details of how to do my job than I do. He's hiring me to be his expert. If he wanted to be the expert, he wouldn't bother to hire me. So I'm confused on why you want your manager to be able to answer something as nitty gritty as efficient algorithms to copy singly linked lists.
I think if you find a manager who can answer this question, right off the top of his, with no hemming and hawing about how long it's been since he did this kind of work... then you have found a manager who is likely to micro-manage you - his head is more in your job than his own.
Instead, I would advocate for making enough inquiries to see if you have a good management culture and one in which a good software developer can thrive. My top ten of management requirements for software engineers would be:
interested in the day to day problems of software engineers, good sample question - "what have been some recent problems your team has had to work through?" then look for the degree of passion and engagement and whether he's misusing terms.
basic knowledge of the craft, and core processes, with strong understanding of the purpose of the software - "what is your current project? Can you give me examples of what software process you used and how your team makes use of it?" - no lifecycle or process ever works exactly how the books/websites say it should... so how has the team customized it to fit their needs? "what's a software lifecycle?" is a very bad sign, but if there's an answer, do you agree with it? For example - "we found that 2 week sprints didn't give us time to fully test, so we moved to 3 weeks and hope to improve automated test efficiency this year" might be OK. But "we found that we can't test in a sprint, so we're delaying all integrated testing until the end of the project" is a danger sign that both the manager and the team are in the dark on the goal of this particular lifecycle.
Has a solid plan, not just a hazy vision for developing his team's skills - "what's your policy on continuing education?" is a standard question, but don't let him get away with "our company offers X dollars a year, you're free to submit an application, more corporate HR provided blather" - push a bit. How many people too training last year? What does he see as gaps in the team? What works better for the organization - conferences, college classes, bootcamps? What does he do to keep himself up to date, what are his bare minimum expectations for his team? How does the team do knowledge sharing?
has his gang's back in a corporate battle - no team will ever totally win (or we'd all be working in offices which are 10/10 on the Joel Test), but how does this guy get his team's back in the software team meets Corporation that Does Other Things conflict. A particular area is requirements elicitation and bug fixing - those are usually the two areas where things don't ever work to complete satisfaction, and where the manager has to be an active participant to make sure the team is optimally productive, while users aren't going nuts. How does this work, what role does the manager play in resolving conflict and setting expectations.
If you get to a peer....
So, I realize that in at least some contexts, you have the option to talk to a peer. I really still wouldn't ask a very "quiz-like" question that could come off as slightly offensive.
But I would aim to engage in a serious discussion that shows you that you're talking to someone smart. This has 2-way benefit - when two people have an intelligent, interesting discussion, both usually walk away thinking "that guy was smart, helpful and fun to work with" - which is exactly the response you want to evoke as well as recieve when you do a peer interview. As a manager, this what I usually aim for when setting up a peer interview with one of my people (and being a clever manager, I send the smart, charismatic people on my team... not the dull, conversationally-impaired, frustrating to talk to people - you can meet them after you sign on the dotted line...).
A quiz is likely to evoke a bland answer, a question about current challenges and recent gotchas is likely to evoke a serious discussion that will show you what it's like to work with this person. So I'd ask:
what's the big unknown or problem on your team today? - and then look to get involved in the solution - "have you tried...?", "what about?", "hmm... I've never worked with that, tell me more..." - are all good follow ups.
what was the best lesson learned from your previous project? (and "blink, blink... we don't do lessons learned or really any closure on our projects" is another very bad sign) - and the follow up - "what are you doing about it on this project?" is another one - after all, you want to find a culture that actively improves upon previous mistakes, as well as being a group of people smart enough to critique their own work...
These are both really just hooks - jumping off points to drill down into something solidly technical. The goal being to come as close to a real work-day discussion that will tell you if this guy is smart enough and fun enough to work with that you'll enjoy working there and thrive on the experience.