>I would have no time at all to do anything if I start looking at all my candidates' github links.
How do you decide to get the candidate in the pipeline? Presumably you're reading a CV and a letter, then having a phone call, etc. You don't think it would add context and clarity if you took 20 minutes from those activities and devoted them to examining a specimen?
Do you do whiteboard interviews? I've never done one less than an hour, and I think you'd be able to glean quite a bit of the same information by looking through the log.
Do you do homework? Who examines it? Could you not get similar perspective from looking at contributions on GitHub?
>I would be more than happy to look at a portfolio showing products built by them
To me, a candidate that has full-blown products out there is fast-tracked.
> You don't think it would add context and clarity if you took 20 minutes from those activities and devoted them to examining a specimen?
Sure. If I had to go through only a few CVs, maybe. And some times I do that for the ones our recruiters screen. But tbh, looking at github/source code and figuring out something (of value) out of it will be more than 20 min. Instead, maybe a blog post or products portfolios would be way more useful and give me something to ask for details on an actual interview.
> Do you do whiteboard interviews? I've never done one less than an hour, and I think you'd be able to glean quite a bit of the same information by looking through the log.
We do, and let me say that `git log` will absolutely not tell you the same info. One is the final version of a thought process (the log). On an interview, at least for me, the result is only one part of what I'm after. How you get there is way more interesting to me, the questions you ask, etc.
>Instead, maybe a blog post or products portfolios would be way more useful
Of course. That's why the author advocates for linking to a specific repo with a readme.
>We do, and let me say that `git log` will absolutely not tell you the same info
>How you get there is way more interesting to me
I get a lot of value from the revision history. To me, that is how you get there. When I see something, and I say, "I wish it was more like..." and a few commits later it is, I know we jibe. Likewise, if it's good, and it's something really novel and clean and clever and I never would have thought of it, that's just gold.
If your published code is bad I can quickly learn whether I'm wasting my time, but if it's good I still need to see you code in person. Neither GitHub nor homework proves you did the work.
>If your published code is bad I can quickly learn whether I'm wasting my time
Sounds good to me. I think we run the risk of training people not to publish, but that's why I like the author's advice to highlight one particular repo that is a showcase for how the individual works.
How do you decide to get the candidate in the pipeline? Presumably you're reading a CV and a letter, then having a phone call, etc. You don't think it would add context and clarity if you took 20 minutes from those activities and devoted them to examining a specimen?
Do you do whiteboard interviews? I've never done one less than an hour, and I think you'd be able to glean quite a bit of the same information by looking through the log.
Do you do homework? Who examines it? Could you not get similar perspective from looking at contributions on GitHub?
>I would be more than happy to look at a portfolio showing products built by them
To me, a candidate that has full-blown products out there is fast-tracked.