Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When hiring developers, have the candidate read existing code

freakingrectangle.wordpress.com

Post reply on HN
Print view View original

221–230 of 565 posts

Re: When hiring developers, have the candidate read existing code

#221

Post by jonahx »

TameAntelope wrote: post #192
jonahx wrote: post #186

Earlier quoted context omitted.

>No need to interweave documentation and code, in most cases. Locality is the reason, and it's a good reason. Of course, I don't want to see paragraphs of explanation inline, but a one-line comment giving context for some choice that might be confusing is much better and faster to work with than a separate WHY doc.

It's neither faster nor better, in practice. It's not faster because you can just name the variable whatever it is the value represents, so by adding a second descriptor (the comment) you're introducing needless complexity. It's not better because you really shouldn't be changing a value you don't understand the context around, which means reading much more than a one-line comment.

I am saying things like this:

https://github.com/golang/go/blob/master/src/cmd/cgo/ast.go#...

belong in the source code, not a Why doc. No variable naming can give that context.

Re: When hiring developers, have the candidate read existing code

#222

Post by morelish »

Yeah I had an interview like this recently. First part of the interview proceeded well as they asked me to read different bits of code and how different language features worked.

Then I was asked a brain teaser that I bombed. And that was the end of the interview.

Re: When hiring developers, have the candidate read existing code

#223

Post by haspok »

Problem is, reading is at least an order of magnitude easier than writing.

In terms of natural languages, if you can read and mostly understand a text in another language, let's say you score 8/10. At the same time it is completely reasonable to expect that you would not be able to write the same text, and if you had to, it would be at 5/10. Then if you had to do it in a speech, you would score a measly 3/10.

I'm not saying that focusing on reading and analyzing code is a bad idea, just be careful, and expect these differences in skill levels. Definitely a hundred times better than leetcode though.

Re: When hiring developers, have the candidate read existing code

#224

Post by buf »

I've interviewed maybe 500 engineers in my career. I'm an early engineer of Instacart, 3rd engineer of Eventbrite, founding engineer of Reforge. Started 3 companies myself.

My interview is always the same:

1. Bring code you've written 2. Share your screen 3. Explain what it does and I will casually ask questions about it

You get so much information from this:

- How they think about code - If they think it could be better - Who they blame if the code isn't the best - Personality - Product dev glimpses - Comms - Sentiment

Re: When hiring developers, have the candidate read existing code

#225

Post by pelario »

haspok wrote: post #223

Problem is, reading is at least an order of magnitude easier than writing. In terms of natural languages, if you can read and mostly understand a text in another language, let's say you score 8/10. At the same time it is completely reasonable to expect that you would not be able to write the same text, and if you had to, it would be at 5/10. Then if you had to do it in a speech, you would score a measly 3/10. I'm not…

I suspect you have not read enough code.

Re: When hiring developers, have the candidate read existing code

#226

Post by sigg3 »

mongol wrote: post #220
wonderbore wrote: post #216

Earlier quoted context omitted.

Better yet: const ONE_HOUR_IN_MS = 3600000 const RESEND_DELAY = ONE_HOUR_IN_MS

I don't get why this is better. My approach: const RESEND_DELAY_MS = 3600000; // because TTL in Agora

I've used stuff like this to do:

const ONE_HOUR = 3600000;

const RESEND_DELAY_MS = 2.5 * ONE_HOUR; // because TTL in Agora

IMO it makes it easier for successor to fiddle with.

Re: When hiring developers, have the candidate read existing code

#227

Post by kissgyorgy »

Good article, terrible advice at the end. I agree 100%, seems like a way better interview approach, but the last sentence is just not applicable to everybody. I enjoy doing side projects, but should not be a requirement and you can be a great developer without even having a public project on GitHub.

Re: When hiring developers, have the candidate read existing code

#228

Post by pojzon »

BFLpL0QNek wrote: post #41

I like this approach. Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard” or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch. At least being taken through existing code you know w…

This is precicely why only few companies will do this kind of interview.

Good candidate would instantly notice the team is being labeled as seniors but instead are a bunch of crappy devs with years of experience.

Code does not lie. If you are crap you gonna produce crap code.

Ive recently hit such a mine. Lies during interview. Gonna sit here through vacations and jump the ship. Was sold on working with experienced ppl with over 10y of experience. Turns out those ppl IMHO have less skill than me few years ago with only 2y experience. Legacy bugers that did not improve over the years.

Re: When hiring developers, have the candidate read existing code

#229

Post by schobi »

mongol wrote: post #220
wonderbore wrote: post #216

Earlier quoted context omitted.

Better yet: const ONE_HOUR_IN_MS = 3600000 const RESEND_DELAY = ONE_HOUR_IN_MS

I don't get why this is better. My approach: const RESEND_DELAY_MS = 3600000; // because TTL in Agora

I would even go for

const RESEND_DELAY_MS = 3600*1000; // because TTL in Agora

Easier to check for the right number of zeros

Re: When hiring developers, have the candidate read existing code

#230

Post by kissgyorgy »

tisc wrote: post #217
srigi wrote: post #208

Earlier quoted context omitted.

Agree. I also add to this - name your constants by meaning, not value. Too many times I see const ONE_HOUR_IN_MS = 3600000 Instead I would like to see const RESEND_DELAY = 3600000

I like to combine those: const RESEND_DELAY_MS = ONE_HOUR_IN_MS; Having the unit in the name saved me more than once and having non-contextual constants for sizes increases readability imo.

I do this instead:

    const RESEND_DELAY_MS = 1 * 60 * 60 * 1000;  // one hour
Essentially the same, but the lack of extra variable spares one jump. Also you can change it without introducing a new variable (no dependency).
Post reply on HN