Cuz, I use git gui and I switch to cli like a once a month at best, so I dont really remember the commands nor see the value in putting effort into it
It feels like people fixated on git details think everyone has the same work flow as they do, so for them it feels like git cli proficiency is really needed.
It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor)
Id really prefer being asked about algos, compilers, web dev, system design, whatever heavily software related (even religious topics like SOLID) than boring tools which can be used in various ways
I agree when it comes to programming langs, libs, compilers and in general computers. Because knowledge of those things significantly affects your output (code)
But git? I treat it the same way I treat email client, power point or chat app used at work.
Hell, I could probably benefit more from high power point skills than high git skills.
What's recent?
I have a busy life. I don't really code outside of work any more. I do woodworking or something else. The newest code you'll see from me is probably when I tried to make a game using Roblox just for fun for the kids. That's been a while. I don't have a github account and that's on purpose. I don't do open source work any longer and the most recent you'll find is probably 20 years old.
Code from work? Not gonna show that to you or you're not gonna hire me because I break NDAs ;)
Personally I do like the git one tho. Even if you use a GUI (unless it renames things it really shouldn't) would allow someone to answer what the conceptual differences are between pulling and rebasing!
FWIW: pull is a combination of fetch+merge, so not a rebase at all. They can be similar, in case your pull and rebase both happen to result in a simple fast-forward operation, which is literally just "moving a label" (or in 'real' terms, changing a commit hash inside one file in the .git directory).
Am I hired?
But what heuristic would you suggest for someone that doesn't know git at all, and doesn't ever write code for fun or to solve problems on their own?
Probably not in an interview situation, especially if they need the job, but would be fun!
Just coz I don't code for fun any longer, what tells you I don't solve problems on my own (both at work or at home)? Getting into woodworking required a lot of figuring out new stuff, including the part of actually doing something with my hands. It was particularly fun because it was new and needed figuring out. Figuring out why the heck the last distro upgrade decided to not be able to find my LVM volumes on software RAID and I thought I had lost all my data was also a fun problem to solve. It required zero code. But it required a lot of debugging and interpreting things I don't know the actual implemtation details of. Something I see a lot of devs being bad at. Fixing bugs. I.e. investigating unknowns.
No, because having "grown up" using git, I can't even imagine using something as insane as the model that ClearCase has decided to go with :D
> Probably not in an interview situation, especially if they need the job, but would be fun!
I'd hope you'd be able to, maybe not quite the way you asked it, but having a conversation where you can demonstrate expertise, even if it's not my expertise or favorite is the goal of the original question. (if asked by me)
> Just coz I don't code for fun any longer, what tells you I don't solve problems on my own (both at work or at home)?
Your answer obviously. Saying "I don't write code for fun" would instantly drop you into the do not hire category for me. But saying "I don't really write code in my spare time anymore like I did when I was younger, I can't really talk it too much detail about [work project], but I can discuss this personal project from years ago. But these days I'm using all my spare personal time getting good at wood working, that's now accounting for my debugging time"
Knowing a bit about wood working, I'd ask so many questions about that. Because for me, wanting to build things, and being interested in getting better at the stuff your building is the signal I'm looking for. Which, as you've hinted to is a big part of what woodworking is. Giving that answer, is also likely put you higher into the clear hire category for me, because it would show that you're able to get good at anything you want to.
No, because having "grown up" using git, I can't even imagine using something as insane as the model that ClearCase has decided to go with :D
having a conversation where you can demonstrate expertise, even if it's not my expertise or favorite is the goal of the original question
Also FWIW, the original commenter made it seem like he asks these questions in the way we've heard many interviewers ask them. You either know the exact answer, almost word for word, that they expect to their trivia question or you're out.
Saying "I don't write code for fun" would instantly drop you into the do not hire category for me
E.g. if you insist that coding for fun after work is the only correct answer, I know we'll not get along and even if I get hired after all, it won't be fun. You'll probably have/come up with your one way of how things have to be (done) but I have my own. I can't stand micro-management, I can't stand having to rush something because someone else screwed up and sat on something that was known for months and then they come to you and basically say "I need this, I need this done this way and I need it 'yesterday'", I can't stand being judged by just a bunch of numbers like "how many hours of coding do you get done outside of work" (interview) or "how many PRs per day do you merge" (work) by someone that literally knows nothing about me except these numbers.
If your hiring decision is based on what someone does outside of work, you are the problem.
For example, someone is hiring a chef for their restaurant:
Q: "What is the difference between X local priduce supplier and Y local produce supplier?"
A:"Where I work we had an exclusive relationship with X supplier so we never used Y supplier."
Q: "Hmm ok, tell me the last fancy meal you cooked at home."
A:"I spend all day cooking for my job. At home my spouse does the cooking because they really enjoy it."
Q:"Ok thanks no hire."
A:"In an executive chef with great credentials and experience. Do you want to ask me about and evaluate me on my actual job?"
Q:" No thanks. I want someone who has the exact same experiences as I do. And I once spent a long time evaluating suppliers and found a better one. And I'm single so do all the cooking at home."
And overall I don't mean to isolate you, but every time I see someone say they don't have extreme coding questions, they instead fall back to using the most non-representative arbitrary signals for decision making.
Also, I've never had any developers I've hired not be able to learn it quickly. The fact that they don't know it does tell you that they're either not rebasing or not using the cli. The discussion around those process topics are more interesting to me than them not knowing it to begin with. For example, "well what is your process around git usage in general?" etc, "how well do you know the cli?" etc. Interviews are all about conversations.
I would tell them they'll learn the cli git if they join my team. Maybe that's not something they're into? I guess that's part of the "fit" of a team.
At one point there was lots of discussion regarding rebasing in general on our team and another shop. This blog post came out of that. I know many people who feel differently of course. I do expect seniors to have an opinion on the matter either way I guess.
https://blog.carbonfive.com/always-squash-and-rebase-your-gi...
curiosity? knowing everything you can about the world around you? having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing?
> It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor)
My editor isn't vscode, so vscode shortcuts wouldn't be helpful to me, the interviever. But again, it's about ability to work with others, the demonstration that you understand systems that you could get away without knowing. You're right, you can be productive while understanding nothing about git, that doesn't mean you're good, or competent, just productive. I don't want to hire people who can write thousands of lines of code, I want to hire people who can do the same in just 100 lines.
> than boring tools which can be used in various ways
that's really what it comes down to isn't it. It's not interesting to you so you don't want to invest the time in learning it because it's boring. I doubt anyone would agree knowing fewer things is better, so I cant help but read this as sharpening my ax is boring, so I just don't do it.
> curiosity? knowing everything you can about the world around you?
There is far more out there to learn than I have time and energy to learn. "Here's something you can learn" does not even begin to reach the bar of "I should learn this".
> having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing?
With one exception, everywhere I have worked has not used git. The one exception used it for one or two years. I know more about four other version control systems than I do about git.
And, since you're talking about learning to use the most critical piece of software for working with other people, and chewing out the GP for not wanting to invest the time... why don't you begin your sentences with capital letters? Written English is one of the most critical pieces of, not software exactly, but at least "tech", for working with other people.
But I'll disagree that English is that important to working with others. I believe that you're confusing English, with being able to communicate ideas and intent.
> I don't really use it but from what I remember... also here's a lot of details about the steps that go into the porcelain command git pull.
I don't use VS code but I know the difference between the command palette and the sidebar file explorer and could answer a bunch of questions about it.
I think the point of the question is to filter out people who aren't curious. Which isn't perfect for the ability of a job candidate to be successful, but does happen to have an incredibly strong correlation.
I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff...
That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools
You're right, by the very nature of asking questions that I can think up, I am filtering for a shared knowledge set... But that's kinda the point. There needs to be some shared knowledge set. The person I want to hire needs to be able to talk about more than just data structures. And, unless you've invented one of your own, to me, that seems nothing but rote memorization?
How many data structures have you memorized? 1 a week for the past 2 years? and in those last two years, you never used git enough to figure out how to rewrite a commit, nor have an opinion about if you should or shouldn't?
> That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools
again, for the same reason above, I can look up documentation myself, I don't want to hire someone really good at reading documentation, I need someone who can think, and solve new novel problems... Another of my favorite questions to ask is "what's the first thing you'd do once you found out you were living in a zombie apocalypse?" Nothing to do about tech, but it's a great question to dig into how someone thinks, and if they're able to solve problems they weren't expecting. Just like any interview question worth asking, there's no one right answer. Sure it's great you've memorized every single data structure that exists, and the list of uses that are approved in some text book. But I can read too, that's not impressive, and not a sign of someone who I'd enjoy working with.
I want you to be curious about everything. I have no expectation that you'll know everything, but the desire to know everything in the order in which you choose is a critical quality of engineers that I'm able to respect.
> I analyze data, a tool user mainly, and thats where my curiosity is more focused perhaps, also what I am paid for ultimately.
Sure, but then why argue about curiosity of a tool you're not likely to encounter, but every single software engineer worth working with has? I don't know enough about data analysis to know what the corresponding tool would be. The closest I could come up with is excel, and I know enough to know that's definitely not it :D
Rebase is a very basic and common command available in a tool you use every day. That you both don't ever use it and don't know how it works might signal to the interviewer a lack of curiosity. They may think you tend to dismiss options without really considering them in favour of what is familiar.
Documentation is easy to read after you’ve read enough of it like any other technical writing. It only takes a moment to consult it and know the ground truth.
For example you mentioned that you know what git pull does. Are you aware that depending on the settings it is either doing a merge or a rebase? I also suspect that is the answer the OP was angling at.
That says a lot about you, not the people you are interviewing. Not everyone uses or trusts rebase workflows. I think --first-parent is a far better "basic and common command argument" and better makes use of the power of git's DAG. I have it in some of my default gitconfig files. Can you tell me without looking it up what is --first-parent and when and how you would use it? Some of the teams I've been on could. Others are happy with their (in my considered opinion, hideous) rebase or squash workflows. It's an aesthetic choice as much as a "right" choice to know one workflow over the others. [0] We all have our own workflows and most of us can learn new ones when we join a new team.
[0] Barring of course that rebase/squash hides merge conflict resolutions under the rug and trying to reverse engineer mistakes in them is a nightmare, and there's a deep dark rabbit hole from there into darker nightmares like rerere caches. I'm happy to claim that learning DAG traversal tools is not just aesthetically better but objectively safer, especially with junior developers around, but you don't have to take my word for it so let's call it just an "aesthetic choice" to stay on good terms.
As did SCCS, RCS, CVS, and SVN ...
Build systems and source control systems are shit work that are in the way of doing what I need to do. Basing interview questions on that is absurd.
If they had a good explanation for that gap in knowledge, like working for the past 20 years somewhere that was stuck in legacy code and running on SVN, I'd definitely take that into consideration. I might still want to be certain this candidate is smart enough to quickly pivot into a new codebase and new tools. I've met many people who struggle with exactly that kind of change which is exactly why they don't keep their knowledge current.
I'll admit that asking people how git works isn't a question I would ask in an interview. Playing devil's advocate though, I would probably not hire someone claiming to be a senior developer who doesn't know how git works.
I use Git only because other people force me to use Git. Otherwise, I use something better.
Also Git and Mercurial are about the same age and less than 20 years old. Perforce is far older than both of them.
A better approach is to ask a candidate something specific about their experience. Even if someone mentions “git expert” on their resume, the question is not what you proposed but instead asking about their experience and digging in from where they go. An engineer you’re interviewing may have fixed a bug in “git push” but not know anything about how “pull” or “rebase” works.