Hacker News Reader

> Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit.

Does this really tell you anything about a candidate? If you sat me down in front of a terminal and said "here's a git shell, make a change and commit it" I'd fail the test immediately. I've used perforce for the last 9 years, and the terms are not the same, and the commands are _not_ discoverable. So you're eliminating anyone who doesn't know git basics (which can be taught in 5 minutes, or with a GUI of their choice), or you're giving a test for some criteria that you won't judge people on, so it's a waste of time.

> - Code review. Give constructive feedback on how to improve any aspect of a diff.

I like this idea actually. Have the person I'm interviewing review a piece of code (maybe a diff? I'm not sure about different diff formats, maybe it just needs to be some text files, or maybe they just have full internet access and the ability to download their own tools), and judge based on that.

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.

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.

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

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.

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

I specified "TortoiseSomething" rather than "TortoiseGit" because I specifically did not expect the developer to be familiar with all VCSes. This needs to be agreed upon in advance - it shouldn't be hard to create an environment for whichever VCS the candidate is familiar with.

Reminds me of this xkcd about tar https://www.xkcd.com/1168/

Or even better, this one about git: https://xkcd.com/1597/

It's good to use version control, but I wouldn't rate it too high in judging developer competence.

Is the candidate pool really so poor that you actually need to test that are they able to perform these basic tasks?

Yes. It really is. A couple weeks ago I interviewed a self-described C# expert who claimed to know everything about C# but couldn't even begin to describe the difference between methods and fields and properties, and did not seem aware that methods have return types. I'm not sure he had ever written a line of real code in C#, or any other language for that matter. This was a recent CS grad from a reasonable quality engineering school, so I'm not sure how he even got through college.

And for the record, I try to interview people on their strengths, giving them the opportunity to show off what they know about the area where their greatest interest or experience lies. A shocking percentage of people (>50%) nevertheless fail to demonstrate even basic knowledge of syntax or language features in the language of their own choice. This is without even considering actual workplace skills like git, PR review, tickets, etc. as discussed above.

Yes. It is awful out there from a hiring manager's perspective