When hiring for junior positions, we generally avoid making requirements for some specific knowledge (for example, although we are working in Ruby, we weren't expecting the candidate to know it), we are relying for other qualities, such as common IT knowledge, problem solving capabilities and "nerdiness".
So, the first part of interview is usually greatly improvised, talking about previous experience of the candidate: for example we talk about candidate's college projects, trying to find out how devoted he was and how deep he understands the technology beneath. We talk about the platform it was built on, with "real" questions thrown in; if he worked in Java, we talk about OOP, difference between interfaces and classes, trying to get opinions as well ("why did they added the concept of interface in Java") etc. Sole existence of an opinion on a subject is usually a good sign. Then, ask the candidate about some specific problem he had while doing the project, how did he handle it etc. You can learn a lot about the candidate by this kind of "techie smalltalk".
In the second part of the interview, we expect the candidate to solve some small problem from the field we are working in. We leave up to him to choose a tool (usually any mainstream scripting language, or bash or anything he's familiar with). Any simple programming task, parsing a simple CSV file and counting distinct fields in it, for example. We watch him working from time to time, offer help etc. In other words, trying to simulate real working conditions as much as possible.
So, sorry, this answer is not really a "recipe" you were asking for, but may be useful.