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.
>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.
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.
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).
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.
> "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?"
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.
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.
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.
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.