4 ms·
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
by 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 agoI 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 agoThey 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.