11 ms·

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 doubtin

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.

switch007 4y ago
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.
- gregors 4y ago
  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. https://docs.github.com/en/get-started/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients https://docs.github.com/en/get-started/importing-your-projec...
  - supportlocal4h 4y ago
    I am ok with candidates asking questions. And I am ok with managers filtering out people who ask questions. From both perspectives, mission accomplished.
Trasmatta 4y ago
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.
- woutr_be 4y ago
  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.
- technion 4y ago
  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.
  - ryanbrunner 4y ago
    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?"
- skrebbel 4y ago
  The performative part is engaging in endless discussions and iterations about internal tooling
  - chrisseaton 4y ago
    > 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.
wrycoder 4y ago
It’s an easy question that could elicit an interesting response. For example, they could be using an internal CVS repo. Or, they could be using GitHub.
muzani 4y ago
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.
- rmnclmnt 4y ago
  WhatsApp for versioning, first time I hear, that’s a new one! (After all why not, there is even e2ee built-in!)
- kleiba 4y ago
  "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." Linus Torvalds
  - yccs27 4y ago
    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".
  - sidlls 4y ago
    Linus isn't right about everything.
    - dsr_ 4y ago
      Then he wrote git.
    - switchbak 4y ago
      If you haven't used CVS, his comment would sound crazy. They did use BitKeeper as well for a time, it's just that CSV/SVN weren't up to the task, so they did the best they could at the time.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
raverbashing 4y ago
Oh no that's a very useful answer It tell you how up with the times (or not) their company is ClearCase has been a very good indicator the place is a dumpster fire
bart_spoon 4y ago
It’s not a bad question. There are still enough companies not using source control that the question is necessary.
jraph 4y ago
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.
arethuza 4y ago
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...
- jacquesm 4y ago
  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.
  - plugin-baby 4y ago
    Where was the code?
    - jacquesm 4y ago
      Embedded device. Or do you mean storage? Tar files... going to back a decade+.
      - xorcist 4y ago
        Well, that is version control, isn't it? Add some basic tooling about that collection of tar balls and you're half way on re-implementing git.
      - 4y ago
YetAnotherNick 4y ago
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.
- chrisseaton 4y ago
  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.
  - XorNot 4y ago
    Did they say why? I'm struggling to think of any difference?
    - chrisseaton 4y ago
      Maybe it was some Atlassian plug-in to the PR system?
  - YetAnotherNick 4y ago
    Is it consistent for all teams?
    - chrisseaton 4y ago
      I think different teams do what works for them - Oracle is pretty heterogeneous.
- jghn 4y ago
  Every time my team is hiring I am always amazed at how many developers have no, or almost no, git experience. People on HN assume some of these things as givens but it's not the case.
  - lakomen 4y ago
JustSomeNobody 4y ago
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?
choeger 4y ago
> 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.
- skrebbel 4y ago
  You're making a whole lot of assumptions there buddy.
- unoti 4y ago
  > 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.
calvinmorrison 4y ago
That is until you start a new job where they use subversion but people really just copy code around and once in a while a new version gets tagged.
OJFord 4y ago
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.
- ryanbrunner 4y ago
  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.
  - OJFord 4y ago
    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.
andrew_ 4y ago
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.
- skrebbel 4y ago
  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. PS. I feel the jab about my EQ was unnecessary.
  - andrew_ 4y ago
    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. Appreciate your clarifications none the less.
- unoti 4y ago
  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.
throw827474737 4y ago
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.
- sumtechguy 4y ago
  "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 at all 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.
- jon-wood 4y ago
  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.
onion2k 4y ago
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.
- skrebbel 4y ago
  Nice one Can drop the "and why" for that though.
  - sebastianconcpt 4y ago
    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?
  - llbeansandrice 4y ago
    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.
cerved 4y ago
version control is key to my productivity. If you don't do that well or don't understand it, we're not a good fit
michaelt 4y ago
> There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features Did you consider that a candidate who asks about "pair programming" or "SOC2 compliance" or "SLAs" might be asking that so she can avoid such jobs? Of course, the list is far too long.
- guhidalg 4y ago
  As a junior, I wouldn’t have understood this comment. 6 years later, I value my time and mental health more than compliance.
to11mtm 4y ago
> 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.
NullPrefix 4y ago
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.
PheonixPharts 4y ago
> to add some context, i run a small startup 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.
- skrebbel 4y ago
  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.
  - politician 4y ago
    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.
whoomp12342 4y ago
uhh if you use visual source safe, I am out. I will tolerate git and SVN and thats about it.
jfabre 4y ago
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.
wildpeaks 4y ago
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).
yCombLinks 4y ago
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.
stonemetal12 4y ago
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.
ChiperSoft 4y ago
Author of the list here, the list is 9 years old. That question was a lot more relevant in 2011.

