5 ms·

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

• 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.
  • PheonixPharts 4y ago
    > 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.
    • feoren 4y ago
      > "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.
    • icedchai 4y ago
      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.
• dahart 4y ago
  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.
  • deleted 4y ago
    [deleted]
  • flerchin 4y ago
    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.
  • grayclhn 4y ago
    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.)
    • dahart 4y ago