7

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.

|improve this question

closed as primarily opinion-based by Ixrec, durron597, user40980, GlenH7♦, user22815 Jun 22 '15 at 3:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    If their response was "I've worked with github" ... why you didn't ask any further questions? I've been in interviews where the interviewer wanted to know more about a question and I've then gone into more detail. Nothing wrong with further questions. If they can't communicate then you've got more important issues than VCS exeprience. – James Khoury Sep 14 '11 at 1:20
  • +1 James. Ask open questions that can't be shut down and don't hire poor communicators. If I had been in that interview I would have immediately followed up with "and how did you find it?" or "what did you like / dislike about it?". As an interviewer it is your job to ask the right questions... – mcottle Sep 14 '11 at 2:55
  • @James Khoury I asked "Can you tell me about your experience with Git?" and the candidate responded "Yes, I've worked with GitHub" so I think I prompted a response that was a little more elaborate than that. I'm not a pro-interviewer, though :) – Nic Sep 14 '11 at 3:31
  • @melee That seems more like an issue with communication. I would be more worried that the candidate could not communicate well than their experience with VCS. But that's upto you. – James Khoury Sep 14 '11 at 3:42
  • A lot more persistence is recommended, e.g. "Tell me about git"... "I've worked with github" should lead to "Tell me more about the github project, how did you resolve code conflicts"... if the answer is "we didn't have any", ask "what order did you do you push, pull, commit's in". You need to ask more than 1 question to get real answers. – Michael Durrant Mar 21 '12 at 20:17
11

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.

|improve this answer
  • 2
    personally I wasn't even really aware of VCS coming out of college; certainly don't remember discussing it in class. That being said it shouldn't be hard for someone to pickup the basics fairly quickly although I have to say that I still mentor experienced developers with merges and branch management. – Ken Henderson Sep 14 '11 at 0:56
  • 1
    I agree with @Ken I hadn't used any VCS in university and barely knew it existed. My first job took me through the ropes and I picked it up a piece at a time. Isn't that how we all learn a piece at a time? – James Khoury Sep 14 '11 at 1:25
  • 3
    The thought of not learning about and using version control in university is not only foreign to me, but also down-right frightening. – Thomas Owens♦ Sep 14 '11 at 2:40
  • 1
    @Thomas Some of us unfortunately aren't in countries with great IT universities. I personally went to one of the less popular Uni's and taught myself (or learnt from professionals) more outside than I learnt in class. And now I think back on it ... it is frightening. – James Khoury Sep 14 '11 at 3:47
12

No they shouldn't be expected to know about it. Some companies (stupidly, in my opinion) don't use version control. They won't necessarily have been exposed to it.

If you're hiring an intelligent, logical developer then they should be able to pick up the concept with very little effort. If you do choose to hire them and are worried they will break something, make sure you point them to a decent tutorial and quiz them a little afterwards.

|improve this answer
  • 7
    I'm not entirely sure I agree with "version control is a tool not a concept". Yes, version control is implemented by a tool, but there are concepts such as branching, tagging, logging, and just general configuration management techniques that are realized by these tools. I think that they should have been exposed to at least a tool in the first programming course taken, and the concepts at some point as well. I was exposed to RCS (gah! the CS department switched to CVS a couple of years later) in my first year and SVN in my second year in my first software engineering course. – Thomas Owens♦ Sep 13 '11 at 23:00
  • 2
    IMHO Version control is both a concept and a tool. If you want to teach your new hires and they can't learn things in their probationary period then then one would assume they aren't a good hire. If you don't want to teach them well .... hmmm. – James Khoury Sep 14 '11 at 1:22
  • +1 for the first point. Not sure about the second point. – Andrew Grimm Sep 14 '11 at 6:12
  • In retrospect possibly it is partly a concept. Ill edit – Tom Squires Sep 14 '11 at 8:10
4

Well, I realize version control is probably relatively important to you, but I wouldn't consider it a big deal. If a programmer who has never heard of version control in his life (which would in itself be problematic, I admit, since they must have lived under a very remote rock for some time) can't pick up what he needs to know in a short time you have more serious problems. He won't be in charge of the company-wide source control policies, he just needs what you described as the simple stuff, and I don't see why a good programmer couldn't learn that in half a day.

|improve this answer
3

I agree with the sentiments that you shouldn't hang to heavily on how much your prospects really know git, but if you wanted to know more about what they know, you might just try to get them to talk about some of these topics:

  • "Have you ever merged anyones patches into your repository?"
  • "What are the different ways you've used tags in your development cycle?"
  • "When would you commit your changes to your local repository? When would you push them to origin?"
  • "Have you ever fixed a mistake by rewriting the history of a git repository? Have you ever been stung by it?"

I wouldn't spend much time on it, but it might still give you an idea of how the candidate works when combining his code with the rest of the team; which of course is really the key idea of DVCS.

|improve this answer
  • It allows to rewrite (unpushed) history before pushing to hide careless mistakes! – linquize Jun 5 '12 at 5:00
1

Agree with the others in that it is a tool not a concept. Consider your limited interview time with these individuals- spending several minutes of time on discussing DVCS may not be the most efficient use of scarce time. All the version-control packages are easy enough to pick up at the level an intern would be using them (they're not going to be administering your system, just using it).

|improve this answer
1

Whether someone has worked with a version control system or not is relatively uninteresting, unless you need someone right now to fix your broken version control yesterday.

Otherwise, what you are interested in is whether the candidate is capable of grasping the concepts involved in version control - and in fact, since the abstract concepts are similar to ones used in many programming problems, you want such a person anyway. Someone who understands pointers and recursion will be able to understand version control.

The basics of any version control system can be learned in less than an hour; more complex tasks may take a while to get used to, but not enough to worry about.

That said, if someone uses version control, that's a positive indicator for doing things the right way - but if they don't, it doesn't mean they're not a good fit.

|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.