6 ms·
I often ask the difference between a merge and a rebase is in my interview questions. It is exceptional common that they cannot even describe it. I typically u
by Topgamer7 3y ago
I often ask the difference between a merge and a rebase is in my interview questions. It is exceptional common that they cannot even describe it.
I typically use it as a barometer for how in depth the candidate tries to understand underlying mechanisms of tools they use.
- rcme 3y agoThis is the type of interview question I hate. You’re basically selecting for candidates who care about the same problems you do.
- heyoni 3y agoExactly. Dig into what they know!
- rizzaxc 3y agoif the interviewee would be a direct report of the interviewer, I dont see the issue
- rcme 3y agoNot an issue per se, but there are plenty of candidates who might not care about merging vs. rebasing but have an interest in other things. So many interviews consist of interviewers hoping you parrot their own worldview back to them. It’s not a good way to build a team.
- tasuki 3y agoI prefer rebasing (for the usual reasons). I have successfully worked with people who prefer merging (for the usual reasons). I don't think I'd work successfully with people who don't care.
- rcme 3y agoI don’t care. Why? Because it’s largely a meaningless distinction that has nothing to do with the goal at hand. It’s like eMacs vs. vim or tabs vs. spaces. Another way of thinking about interviewing is this: you say you don’t want to work with people who don’t care about this problem you care about. That’s fine, I guess. But if you changed your viewpoint to “I want to work with candidates who care about interesting things” then you might find you ask more about what they care about and less about what you care about.
- evandale 3y agoI'm with you. I don't care. I prefer merging but if someone insists on rebase + squash commit I don't care because it doesn't make a difference. Sometimes I'll tell a rebase person that if they don't like merge commits they can use git log --no-merges and you won't see merges. The majority of people I come across who prefer rebase for "clean history" reasons don't know this. If you truly understand the difference between rebase and merge you'll come to the conclusion that it doesn't matter what you use.
- yxhuvud 3y agoYes, if I want to find someone to work with I certainly want someone that do care about not making a total mess in the VC history. Selecting for that seems like a very good thing, regardless of whatever else they contribute.
- pydry 3y agoIt's also exceptionally common that the difference doesn't matter in the slightest. I'd file this question under "trivia the interviewer believes correlates with performance".
- OkayPhysicist 3y agoIt's "trivia that would be difficult to avoid picking up as a professional software developer". Like, asking what a for loop does wouldn't give you any real positive signal, but if they can't answer it's a strong negative signal.
- pydry 3y agoIt's super easy to avoid. You dont have to learn git's internal model to use it and it barely matters whether you use merge commits or rebase in 99% of code bases anyway. You might as well judge people on how well they know xkcd comics or VIM keystrokes.