4 ms·

I would give them opportunities to show their skills at real-world tasks: - Version control. Given a terminal (or Explorer with TortoiseSomething) and an exist

by l0b0 8y ago

I would give them opportunities to show their skills at real-world tasks: - Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit. - Testing. Given a simple piece of code, its tests and either a bug report or feature request, explain at least in high level terms how to move forward. - Code review. Give constructive feedback on how to improve any aspect of a diff. These tasks indicate an understanding of code and facility with communication beyond the very basics, and you'll never finish learning them, so I believe they are appropriate for any non-entry level position. They are also sufficiently open ended that the candidate has to prioritize getting at least something done on all of them. After that, unless they are completely hopeless I'd arrange coffee or lunch (on company money of course) with at least part of the team they'd be working with, so they can tell if they are at all compatible. Needless to say, give the candidate plenty of options for a suitable time, let them know exactly how long it'll take, coordinate the time with the team, show up on time with a computer—which the admin team has wiped and you've just had to copy a few files onto—and find somewhere quiet and comfortable for them to work.

fsloth 8y ago
Is the candidate pool really so poor that you actually need to test that are they able to perform these basic tasks?
- stult 8y ago
  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.
- eccbits 8y ago
  Yes. It is awful out there from a hiring manager's perspective
maccard 8y ago
> 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.
- jgforbes 8y ago
  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.
  - hvidgaard 8y ago
    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.
  - maccard 8y ago
    > 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?
lkdjjdjjjdskjd 8y ago
Reminds me of this xkcd about tar https://www.xkcd.com/1168/ https://www.xkcd.com/1168/ Or even better, this one about git: https://xkcd.com/1597/ https://xkcd.com/1597/ It's good to use version control, but I wouldn't rate it too high in judging developer competence.

by l0b0 8y ago

fsloth 8y ago

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

stult 8y ago
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.
eccbits 8y ago
Yes. It is awful out there from a hiring manager's perspective

maccard 8y ago

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

jgforbes 8y ago
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.
- hvidgaard 8y ago
  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.
- maccard 8y ago
  > 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?

lkdjjdjjjdskjd 8y ago

Reminds me of this xkcd about tar https://www.xkcd.com/1168/ https://www.xkcd.com/1168/ Or even better, this one about git: https://xkcd.com/1597/ https://xkcd.com/1597/ It's good to use version control, but I wouldn't rate it too high in judging developer competence.