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

[grayhatter]

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

[buttercraft]

> Saying "I don't write code for fun" would instantly drop you into the do not hire category for me.

If your hiring decision is based on what someone does outside of work, you are the problem.

[grayhatter]

You don't understand the rational behind that. If you'd kept reading, you'd have learned that talking about woodworking would easily put you into the hire category.

[tharkun__]

    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

Let's reverse things: If I was interviewing you and you gave me that answer when I asked about ClearCase, that would squarely put you in the no-hire bucket ;) "Young guy that just refuses to even try to think for himself, instead of making some guesses based on non-perfect information and assumptions, which he will clearly label as such." That's a really big one I look for. Labelling assumptions.

    having a conversation where you can demonstrate expertise, even if it's not my expertise or favorite is the goal of the original question

Ah, so then, without Googling :D, what's the answer to the ClearCase question? And yes I'd love to have a conversation (in an interview situation) about what's good and bad about how ClearCase does it after I tell you vs. what git does.

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

If I really needed the job I'd probably try to be less 'feisty' in my answer but if I was just casually looking and you asked me that question, the paragraph about woodworking and the almost data loss might have been exactly what I would say as a "reverse interview question" so to speak, to see if you are stuck on your one exact way of thinking or if you can appreciate that everyone's situation is not the exact same and you adjust.

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.