5 ms·

Thats so strange to me. I work with git every day and don’t use rebase. If you asked me in the interview I’d fail that. But if you asked me that question in rea

Thats so strange to me. I work with git every day and don’t use rebase. If you asked me in the interview I’d fail that. But if you asked me that question in real life I’d give you the answer in 30 seconds after looking at the documentation, and everything would carry on without a hitch.

grayhatter 3y ago
you don't even know what it does enough to say, > 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.
- mech422 3y ago
  >>I think the point of the question is to filter out people who aren't curious. 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
  - grayhatter 3y ago
    > 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... 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.
- kjkjadksj 3y ago
  Do you want me to be curious about git or what we are actually doing on the job though? Maybe its different for software engineers where the job is to build tools over use tools. I analyze data, a tool user mainly, and thats where my curiosity is more focused perhaps, also what I am paid for ultimately.
  - grayhatter 3y ago
    > Do you want me to be curious about git or what we are actually doing on the job though? 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
gambiting 3y ago
I'm a technical lead on a project that uses git and frankly I have no idea off the top of my head. And yeah same I could just look it up if I needed to.
lucisferre 3y ago
I get what you are saying about this being easily available information. However, an interviewer might still view this simple test as demonstrating a character flaw. 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.
- kjkjadksj 3y ago
  I work with too many tools to sit there and memorize the implementation of each of their functions should I be questioned. Either way, its a wasted effort memorizing that considering its all documented should I need to use it. I’ve probably read what was written on rebase at least once by now but I don’t work in shared repos and keep things pretty organized so I don’t need to use it. 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.
  - lucisferre 3y ago
    No one said anything about the implementation of the function. Not understanding what rebase is and does would imply not understanding how git actually works. 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.
    - kjkjadksj 3y ago
      To me we are getting a bit away from the point and going into semantics. My point is and was that being tested on easily reference-able knowledge you are able to look up on the job to no penalty is a waste of everyone’s time, in contrast to the gp who stated failing such test in hiring would lead to perhaps not getting the job on account of it.
- WorldMaker 3y ago
rayiner 3y ago
But shouldn’t you use rebase? E.g. if you’re developing a new feature on a central repository, and a bunch of commits happen to the repository in the meantime, wouldn’t it be best practice to do a rebase before you push your own commits to the repository?
- Manuel_D 3y ago
  If there's no merge conflicts, then the end result is the same whether or not a rebase is done before merging. If there's unit tests involved, though, then CI should perform a rebase before running the test suite though.
- tayo42 3y ago
  Yeah, idk how you can work on a slightly busy code base without rebasing? Maybe it is a good filter question
  - rendang 3y ago
    As a git newbie I just do git pull. Is the problem that the merge makes the commit history harder to reason through in the future vs if you rebase?
    - kjkjadksj 3y ago
      If you aren’t working with multiple people or making a mess of your repo then git pull is fine.
    - tayo42 3y ago
      Its probably more complex then I'm ready to explain in a comment section. But its useful when you are working on your own branch (IDK why you wouldn't be?) and need to integrate recent merges from the master branch on to your own branch.
    - rayiner 3y ago
      Yes. Say you git clone a repository, and over the course of some months add a new feature. If you do a rebase then push, then it will appear in the history as if you had done a clone of the most recent version of the repository, done all your commits, and then pushed your changes to the main repository. Otherwise, the history will have merge commits in it where your commits to your local repository are merged with commits that were pushed to the public repository after you cloned your local repository.

grayhatter 3y ago

you don't even know what it does enough to say, > 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.

mech422 3y ago
>>I think the point of the question is to filter out people who aren't curious. 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
- grayhatter 3y ago
  > 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... 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.
kjkjadksj 3y ago
Do you want me to be curious about git or what we are actually doing on the job though? Maybe its different for software engineers where the job is to build tools over use tools. I analyze data, a tool user mainly, and thats where my curiosity is more focused perhaps, also what I am paid for ultimately.
- grayhatter 3y ago
  > Do you want me to be curious about git or what we are actually doing on the job though? 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

gambiting 3y ago

I'm a technical lead on a project that uses git and frankly I have no idea off the top of my head. And yeah same I could just look it up if I needed to.

lucisferre 3y ago

I get what you are saying about this being easily available information. However, an interviewer might still view this simple test as demonstrating a character flaw. 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.

kjkjadksj 3y ago
I work with too many tools to sit there and memorize the implementation of each of their functions should I be questioned. Either way, its a wasted effort memorizing that considering its all documented should I need to use it. I’ve probably read what was written on rebase at least once by now but I don’t work in shared repos and keep things pretty organized so I don’t need to use it. 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.
- lucisferre 3y ago
  No one said anything about the implementation of the function. Not understanding what rebase is and does would imply not understanding how git actually works. 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.
  - kjkjadksj 3y ago
    To me we are getting a bit away from the point and going into semantics. My point is and was that being tested on easily reference-able knowledge you are able to look up on the job to no penalty is a waste of everyone’s time, in contrast to the gp who stated failing such test in hiring would lead to perhaps not getting the job on account of it.
WorldMaker 3y ago

rayiner 3y ago

But shouldn’t you use rebase? E.g. if you’re developing a new feature on a central repository, and a bunch of commits happen to the repository in the meantime, wouldn’t it be best practice to do a rebase before you push your own commits to the repository?

Manuel_D 3y ago
If there's no merge conflicts, then the end result is the same whether or not a rebase is done before merging. If there's unit tests involved, though, then CI should perform a rebase before running the test suite though.
tayo42 3y ago
Yeah, idk how you can work on a slightly busy code base without rebasing? Maybe it is a good filter question
- rendang 3y ago
  As a git newbie I just do git pull. Is the problem that the merge makes the commit history harder to reason through in the future vs if you rebase?
  - kjkjadksj 3y ago
    If you aren’t working with multiple people or making a mess of your repo then git pull is fine.
  - tayo42 3y ago
    Its probably more complex then I'm ready to explain in a comment section. But its useful when you are working on your own branch (IDK why you wouldn't be?) and need to integrate recent merges from the master branch on to your own branch.
  - rayiner 3y ago
    Yes. Say you git clone a repository, and over the course of some months add a new feature. If you do a rebase then push, then it will appear in the history as if you had done a clone of the most recent version of the repository, done all your commits, and then pushed your changes to the main repository. Otherwise, the history will have merge commits in it where your commits to your local repository are merged with commits that were pushed to the public repository after you cloned your local repository.