[jgforbes]

I also balked at it, but for the opposite reason. Everyone should be able to sit down to a terminal, make a change to a repository, and commit it.

I mean even if you don't know the command (or they are using a different version control system then you are used to) you can always check the help or man page. It's still a trivial task.

[maccard]

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

[flukus]

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

[maccard]

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

[flukus]

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

[oogali]

I've encountered people who didn't know the concept of a man page exists, or that -h / -? / --help is a semi-standard construct.

Yet they carried mid/senior-level titles.

You should absolutely test for the things that you think are annoyingly trivial if this person is to be a close peer or a direct report, because your level of disappointment will be so much greater after that person becomes an employee.

I define "annoyingly trivial" as the things that you feel everyone should know "at this stage", and you would be annoyed at having a conversation about said topic for more than 5 minutes.

My personal opinion is Git definitely falls into that category.

[maccard]

> I've encountered people who didn't know the concept of a man page exists, or that -h / -? / --help is a semi-standard construct.

I can count on one hand the number of times I've relied on man pages for descriptions. Using git as the example, compare https://man.cx/git-commit(1) to https://www.atlassian.com/git/tutorials/saving-changes for someone who has never used version control. One of them talks about saving, with examples. The other talks about storing an index in a log.

> My personal opinion is Git definitely falls into that category.

There are plenty of developers with working knowledges of branching/merging workflows, version control, using visual tools, or non-git tools.

[hvidgaard]

The intricate of GIT commands are not obvious in the man page. I'd be more interested in a talk about how often to commit, branch, merge, review, ect. If you got that right, the VSC is just a tool you learn if you don't know it.