switch007 4y ago

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.

gregors 4y ago
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. https://docs.github.com/en/get-started/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients https://docs.github.com/en/get-started/importing-your-projec...
- supportlocal4h 4y ago
  I am ok with candidates asking questions. And I am ok with managers filtering out people who ask questions. From both perspectives, mission accomplished.

Trasmatta 4y ago

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.

woutr_be 4y ago
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.
technion 4y ago
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.
- ryanbrunner 4y ago
  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?"
skrebbel 4y ago
The performative part is engaging in endless discussions and iterations about internal tooling
- chrisseaton 4y ago
  > 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.

wrycoder 4y ago

It’s an easy question that could elicit an interesting response. For example, they could be using an internal CVS repo. Or, they could be using GitHub.

muzani 4y ago

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.

rmnclmnt 4y ago
WhatsApp for versioning, first time I hear, that’s a new one! (After all why not, there is even e2ee built-in!)
kleiba 4y ago
"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." Linus Torvalds
- yccs27 4y ago
  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".
- sidlls 4y ago
  Linus isn't right about everything.
  - dsr_ 4y ago
    Then he wrote git.
  - switchbak 4y ago
    If you haven't used CVS, his comment would sound crazy. They did use BitKeeper as well for a time, it's just that CSV/SVN weren't up to the task, so they did the best they could at the time.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

raverbashing 4y ago

Oh no that's a very useful answer It tell you how up with the times (or not) their company is ClearCase has been a very good indicator the place is a dumpster fire

bart_spoon 4y ago

It’s not a bad question. There are still enough companies not using source control that the question is necessary.

jraph 4y ago

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.

arethuza 4y ago

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...

jacquesm 4y ago
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.
- plugin-baby 4y ago
  Where was the code?
  - jacquesm 4y ago
    Embedded device. Or do you mean storage? Tar files... going to back a decade+.
    - xorcist 4y ago
      Well, that is version control, isn't it? Add some basic tooling about that collection of tar balls and you're half way on re-implementing git.
    - 4y ago

YetAnotherNick 4y ago

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.

chrisseaton 4y ago
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.
- XorNot 4y ago
  Did they say why? I'm struggling to think of any difference?
  - chrisseaton 4y ago
    Maybe it was some Atlassian plug-in to the PR system?
- YetAnotherNick 4y ago
  Is it consistent for all teams?
  - chrisseaton 4y ago
    I think different teams do what works for them - Oracle is pretty heterogeneous.
jghn 4y ago
Every time my team is hiring I am always amazed at how many developers have no, or almost no, git experience. People on HN assume some of these things as givens but it's not the case.
- lakomen 4y ago

JustSomeNobody 4y ago

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?

choeger 4y ago

> 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.

skrebbel 4y ago
You're making a whole lot of assumptions there buddy.
unoti 4y ago
> 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.

calvinmorrison 4y ago

That is until you start a new job where they use subversion but people really just copy code around and once in a while a new version gets tagged.

OJFord 4y ago

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.

ryanbrunner 4y ago
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.
- OJFord 4y ago
  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.

andrew_ 4y ago

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.

skrebbel 4y ago
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. PS. I feel the jab about my EQ was unnecessary.
- andrew_ 4y ago
  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. Appreciate your clarifications none the less.
unoti 4y ago
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.

throw827474737 4y ago

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.

sumtechguy 4y ago
"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 at all 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.
jon-wood 4y ago
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.

onion2k 4y ago

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.

skrebbel 4y ago
Nice one Can drop the "and why" for that though.
- sebastianconcpt 4y ago
  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?
- llbeansandrice 4y ago
  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.

cerved 4y ago

version control is key to my productivity. If you don't do that well or don't understand it, we're not a good fit

michaelt 4y ago

> There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features Did you consider that a candidate who asks about "pair programming" or "SOC2 compliance" or "SLAs" might be asking that so she can avoid such jobs? Of course, the list is far too long.

guhidalg 4y ago
As a junior, I wouldn’t have understood this comment. 6 years later, I value my time and mental health more than compliance.

to11mtm 4y ago

> 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.

NullPrefix 4y ago

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.

PheonixPharts 4y ago

> to add some context, i run a small startup 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.

skrebbel 4y ago
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.
- politician 4y ago
  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.

whoomp12342 4y ago

uhh if you use visual source safe, I am out. I will tolerate git and SVN and thats about it.

jfabre 4y ago

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.

wildpeaks 4y ago

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).

yCombLinks 4y ago

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.

stonemetal12 4y ago

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.

ChiperSoft 4y ago

Author of the list here, the list is 9 years old. That question was a lot more relevant in 2011.