8 ms·

> "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" Actual

> "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. After thinking about it for a minute or two, what I _think_ you're asking is "should all development happen on a common branch, or should developers create separate branches for individual features/fixes, merging back into the mainline when finished". And, indeed, I'd be happy to have a conversation with you about this. But if it takes me a couple of minutes to figure this out while just sitting here at home, in the pressure of an interview, I'm probably going to fumble, or say "I don't understand what you mean", which will make me wonder if I've blown the entire interview. This despite the fact that I've been programming for 20 years and have used a number of version control systems (CVS, ClearCase, P4, Subversion, and most recently Git).

StevePerkins 12y ago
In an actual interview, I would only pull out that specific example for a candidate who's worked with CVS and Subversion almost exclusively. The actual question is also a bit more verbose: Have you worked for a company that strives to do as much development as possible in 'trunk', creating a release branch near deployment time for production bugfixes? Have you worked for a company that preferred to branch at the outset of new development, merging back to 'trunk' periodically? What did you find to be the strengths and weaknesses of each approach? Their answer lets me read between the lines and gleen much more information about their work history. Have they worked in settings where multiple work streams were in development simultaneously? Do they have substantial experience in collaborating without trampling on shared resources? If so, then they usually mention the different pain points in merging. I don't consider there to be a "right" or "wrong" answer to this question, and not having a clever answer certainly doesn't disqualify someone from being a strong programmer. But it does help to level-set, and identify candidates who think like team leads or might be well suited for responsibly beyond raw coding. However, I don't want too much text between parentheses that are injected into a long sentence. So you get "trunk-first vs. branch-first". :)
- tptacek 12y ago
  Exactly why is it that you would making a screening decision based on version control practices? Of the many things you'll need to ramp candidates up on, this seems like one of the very easiest. Not only that, but because most firms do release management a little differently from each other, there's some VC ramp-up effort you'll need even with people who have mastered your VC tool. I feel like dev interviews are full of questions like this, things that require some expertise and experience to answer, but do virtually nothing to predict on-the-job performance. When you ask an interview question, you are pricing candidates. That's obvious when you think about it: you're screening, and so your questions alter the supply of candidates that will hit the bottom of your screening processes. Fewer selectees -> poorer employer BATNA -> higher prices. Do you really want to price candidates based on how they use version control tools? How much are you willing to pay extra for people who have a lot of experience with different VC methodologies? Are you sure the weight of your questions about VC match up with the (hopefully minimal) premium you're hoping to pay for VC expertise?
  - StevePerkins 12y ago
    I'm not sure that you fully read the parent comment. I could care less about their Subversion expertise. My company doesn't even use Subversion anywhere. However, if you list "10 years experience with <Technology X>" on your resume, then you should absolutely be prepared to discuss your experience with <Technology X> at a high level. Not anal minutia or contrived trick questions, but certainly you should be able to respond to an open-ended question about the basics with enough context to show that you weren't lying to pad your resume. More importantly, as I explained in the parent comment, I am interested to see if their response reflects experience with multiple teams working on parallel over overlapping efforts within the same codebase simultaneously. Everyone says that they have experience like that, but if you poke a bit deeper you find that half the time it's exaggerated. They may have worked in a context with multiple teams, but affecting the same area of the application or system. If you have had legit experience of this kind, or at least show a high level of insight in talking through the issues that can arise, then you might be considered for a team lead role sooner than you otherwise might have been. As I said earlier, it's not a "right or wrong" question that can disqualify you from being a capable programmer... it's a "level setting" question that helps gauge which level of responsibility you might start out with.
troels 12y ago
I got a bit baffled by that too, but came to the same conclusion as you did after a minute or two. In an actual interview, I suppose I would just start by clarifying what is meant by those terms before going on with a discussion about it?
simoncion 12y ago
> Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. I'm not trying to get in an ego stroking contest here, I'm just providing anecdata. I worked with SVN for ~4 years and git for ~4 more. What StevePerkins was asking was perfectly clear to me after about three seconds of thinking. Of course, in an interview, I would be sure to parrot back my understanding of the question. :) FWIW, you and I understood his question to mean the same thing.
- tonyarkles 12y ago
  I feel the same way, with approximately the same number of years of experience with each. And I definitely have strong opinions on the answer to the question :)
seanwilson 12y ago
I don't see the issue to be honest; it's an interview, not a written exam. You can think aloud, the interviewer can guide you if you're confused by the terminology and you can ask clarification questions.
phazmatis 12y ago
Unless a software developer is tasked with deciding which version control system to use or for some odd reason has to do a deep dive into the philosophy/design of subversion, why on earth would they bother to know this? You might as well ask if they prefer Cherry MX Blue or Brown. I don't know SVN but if it's anything like Git, there are 100 ways to use it, exactly 5 of which are useful to 90% of developers on any given day.
facepalm 12y ago
I think you could just ask for clarification. I suppose the whole point is to have a conversation. Of course this again biases against people who suck at interviewing (too nervous or whatever).
nitrogen 12y ago
A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. It's not a terminology question, it's a concept question. A good candidate should be able to recognize abstract concepts regardless of the words used to describe them. Even in an interview setting.
- tptacek 12y ago
  Why? What makes being able to persuasively discuss this particular concept an attribute of a good candidate? And, when you identify the answer to that question, can you then answer: is this question the best means I have of assessing that attribute?
  - nitrogen 12y ago
    I agree with you that this type of technical interview is a great way to fail to hire ideal candidates. I've experienced this myself. I was commenting only on the specific complaint about "terminology," and that one should be able to see through unfamiliar terminology in an interview, not that such an interview is the best way to hire excellent developers.

