I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product. There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp.
EDIT: to add some context, i run a small startup, we need the whole team able to ship. I can imagine that in certain bureaucratic bigcorps, performatively obsessing on code/process quality can be useful, because the distance between the programmer and the customer/user is so long.
And you don't understand why developers might be interested in your source control setup and thinking behind dev processes?
If your response to a really common and sensible process question is
> I'm going to begin doubting that this person can focus on actually shipping product.
Then, if I'm interviewing with you, my assumption is going to be that your company way over prioritizes "just ship it!" with a total disregard for technical debt, and has a generally poor engineering culture.
Any engineer of any real talent is going to recognize that your dev environment and general software developement practice is in fact a big part of "shipping features" in the long term. The fact that you view this as some practice of "bureaucratic bigcorps" would tell me all I need to know to walk away slowly and politely.
So I would say this comment is inadvertently validating that this is in fact a very good question to ask during an interview.
I actually agree with you, though i think you missed the "series of questions like" and the "and why" part. My beef is with applicants who think engineering is entirely about process and quality and who forget about business value. Obviously you've been in touch with a lot of businesses where the balance is too far in the other direction which is its own kind of hellscape.
I recognize now that my comment makes us seem like such a place but actually we're very much not, I simply had not realized (until reading the replies here) that there were so many companies where even basic stuff like "using something like git" is considered overly fancy.
I do still believe that it's a common pitfall for good engineers to obsess too much about tooling and process and too little about customers and end users.
> i think you missed the "series of questions like" and the "and why"
No, I didn't miss these, those are the most important part of the interview.
Here's two example answers to demonstrate the importance of the "why":
"We use git because everyone else does" is the definition of cargo culting, good you use git but not great reasoning.
"We don't use git because it turns out 98% of our code changes are to XML, and we've found git for XML means even the simplest merge is a nightmare", code base sounds terrifying but that answer tells me engineers working there are thoughtful about their process.
The series of questions that logically follow very is natural stuff like "do you use CI/CD?", "how are PRs handled?", "what are code reviews like?" these are basic questions that give me as an engineer as sense of what the overall technical culture is like. And to your point, the more clearly the interviewer can answer these it means the less time it takes to get changes shipped to prod. Engineers asking these questions aren't bike shedding, they're making sure they are going to a good environment where they can focus on writing code and shipping features.
Frankly if conversations like this aren't part of your standard interviews then it doesn't sound like a very mature engineering culture. If you're uncomfortable with these conversations, that is an incredible red flag.
> "We use git because everyone else does" is the definition of cargo culting
I disagree with this, and Git isn't even my favorite source control system (Mercurial is). Using the same thing everyone else does has very clear benefits: new hires will already know how to use it, most CI/CD tooling out there expects it, StackOverflow will have more posts about it, you'll be able to fork libraries from GitHub and host them locally without having to migrate source control or use two systems, etc. etc. There are lots of reasons to use the same tools as everyone else besides cargo-culting.
They may use git, but that doesn't mean they use git correctly. You would have to ask a lot of questions to uncover this during an interview. I've personally witnessed a variety of bizarre workflows, individuals who don't know how to do merges, people who haven't learned how to cherry-pick, so they copy stuff manually. I could go on. It's not git specific. I saw similar troubles in the subversion days, and CVS days before that.
I found the list interesting from the perspective of an interviewer: we should have answers for all of these questions, but might selectively reveal them in job postings and across the interview process. We can be proactive about some things and circumspect about others.
That said, not everyone who says that they know git can rebase or do a 3-way diff if they get into trouble. There are a lot of git-is-Github in the pipeline right now.
FWIW, my flippant gut reaction was the same as parent’s, but really none of us needs to jump to logical extremes or put up straw men, the better thing to do than make assumptions about the other person is to have a conversation and ask about it, right?
To me the reasons that question should be asked carefully are that:
You’re interviewing to join a company that works a certain way and (unless it’s a startup) does so successfully enough to pay a salary. There are many valid ways to do source control, and a lot of people like to moralize their favorite one and make bad assumptions about how a company runs based on whether they use git or Perforce or Subversion.
The important question is just whether the company uses source control, and that’s what the Joel Test this question was borrowed from asks. Asking which one is fine, but requesting justification for it is the part that could come off as naive and/or condescending. That part of the question to me feels somehow a tad aggressive, and it feels focused on details that matter far less than whether the product ships or not.
Given a random interview at any size company, chances are high that the person you ask did not make the source control decision, and does not know why it was chosen. They might want to rationalize or justify something, but in any case, it’s probably not going to change, and it doesn’t really matter why it was chosen.
I would for sure want to know why a company was using svn or fossil for source control (just to take two examples)… there might be good reasons, but either one suggests that the company may not be making the right trade-offs.
(Nothing against fossil, it sounds lovely. But there needs to be a good reason to choose a niche product here.)
I happen agree with those two specific examples for specific reasons. I’m less sure about the suggestion that a niche tool needs to be justified. Why does there need to be a good reason? I’ve had jobs with in-house source control tools, and there were perfectly fine reasons for them at the time, and the companies were IMO making better trade offs than people choosing the thing everyone else was using.
When Joel wrote the Joel Test, git use was nowhere near as widespread as it is today. Doesn’t it predate GitHub? I mostly feel like the likelihood of this particular question being helpful in an interview is near zero, since nearly everyone’s on git for code anyway (or Perforce if there’s binary content.) I see comments here from people experiencing odd setups, but I’m pretty sure that is not the norm today.
If y'all aren't using git then I can end the interview quickly and save everyone some time. I will never get the 3 years of my life back that I got suckered into working with RTC.
I've worked places where the source control tool was email and WhatsApp. I taught them Git but they were "too busy" to adopt it. Part of the reason for the busyness was everything was always on fire.
As a junior, the Joel Test was a thing, and included source control. These days, it doesn't really matter though. It's easy enough to use Git, Github, and Github Desktop for everything.
"For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is."
Presumably the "source control" for the kernel was a disciplined system with competent people in charge of tracking versions, not wildly sending around "project_v2 final (1).zip".
It probably wouldn't have been as bad if the emails didn't run out of space every week or so.
WhatsApp is absolutely terrible for source control as you end up with people accidentally downloading an old version or not uploading a recent version.
Something like FTP or an external hard drive might have been a reasonable alternative. But today, might as well use Git.
Patches over email with a strict process (like one benevolent dictator approving each one) is much much better than random snippets of code (or I suspect vague descriptions of it) via whatsap message. Maybe I am adding too much to what OP said though.
True, and I agree. But at the same time, distributed development on the scale of the Linux kernel wasn’t that common in CVS’s time. CVS was adequate for it’s day. I’m glad we have git now, and I’m never going back to CVS, but at least it was source control and did it’s job just fine in lots of companies, right? My first real job was all CVS, and I don’t remember major problems. I feel like git didn’t reduce the number of issues as much as it enabled workflows we didn’t have before. All in all, I think I’ve watched more people lose data with git than with CVS, just because git is complicated so when things get messed up, some people nuke their repo rather than fix it, and because git stash is dangerous.
I always liked CVS better than Subversion. Merging was easier, and admin could manually fix the repo, if you broke it. I think OpenBSD is still using CVS.
Git is better for distributed development and pushing to upstream via layers of review/approval.
A few years back I worked for a large company that had, for various reasons, dependencies on software products produced by a lot of different suppliers. We wanted to do a "sanity check" on how good these companies were so we could identify where the risks were.
So I came up with a list of pretty basic questions - including what tools they used for source control.
During this process I encountered people who had somewhat eccentric views about source code control - including arguing pretty passionately against using it. I was somewhat taken aback by this....
So I think asking about how companies do source code control is pretty reasonable - 95% of the time they are probably sensible, but they might uncover somewhere where they have unusual views about how to do things.
Edit: I've encountered some people with really odd views about software development, such as one chap who believed that testing caused bugs...
I've encountered a company without version control in recent times. Interesting aside: they produced very high quality software, so it's not even a cut-and-dried thing on that front. Personally, I wouldn't get through the day without it but apparently there are people disciplined enough to manage. But I suspect they are quite rare.
Relying solely on developer discipline is a risky bet, there is always a chance the developer will forget something or external events will cause them to be distracted just long enough to skip an important part.
You can especially see it now with long COVID reducing mental capacities short or long term: processes that were designed to require only low mental load (thanks to automation and tools) didn't break and business continued to operate smoothly.
It is cut and dry. You need to be effective at collaborating with other people. I use git for everything even my own projects. How can you collaborate copying code around effectively?
All git really does is copy code around for you. ;) It’s certainly nice that it keeps track of the code it copies around, but I’m sure you’re aware that before git, Linus and everyone developing Linux collaborating extremely effectively by emailing code patches around.
I don’t know exactly what is cut and dry, but as I age it’s endearing to hear young people having trouble imagining effective collaboration before git. That says something very good about the tools we have now, and I hope they keep improving. But the days before git and even before CVS or email or internet weren’t quite the Stone Age some people imagine, there was plenty of effective collaboration, so maybe you can take that knowledge and do some research to answer your question. Knowing that effective collaboration is possible by copying code around, what then is truly important? We’re collaborating faster and on a larger scale now, it’s getting better, but it was exciting then (possibly more than today) and working well enough to get us to where we are now, right?
Well, version control wasn't always a thing and people got by just the same. So I can see how it could be done but the key is 'effectively' and the ability to quickly review and accord changes to a larger code base as well as to compare versions in a divide-and-conquer manner to see where a particular issue got introduced is priceless. So it would be a bit like trying to drive with the handbrake on, you can do it but it isn't an advantage.
Having Googled it, CVS came out in 1990, and there wer other pre cursor systems. So, pre-widespread internet and collaboration, yes, maybe people had some limited control systems that worked, but I don't think it even comes close.
CVS came out in 1986, and it is built on top of RCS, which dates to 1983.[0]
RCS was an alternative to SCCS, which was written for the IBM System/370 in 1972.[1][2]
All of these are very workable for software development by a co-located group of engineers. They are full-featured, not "limited". CVS is currently used by OpenBSD.[3]
And the car was invented in the early late 1800's and yet there are people who use bicycles.
The date when something is invented or comes into common usage does not automatically imply that everybody should use them. Though in the case of version control there are no good reasons not to use it that I'm aware of, even so, some people don't seem to require it to be able to be both productive and qualitatively at a very high level.
everyone has a copy. you email patches to someone whose job it is to review them and maintain the release version. they publish that to everyone else who uses it to replace their local version. repeat.
So they DO have source control. It's just 100% manual instead of (partially) automated.
I wonder what happens when the "source master" receives everybody's tarballs at the end of the work week? Manually inspect them all and manually merge the source files? Or, pick one at random and tell the engineers to merge on their own next week?
Gotcha. Yeah, it makes sense from their perspective to not use version control if they're journalling everything already. I can imagine the thought is what's the point of the extra process. I don't feel that way personally, but I see the point.
This question can be fine addressesd and be done with in 10 seconds.
If you cannot answer this positively quickly I'd doubt your ability to ship a product (long-term).
Especially the remark about "
obsessing on code/process quality can be useful" .. erm, asking about source control is not obsessing about code/process, it is the bare minimum and more to me like e.g. ask my future truck employer if their trucks have seatbelts.. tbh if I'd hear that from the guy that runs a small startup I'd run .. and that's good, people are different.
"we sometimes check things into sourcesafe but usually keep it on jims computer"
That was 3-4 years ago. From a company that was in no way a 'startup'.
That tells me they have no release system atall other than the late 80s crowd around a 'blessed' computer and hope it builds right.
"have you considered git, svn, perforce anything like that?"
"we don't have time for that"
That tells me they do not have time to invest in having a good reliable thing for themselves. It tells me that as a developer I will not have any time to fix recurring issues. It is a question you can learn a lot from. Because it is something the developers do day to day.
These are not new concepts. These are table stakes at this point. We were doing this sort of thing in the mid 90s. If you are not doing them. You are missing out on some cool debugging/regression/qa tools.
I would (and do, when interviewing candidates on the other side of the table) frame this differently. I can more or less assume that a candidate at the level we're hiring has used git, and done some form of code review, so I don't bother asking that particular question. What I do get into is their approach to code review, how they go about handling a pull request, how they'd provide feedback to the submitter, and what particular red flags they're looking for when reviewing code.
I indirectly also find out if a candidate hasn't used git, or done code review, but much more usefully I find out whether they're the sort of person who's going to take a quick glance and then throw a "lgtm" comment on the PR, or if they're actually going to review things.
Ah the cliche “I’m a hiring manager and I wouldn’t hire this person” comment.
I think you’ve not considered the reason behind the question and jumped to conclusions.
Eg if the say subversion and it’s a massively distributed team, the developer is not going to have a fun time. It isn’t a first class citizen when it comes to third party tools either. These are real issues.
While that's true, there are work arounds. Github does support Subversion. Having found myself on a team (in the past) that was tied to an outdated version control solution (source safe), you can still use Git locally to facilitate branches, rebasing and most everything else. Thankfully that's a rare occurrence these days.
I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product.
Asking a question like that in an interview is less about the answer and more about the ability to answer.
Any reasonably competent dev doing the interviewing will be able to rattle off an answer and a valid reason in a few seconds. It's really obvious. It requires no thought. There's no subtle complexity to be explained. If the interviewer can't answer, or they waffle on about complex stuff, then you can know that the company doesn't have the devs who are hands on with the code in the interview process which is a really big red flag.
Yeah I think you're just a little caught up in the phrasing (very blunt) and the mostly useless "and why" portion.
I've asked this plenty of times in interviews. But I usually wrap it in a general process question to see if devops and builds are a smooth process or a nightmare. Bad source control and devops means shipping features can be impossible.
Agree, ask them to make them qualify is fine but the why there feels pushing it. Also makes wonder on "why that why?" are you planning to be hired and revolutionize everybody's repo in the first week or you have to decide if you cannot adapt yourself to use git?
That's an odd one to cherry pick. There's nothing performative about source control. It's one of the most important tools for actually shipping software.
I can see the concern though. If you say something like "we invested in a large workflow involving Gitlab/Gerrit/anything else" and a potential applicant without any context expects you to go on the defense about why you aren't just using Github, I can see that person being hard to work with. I'm particularly noting the "and why" part here.
The problem isn't the question there though, the problem is an invented scenario that happens due to the response. The followup to that response could easily also be "Oh cool, how does that workflow work? Why did you go in that direction? What do you want to improve about it?"
> endless discussions and iterations about internal tooling
They just asked a simple question. It's a one-to-three-word answer. 'GitHub', 'Gitlab', 'BitBucket', 'Self-hosted CVS'. They wanted information, not to start a fight like you thought.
I said "a series of questions akin to", not "this single question". Please don't take my words out of context.
My comment isn't about source control. It's about warning applicants not to over-obsess about technical details when other stuff influences job happiness much more than git vs mercurial.
I think "what source control tool do you use" is fine, it's the "and why" where I start to think that you're asking the question to be combatative. I agree if you're expecting a couple word answer like Github etc, then perfectly good question to ask.
The why can be really important though. We do X because Google does it, or something like that is often a red flag because they have some insanely convoluted process that they don't need. knowing that things are selected that fit the size and scale of where a company is or will be soon is important.
I was going to say; I would ask this, as a lead up to CI/CD, and how they feel about developers shipping features continuously, or if there’s any process to actually ship what I’ve build.
I can understand 'and why' being tedious, and I've never had any questions come to mind to ask really, but it has occurred to me before that if I joined and then found out they didn't use git... I'm all for 'actually shipping product' but there's enough employers out there that such a fundamental unlikely to change tool is a reasonable deal-breaker.
The other thing I thought that about was Windows - using macOS would frustrate me daily but I'd (and have) get by, but Windows I would definitely regret not having checked what I'd be using/whether it was my choice before joining.
For a lot of candidates, "we don't really view source control as something we need to innovate on and prefer to ship features" is the right answer, and if that's your answer and the person is combative about it, well, that sounds like you just got a pretty clear signal about hiring that person, which is the whole point of interviewing anyway.
I'm not suggesting being 'combative about it', I just don't want to work somewhere that doesn't use SVC, I'd have to really want to work there for other reasons to learn subversion/mecurial/whatever (though maybe something newer than git, like pijul, would be interesting rather than annoying), isn't it in both our interests that I don't have a nasty surprise after joining?
Nor do I want to 'innovate on' on SVC, btw... If anything I'm saying the opposite aren't I? Git's what I know, and it's so fundamental/used so much throughout my day that it's a tool I wouldn't really want to be without. Hard to explain perhaps, considering I wouldn't have a problem with a new language (immediate turn-off when I get recruitment spam looking for a 'python/django engineer' or whatever - yes I have experience doing that but that's not how I'd categorise myself) but it makes sense to me.
I just mean, if it hadn't already come up/been mentioned, when they invariably asked 'any questions for us', I'd now (having thought about this before but not interviewed since) at least ask if they could tell me a bit about the hardware the provide and tools/processes they use. Just a question, nothing 'combative' about it.
Well, here's the thing. If I'm forced to use a clunky source control tool, the company ought to be able to tell me why (maybe there's a very good reason) and/or have other aspects I'll really like. So, yes, I might try to know this kind of things and understand the whys behind the choices, that'll also help me decide if the way choices are made seems reasonable to me, which is actually very important for both parties.
Of course on should only pick questions that really matters to them / which may trigger an interesting talk.
Having worked at places with no source control and visual source safe, I would ask what they use, but not why. Where the latest zip of the project is and if some random zip has a certain bug fix shouldn't be a regular question.
I would also ask about a artifact repository like Artifactory, because not having to worry about downloading random dependencies from the internet is nice. Having all your build artifacts in some centralized place is nice. Certainly not a deal breaker if it isn't there, just a nice to have.
Source control is a tool I interact with daily. I should be able to ask you about it. I personally don't care which tool you use unless your process around it causes friction for me. I don't want friction from doing source control. That's easily fixable and if the company isn't willing to fix it, I am not willing to waste my time there.
How am I supposed to ship if your SC is such a mess?
The reason is that it's such a basic question that not having an answer is a red flag.
For example: "we use Github for source control: it has good security, price is reasonable, comes with a bug tracker and a CI that are easy to use" is more than enough.
It's also more than OK to reply "I don't know, but I can find out if you think it's important", they're not performing a power play, they're merely looking for information in the same way they'd look for information from a computer.
It's also a way to know if it's a company culture where higher ups frown upon underlings asking pragmatic clarifying questions when assigned a task (another red flag because ego will hinder the productivity because developers will fear angering higher ups and will build the wrong thing, thus losing time and money you can't afford to waste in smaller companies).
There are many teams in big old companies which haven't transitioned to git or any modern source control. I remember hearing this for Oracle, not sure if it is still the case.
The part of Oracle I was in were using Git on BitBucket when I was there years ago. They were on GitHub for a time but decided they didn't like the PR functionality.
If you have trouble finding a job, sure. I use these questions to vet the employer, not the other way around. Mentality like "we have to ship right now" only works for so long and after a while no one is able to ship anymore and life is hell. I turn down offers from companies like that and let the juniors cut their teeth on that kind of company. And to be clear, I would work on a small startup over a large org 9 times out of 10.
> I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product.
I'll devil's advocate this.
In the .NET world, there are a number of toolsets that... are far from ideal. Either because I know the frameworks are restrictive, or there is a common pathology to see the tools in question abused to a point where forward progress is frequently impeded.
An example that comes to mind, 2015-2017 most .NET devs I know would ask questions around whether they were using Dapper, Raw ADO, or EF6, knowing they would be FAR more productive in the former environment than the latter.
As a lesser example, I know I'm -far- more productive in Github than Bitbucket for pull requests, BB honestly feels primitive and kinda broken in comparison. It's not a dealbreaker, but if I theoretically had two identical offers in front of me aside from that point... It would help me decide.
> There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp.
Agreed, There's also the 'blustering arguer' type; a specific type of dev that won't use the tools that are prescribed by an org, yet cannot finish assigned tasks using 'their toolset'. I've only run into a couple of these in my travels, at best they are marginally productive and at worst you are repairing both code and team morale after they go.
this comes across poor. it makes you sound more like The drummer on a Roman galleon, than someone leading other developers towards a goal. if a perspective developer adds value to your company and your product, but happens to care about things like source control, there may be really good reason why. if you dismiss that because of "we need to ship" then I'd propose that you might have tunnel vision and lack the EQ to value perspectives other than your own.
It's not the best comment i ever wrote, but I never said I'd dismiss devs caring about source control. I said that a series of questions like that suggest that the dev might care too much about stuff like that to the detriment of other stuff.
If you keep shipping and growing but don't make your internal tooling and processes better, you're going to grind to a halt. If you only make your internal tooling an processes better but not shipping, you're also going to grind to a halt. My argument is that you need a lot of the first and a bit of the, latter. An applicant who nearly only asks detailed technical questions about internal stuff, and makes me defend our decisions when we're not ticking off all the hypes du jour, suggests to me that we're not on the same page wrt where that balance should lie. Yes, we iterate on that stuff. No, not fulltime.
In fairness it wasn't a jab, but an objective observation. There were no personal attacks, merely suggestions based on observation. If we can suggest that an attentive list (where we've yet to define if a fictional candidate would expect all items to be addressed) means inherent expectations, it's reasonable to make the same kind of suggestions on your take.
I get where you’re coming from, but keep in mind we were talking about the candidate bringing an exhaustive list of such questions. In such a scenario it’s reasonable to suspect the candidate cares more about technical process than providing value for customers.
You're not getting a lot of agreement in your replies, but I've worked with people exactly like what you're saying. They could spout off some of the most impressive sounding concepts. When the rubber hit the road they produced absolutely nil. But I do think this particular question wouldn't be a good filter for that type of person.
It appears that skrebbel's source control is bunch of directories on dropbox. Version increment is made by copying the sources and renaming them to "project new new new", because "project new new" is already in use.
> There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp.
Sorry, but I think you're probably wrong as well. Do you actually sell features? As in: Is your revenue directly tied to the number of shipped features per year? If so, who pays for the perpetual maintenance? Did it ever occur to you that every feature is a liability? Security issues, bugs, incompatibilities and odd side-effects with other features, legal changes all add cost per feature.
If you're (like many in the industry) piling features on top of each other because you currently have no idea what your finished product should look like and you're hoping that your feature pile will someday somehow turn into a profitable product, I think you're wrong. And even if it does, you'd better exit shortly after because mid-term maintenance will be a proper nightmare.
> Do you actually sell features? As in: Is your revenue directly tied to the number of shipped features per year? If so, who pays for the perpetual maintenance?
I have worked for years in different places where the answer is yes, we sell features. This happens any time you are in a competitive deal where customers want software that does certain things and solicit bids from software providers. Your software does some things out of the box and you need to customize or extend it to do other features the customer wants that the system does not yet currently do. You demo what you have, describe how you would do the rest, and do a bid for total cost to the customer. Your competitors do the same. Maintenance can work different ways.
But yes, people pay money for features. And when properly managed, it is possible to make features add up to a product that provides value and earns money.
EDIT: to add some context, i run a small startup, we need the whole team able to ship. I can imagine that in certain bureaucratic bigcorps, performatively obsessing on code/process quality can be useful, because the distance between the programmer and the customer/user is so long.