I've been interviewing some potential interns for a project I'm working on. We use git, so I'm looking for someone familiar with DVCS (or SVN/CVS or a desire to learn). A response that threw me off was I've worked with github with no further information, so it forced me to consider what to expect from a programmer working with version control.I actually led a VCS conversion, so I got more intimately involved with Git/DVCS administration than I thought I ever would be, so I don't think it is fair to hold a student to that standard. My question is, what should a junior programmer be comfortable doing when working with a DVCS? Should it be simple adds, commits, merges, remotes, or would you expect something more? If you've been asked good questions in interviews, I'd appreciate them being shared.I don't really want to hire the developer that pushes a backwards merge!Edit: I really should have mentioned before this got rolling that our distribution model relies heavily on Git and our self-hosted repository (I'm a web developer), and that's why  I feel it's important to know (at the very least) the consequences of serious actions like remote pushes; these actions triggers a few different processes in our environment. My fault! The answers have still been very helpful.
Interviews: How far to go on DVCS experience?
interview;git;dvcs
If you're looking for a junior developer, I've worked with github is probably plenty.Having graduated not that long ago, I think most students will not have run into situations where truly advanced uses of Git or SVN would have ever applied. I spent most of my college education as the sole committer to an SVN repository, it's just the nature of the projects you work on.I would focus on their programming and critical thinking skills. If a candidate has those, they can pick up Git in a couple days with someone to bounce questions off of. You could search for someone who knows Git, but it should be way down on the list of important things they should know.