Hacker News Reader

Comment by martijn_himself | Hacker News Reader

Could be updated:

Interviewer: Could you give us a couple of examples of carpentry projects you have completed in your spare time, and do you have a portfolio of projects you have worked on outside of your day-to-day job?

Carpenter: Uhm, what do you mean?

Interviewer: I mean like carpentry in your community, or a project you've completed to hone your skills outside work?

Carpenter: Oh, I am usually quite tired of hammers and nails when I get home and I like to spend some time cooking and cycling, but my carpentry work I do in my day job I am really proud of.

Interviewer: We are not really interest in your day job.

Carpenter: ..

View on HN

  Interviewer: Also, do you have any full stack experience?
  
  Carpenter: Yeah, I guess.

  Interviewer: How quickly would you adapt to using a new tool framework that comes out in the market?
  
  Carpenter: I would rather choose to use the tools that I have honed my skills in and am good at.
  
  Interviewer: But, considering the toolbase that our org uses, our other carpenter say that some new kit/framework comes out every other day and they all keep up. I think that toolbench is called JS in short.
  
  Carpenter: ...
  
  Interviewer: Also, how about the fragile methodology, any experience in that?
  
  Carpenter: Yeah, I guess.

But strictly speaking, considering that the outcome from both disciplines carpentry and software development are on opposite sides of tangibility, a straight up comparison isn't really helpful, to both disciplines.

It would be pretty cool if programmers could show their day job programs the way a carpenter can say "I build this" and people could look at it to see its quality. Unfortunately, this is often not possible.

How often can a carpenter really do this? What if most of his clients won't allow him to take pictures? And certainly most won't allow strangers to come in and fondle the furniture.

It's not uncommon for a contractor or architect to take pictures of a building after it's completed to use in their marketing material. It's pretty standard unless the client requests that they don't.

The client in these cases likely don't consider the architecture / product to be a critical competitive advantage.

On the occasion that they do (super efficient manufacturing plant), the same rules would apply.

TLDR; The carpenter analogy is horrible.

Few years back, had a knock on the door. Dude was there, said that he built our staircase, and could he take a couple pictures. It was a massive open log staircase, it was pretty cool. Filled us in on where the wood was from (local).

It was strange, but that happens there.

I agree reality is probably more subtle that this, but I do feel that there is too much emphasis on public repositories in application processes.

It's probably more common for recent graduates to have public repositories than for the majority of senior devs. Then again I'm sure there are other pressures graduates have to deal with that senior devs don't.

Too much emphasis? Most recent graduates don't even have a GitHub profile. They get jobs because they graduated. It's totally fine. If you did not graduate, you better have some projects to show though.

That's interesting. For companies I have approached recently it was the first question they asked. Maybe it depends on the kind of company (for me it was mainly start-ups).

Github full of passion projects is mutually exclusive with previous jobs being fast paced and/or requiring long hours - like startups.

I don't know what kind of emphasis you've seen, but being able to look at a public example of code a person has written is IMO the single biggest risk reducer available to a company hiring developers (well, other than actually having worked directly with the person before, which is an order of magnitude or two less common) because it gives me a picture of performance on real world software. Hiring is substantially about risk reduction because there's a huge amount of stuff you don't know about how the candidate will do. It would be foolish for companies to not take advantage of this potential source of signal. If it's not available, then I would proceed with my normal assessment process. Lack of public code isn't going to disqualify a candidate, but it does help to increase my confidence.

I suppose that is fair enough, and I don't think there is anything wrong with it being one of the ways in which companies assess potential candidates.

From my recent experience (and anecdotal evidence) it seemed it was becoming a deal breaker for companies but maybe I reached that conclusion too quickly.

Ive been in the game a while now , almost 18 years - 7 as a dev, and still get asked by recruiters generally within the first or second question if i have a github profile. Nope, I moved to BitBucket. Recruiter: never heard of it, what's that?

It'd be nice if tech recruiters actually had a background in tech.

Shouldn't have to. Should be able to talk intelligently about what you do and that should be enough. If I write SW that interacts with RFID readers, I should be able to talk about the various protocols. I should be able to talk about poll vs push and the benefits (and pains) of both. I should be able to talk about how to architect a performant system that gets the data from the devices, processes it and sends it on to some other device.

I should not have to worry about not being able to show any of that. If the people interviewing me don't understand what I did without me showing them, then I am certainly applying at the wrong company.

I once wrote some software that needed to interact with RFID readers. I couldn't talk about protocols then and I still can't today, but the program is still running just fine 10 years later.

Don't underestimate the value of some general understanding / intuition of how systems will probably work combined with a little googling.

I agree. I also read somewhere that talking about past behaviors (e.g. how you solved a complex issue) is the best indicator for competency (I can't back that up with sources sorry).

On a side note I also worked with RFID readers, they were yesteryear's Internet of Things :).

I do this by bringing samples of my code and documentation.

If you can do this that's great - often that is not possible for various reasons, usually "You wrote code for an employer, the employer doesn't want you to show that code to someone else".

I wouldn't be surprised if there was a pretty high correlation between working in a trade like carpentry and having a home workshop (it's almost universally true in my anecdotal experience).

There's a higher correlation in working in a trade like carpentry and having everyone they know needing carpentry work done as a favor.

I dunno. I was quite disappointed when nobody cared about projects could show when I was interviewing last time.

Right. At my last interview I'd try to steer the discussion to a side project or job-before-last but they pretty much only cared about my day job.

Interviewer: Can you show us some of your work from your day job?

Carpenter: No, it's all internal to my previous employer.

Reply on news.ycombinator.com