Comment by PheonixPharts | Hacker News Reader

Comment by PheonixPharts | Hacker News Reader

Parent Full thread

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

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

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

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.

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

Reply on news.ycombinator.com