Algorithm questions could be last resort, design questions might end up making myself the interviewee...what else then?
What approaches did you use?
How do those approaches compare or contrast to your own experience as a junior developer?
What do you see as the defining differences between junior developers and senior developers?
Is there an interesting technical subject you've recently encountered?
How often do you write code?
What makes a good programming language?
Tell me a debugging story.
[caveat, I might be old enough to be your parent]
Then, ask about his past experience working on career growth. Has he ever promoted anyone? What's his management style, hands-on/off? etc.
Honestly, algorithm questions are really out of the scope here (don't ask algo stuff... please :-)
In this case, I would poke them on a) relevant problems they worked on and how they went about solving them (dig as deep as you can), b) how they approach problem solving and coding in general (what excites them), c) how they made career decisions to date (what drives them), and why they're interested in the role you're hiring for (what's motivating them).
I wouldn't waste time with algorithm questions. A thoughtful and motivated developer will figure out and deliver much more than a algorithm guru.
Go for the design questions.
Let him show his design skills and show his ability to teach it to you. That's what you expect from a more experienced, isn't it?
I think the best thing to focus on is hiring a manager that knows a little bit about the processes you guys use day-to-day. If you're an agile team, ask about agile; a requirement document team, ask about documentation experience. Processes sort of follow some high-level patterns due to the large accreditation bodies that profit from selling their own flavors.
Have they managed QA or been involved with continuous integration and automated testing? What task-management systems have they used? Are they interested in promoting strong architecture, is production support a priority; or ask them to list out a set of priorities related to product delivery, production support, architecture, customer service, which helps with discovering any underlying philosophies more than really giving any direct information. Give an example of a time they resolved a conflict.
Asking about what the technology stack was for the team they managed is always good as well. If they can explain it coherently they weren't just doing performance reviews and checking time logs to make sure people were at their desks.
Just some ideas off the top of my head.
Asides from the basics, I'm more interested in an applicant's personality and how well they'd mesh with the existing team.
The particulars of skills can be trained. Personality pretty much cannot.
Some empathy-- He might be thinking this millennial is the same age as my kids. It can be rather intimidating having a young punk size you up for a job.
Get beyond that -- focus your questions on determining if the candidate could be a successful manager. Here's a list of questions to give you some ideas > http://www.bakertilly.com/uploads/interviewing-leadership-ca...
In the absence of other info I would let the more senior guys size him up in terms of technical skills, and instead focus on the more human aspects. At the end of the day what you want to know is "can I be happy working with this person?".
You didn't mention whether this person will be or is likely to become your future manager. If he will then the question becomes "would I like to report to this guy?".
I did ask my current manager about this decision and he did mention that he wants to find a engineering project manager (we have PMs) who could technically manage projects with him so he's not overloaded. This person might become my manager in the future but not immediately (maybe after 1 or 2 years when he's going to assemble his own team).
(And since the other interviewers will almost certainly overspend their interview minutes on technical quiz questions, you can help even things out by skipping them.)
The reason for this is that as a junior developer, you won't probably be able to technically challenge a candidate with many more years or experience.
Also make sure you ask for advise to other interviewers in your company, people is always happy to share the way the interview candidates and everyone has a different approach that we can learn from.
Ask how he handles people under him that he has a personality clash with. (If in doubt, make it clear that you aren't intending for that person to be you.)
Ask him about mentoring people younger/less experienced than himself.
