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

81–90 of 565 posts

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

#81

Post by teddyh »

jra_samba wrote: post #55

When I did interviews @ Google (I only do hiring committee work now, thank god :-) I usually asked questions around bugs I added to an existing codebase, to see if the candidate can avoid the pitfalls I ran into by making bad assumptions. As I'm a pure C coder, my starter question was usually something like: a). What does malloc(0) return ? b). Why does it do that ?

According to GNU libc, malloc(0) can return either NULL or a valid unique pointer value which can later be passed to free(). You seem to imply that one or the other is definitely true.

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

#82

Post by johnqian »

quantisan wrote: post #43
johnqian wrote: post #18

I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.

how do you ensure consistent criteria between candidates and avoid unconscious bias?

The standard coding challenge is still most of the interview, so that provides some consistency. I just want to give candidates an additional opportunity to flex, in case they feel there's an important thing that most interviews neglect. Most candidates never really thought about it, and that's totally fine, for them I just do the standard course.

As for avoiding unconscious bias, was that ever an option?

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

#83

Post by anyfoo »

johnqian wrote: post #18

I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.

> It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to.

I like leading with that, and am a big fan of the initial "what's an interesting problem you had to solve?" question, but I made the unfortunate experience that even people with good war stories are sometimes very shaky in the basics of the particular subfield I'm interviewing for. To the point of deeming someone not a good match for our team, but encouraging them and internal recruiters to interview with other teams.

There is ultimately no full substitute for getting down to brass tacks and actually do some "sample work" together. Whiteboard coding is the usual (and, I guess, often poorly implemented) approach, but I've used reading existing code, with added intentional mistakes, to great success so far.

EDIT: Just read your new reply in a sibling thread that you're doing that anyway, and project and war stories are supplemental. It seems like we're in agreement, then!

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

#84

Post by jra_samba »

aunty_helen wrote: post #78
jra_samba wrote: post #55

When I did interviews @ Google (I only do hiring committee work now, thank god :-) I usually asked questions around bugs I added to an existing codebase, to see if the candidate can avoid the pitfalls I ran into by making bad assumptions. As I'm a pure C coder, my starter question was usually something like: a). What does malloc(0) return ? b). Why does it do that ?

I find questions like this lack an on-ramp. Either you know or you don't. If you don't it gives you 0 indication of the skills. I once flunked a faang interview because the interviewer mispronounced (or used the correct pronunciation I was unfamiliar with) of "arp protocol" I had no idea of what was being asked and was racking my brain for something I didn't think I had ever used to down every computer in the library…

No, that's not true. If you know anything about C and writing secure code (which I what I was probing for) you know about using malloc(). You know because you have to know something about the internals of memory management.

Imagine you just read a 4 byte value off the network, and it's part of a protocol that specifies how many more bytes there are to read. You might (in error, ahem... :-) pass that value to malloc(). So knowing what might happen if an attacker puts an unexpected value in there is something you need to think about.

If you don't know or can't guess because you don't know how malloc() works, then you're not the person I'm looking for.

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

#85

Post by gaoshan »

Aeolun wrote: post #17
gaoshan wrote: post #14

This is exactly what I started doing at my company a few years back. You are presented with a complete app written in the stack we use. This app has some bugs we will solve to get it working (nothing that's a trick... actual, commonly encountered bugs that have all the error messaging you need to solve them). Once it is working you will walk me through a particular flow of the app, explaining what is going on and why…

How long is this interview? I can debug a random React app in 30 minutes, but a whole stack may be pushing it.

1 hour. The initial bug takes most people about 5 minutes or less (the console error practically tells you what to do if you actually read it)

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

#86

Post by jra_samba »

teddyh wrote: post #81
jra_samba wrote: post #55

When I did interviews @ Google (I only do hiring committee work now, thank god :-) I usually asked questions around bugs I added to an existing codebase, to see if the candidate can avoid the pitfalls I ran into by making bad assumptions. As I'm a pure C coder, my starter question was usually something like: a). What does malloc(0) return ? b). Why does it do that ?

According to GNU libc, malloc(0) can return either NULL or a valid unique pointer value which can later be passed to free(). You seem to imply that one or the other is definitely true.

Yes. Write test code for glibc. You'll find it always returns one of the two. There is a reason for that.

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

#87

Post by astonex »

ddaalluu2 wrote: post #48
johnqian wrote: post #18

I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.

Quoted post unavailable.

>I cancel all interviews where I'm supposed to talk to some HR girl instead of an equal

Seems like those interviews are doing their job then if they screen you out

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

#89

Post by Cyph0n »

jasoneckert wrote: post #56

Of course, if a developer comes with experience and personal references from acquaintances, you don't need to test their abilities at all during the interview process. For example, I hired a backend developer last month. She already had the job because she came highly recommended from a trusted friend of mine, but she didn't know that. Here's how the interview went down: Me: I see on your resume that you've achieved…

Completely off-topic: I am 99% certain that I read a very similar comment on HN a few weeks back. Did you happen to share this anecdote on another HN thread?

This is my first time experiencing HN deja vu :)

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

#90

Post by mylons »

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…

the blog author doesn’t take them through the company’s code base. the author creates code for the interview.
Post reply on HN