StevePerkins 12y ago

In an actual interview, I would only pull out that specific example for a candidate who's worked with CVS and Subversion almost exclusively. The actual question is also a bit more verbose: Have you worked for a company that strives to do as much development as possible in 'trunk', creating a release branch near deployment time for production bugfixes? Have you worked for a company that preferred to branch at the outset of new development, merging back to 'trunk' periodically? What did you find to be the strengths and weaknesses of each approach? Their answer lets me read between the lines and gleen much more information about their work history. Have they worked in settings where multiple work streams were in development simultaneously? Do they have substantial experience in collaborating without trampling on shared resources? If so, then they usually mention the different pain points in merging. I don't consider there to be a "right" or "wrong" answer to this question, and not having a clever answer certainly doesn't disqualify someone from being a strong programmer. But it does help to level-set, and identify candidates who think like team leads or might be well suited for responsibly beyond raw coding. However, I don't want too much text between parentheses that are injected into a long sentence. So you get "trunk-first vs. branch-first". :)

tptacek 12y ago
Exactly why is it that you would making a screening decision based on version control practices? Of the many things you'll need to ramp candidates up on, this seems like one of the very easiest. Not only that, but because most firms do release management a little differently from each other, there's some VC ramp-up effort you'll need even with people who have mastered your VC tool. I feel like dev interviews are full of questions like this, things that require some expertise and experience to answer, but do virtually nothing to predict on-the-job performance. When you ask an interview question, you are pricing candidates. That's obvious when you think about it: you're screening, and so your questions alter the supply of candidates that will hit the bottom of your screening processes. Fewer selectees -> poorer employer BATNA -> higher prices. Do you really want to price candidates based on how they use version control tools? How much are you willing to pay extra for people who have a lot of experience with different VC methodologies? Are you sure the weight of your questions about VC match up with the (hopefully minimal) premium you're hoping to pay for VC expertise?
- StevePerkins 12y ago
  I'm not sure that you fully read the parent comment. I could care less about their Subversion expertise. My company doesn't even use Subversion anywhere. However, if you list "10 years experience with <Technology X>" on your resume, then you should absolutely be prepared to discuss your experience with <Technology X> at a high level. Not anal minutia or contrived trick questions, but certainly you should be able to respond to an open-ended question about the basics with enough context to show that you weren't lying to pad your resume. More importantly, as I explained in the parent comment, I am interested to see if their response reflects experience with multiple teams working on parallel over overlapping efforts within the same codebase simultaneously. Everyone says that they have experience like that, but if you poke a bit deeper you find that half the time it's exaggerated. They may have worked in a context with multiple teams, but affecting the same area of the application or system. If you have had legit experience of this kind, or at least show a high level of insight in talking through the issues that can arise, then you might be considered for a team lead role sooner than you otherwise might have been. As I said earlier, it's not a "right or wrong" question that can disqualify you from being a capable programmer... it's a "level setting" question that helps gauge which level of responsibility you might start out with.

troels 12y ago

I got a bit baffled by that too, but came to the same conclusion as you did after a minute or two. In an actual interview, I suppose I would just start by clarifying what is meant by those terms before going on with a discussion about it?

simoncion 12y ago

> Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. I'm not trying to get in an ego stroking contest here, I'm just providing anecdata. I worked with SVN for ~4 years and git for ~4 more. What StevePerkins was asking was perfectly clear to me after about three seconds of thinking. Of course, in an interview, I would be sure to parrot back my understanding of the question. :) FWIW, you and I understood his question to mean the same thing.

tonyarkles 12y ago
I feel the same way, with approximately the same number of years of experience with each. And I definitely have strong opinions on the answer to the question :)

seanwilson 12y ago

I don't see the issue to be honest; it's an interview, not a written exam. You can think aloud, the interviewer can guide you if you're confused by the terminology and you can ask clarification questions.

phazmatis 12y ago

Unless a software developer is tasked with deciding which version control system to use or for some odd reason has to do a deep dive into the philosophy/design of subversion, why on earth would they bother to know this? You might as well ask if they prefer Cherry MX Blue or Brown. I don't know SVN but if it's anything like Git, there are 100 ways to use it, exactly 5 of which are useful to 90% of developers on any given day.

facepalm 12y ago

I think you could just ask for clarification. I suppose the whole point is to have a conversation. Of course this again biases against people who suck at interviewing (too nervous or whatever).

nitrogen 12y ago

A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. It's not a terminology question, it's a concept question. A good candidate should be able to recognize abstract concepts regardless of the words used to describe them. Even in an interview setting.

tptacek 12y ago
Why? What makes being able to persuasively discuss this particular concept an attribute of a good candidate? And, when you identify the answer to that question, can you then answer: is this question the best means I have of assessing that attribute?
- nitrogen 12y ago
  I agree with you that this type of technical interview is a great way to fail to hire ideal candidates. I've experienced this myself. I was commenting only on the specific complaint about "terminology," and that one should be able to see through unfamiliar terminology in an interview, not that such an interview is the best way to hire excellent developers.