> Everyone should be able to sit down to a terminal, make a change to a repository, and commit it
Disagree - You're testing can someone use the basics of git in a terminal.
> you can always check the help or man page.
Assuming you know how to do that, and what you're looking at. Say I'm sat down in front of a terminal, and I'm told "here's a terminal, make a change and commit it"
I type in "git", and I get: "usage: git" - If you're used to using shell tools, then sure you can make sense of it, If you're not, then you're done.
You said "commit" and the description for that in the "git" command is:
> grow, mark and tweak your common history
> commit Record changes to the repository
Right, I don't know what that means, but lets try this `git commit`
> fatal: not a git repository (or any of the parent directories): .git
Ok, No idea here. I somehow figure out that git init will give me a .git folder. Now that I've got that out of the way, I try git commit , I get:
> nothing added to commit but untracked files present
Ok, how do I track files? "git help" doesn't mention tracking files. I'll try "git commit hello.txt", which gives me:
> error: pathspec 'Hello.txt' did not match any file(s) known to git
I give up at this point really.
(by the way, I got this far by doing this walkthrough this morning, and googling "how to use git" - which told me the answer in 3 seconds).
Not knowhing how to use a terminal vcs, or knowing the commands to perform even the basics doesn't mean you can't use version control, it just means you can't use a terminal for git. Is my 9 years of C++ and perforce experience because I didn't know that commit was analogous to submit, or because I've used a graphical interface for all that time?
> I type in "git", and I get: "usage: git" - If you're used to using shell tools, then sure you can make sense of it, If you're not, then you're done.
That's part of the test, to see if they're familiar with the command line and if they know how to open the man page. It's trying to weed out the people that can only work in the confines of an IDE and gui tools. That said I wouldn't expect anyone to know git from the man page, I would however expect anyone for a senior role to be familiar with what is a de-facto industry standard.
And source control in general is a great topic for interviews on both sides. Many devs (and companies) don't know what a branch is or what you'd use one for. Many companies make it hard/impossible to create feature branches, either by policy or crazy mono-repo stuff. Even their choice of SCM says a great deal about them, I'd avoid anyone that uses clear case or TFS.
> That's part of the test, to see if they're familiar with the command line and if they know how to open the man page.
That doesn't tell you anything about how good a programmer they are. I don't need to use a command line or man pages for 99.999% of my work, so I'm not going to waste time learning to use more tools.
> It's trying to weed out the people that can only work in the confines of an IDE and gui tools
Ah, so anyone who uses a terminal is superior to someone who uses an IDE or a GUI?
> I would however expect anyone for a senior role to be familiar with what is a de-facto industry standard.
In _your_ industry. As I've mentioned before, I use Perforce (which is standard in my industry).
> And source control in general is a great topic for interviews on both sides
Agreed, but asking somone to rattle off `git init git add . git commit -m"I can remember three lines"` doesn't tell you anything about how much they know about source control. Talk to them about branching/workflows to find out how much they know about source control, or let them use the tools they're comfortable with, but plonking someone in front of a terminal to rattle off some commands is the equivalent of looking for a "culture fit"
> That doesn't tell you anything about how good a programmer they are. I don't need to use a command line or man pages for 99.999% of my work, so I'm not going to waste time learning to use more tools.
I don't want to offend but you sound like exactly the type of developer I try to filter out. IME there is a large correlation between at least rudimentary command line proficiency and being a good developer. Aside from that I want someone to know about the world outside of the IDE and what options are available, because a unix like environment offers far more power than an IDE.
I expect developers should be able to automate common tasks, work with build tools, grep through logs, remote into servers, debug on servers without an IDE installed and a million other things that are very common.
Maybe this doesn't apply to your specific industry but it does to everyone I've worked in to varying degrees. Not memorizing git I could forgive if you could explain branching workflows, but living life in the IDE I wouldn't.
Disagree - You're testing can someone use the basics of git in a terminal.
> you can always check the help or man page.
Assuming you know how to do that, and what you're looking at. Say I'm sat down in front of a terminal, and I'm told "here's a terminal, make a change and commit it"
I type in "git", and I get: "usage: git" - If you're used to using shell tools, then sure you can make sense of it, If you're not, then you're done.
You said "commit" and the description for that in the "git" command is: > grow, mark and tweak your common history > commit Record changes to the repository
Right, I don't know what that means, but lets try this `git commit`
> fatal: not a git repository (or any of the parent directories): .git
Ok, No idea here. I somehow figure out that git init will give me a .git folder. Now that I've got that out of the way, I try git commit , I get:
> nothing added to commit but untracked files present
Ok, how do I track files? "git help" doesn't mention tracking files. I'll try "git commit hello.txt", which gives me:
> error: pathspec 'Hello.txt' did not match any file(s) known to git
I give up at this point really.
(by the way, I got this far by doing this walkthrough this morning, and googling "how to use git" - which told me the answer in 3 seconds).
Not knowhing how to use a terminal vcs, or knowing the commands to perform even the basics doesn't mean you can't use version control, it just means you can't use a terminal for git. Is my 9 years of C++ and perforce experience because I didn't know that commit was analogous to submit, or because I've used a graphical interface for all that time?