[hardware2win]

Git questions are weird for me

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

[grayhatter]

> so I dont really remember the commands nor see the value in putting effort into it

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.

[AnimalMuppet]

> > so I dont really remember the commands nor see the value in putting effort into 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.

[grayhatter]

You're right not starting with capital letters really detracted from my point and made it much harder for you to understand my meaning and intent. I'm sorry you had to endure that struggle.

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.

[cranberryturkey]

that's a fair point but i valud people who value the cli over guis. not that you can't use a gui but its much better to know what its doing under the hood.

[hardware2win]

>its much better to know what its doing under the hood.

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.

[cranberryturkey]

I also ask people to walk me through some recent code they write. So if you didn’t know the git answer no biggie

[BoiledCabbage]

I believe his point is you're part of the issue with interviewing as well. People design arbitrary trivia for people to answer and won't hire unless their workflow overlaps yours.

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.

[tharkun__]

Caveat not your parent.

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?

[grayhatter]

you answered the git question passibly IMO, so perhaps you could be 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?

[tharkun__]

If someone has never used git, they probably used <somethingElse>. I would hope they're witty enough to ask the interviewer back: "I dunno, never used git, we use Rational ClearCase. Can you tell me what the difference is between a reserved and unreserved checkout and when would you use each?"

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.

[gregors]

I also like to do this, and I think it's absolutely wonderful for having a conversation. I've never seen a downside to this and I've never had anyone who didn't have something they wanted to share.

[gregors]

I think it's a fair question. I would never not hire someone over not knowing that particular flow though.

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