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

61–70 of 565 posts

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

#61

Post by aunty_helen »

paulgb wrote: post #47
andrewflnr wrote: post #37

My thesis is that the true measure of reading code is still the ability to fix and extend it. So my current ideal interview problem is still a tiny toy codebase, where the interviewee is tasked with adding some (relatively trivial) feature to it. Like ten lines of code, but where those lines require you to have grokked the other couple hundred or so. Any downsides?

One thing I like about this (as opposed to a “blank slate” coding challenge) is that it shows how well the candidate is able to fit into the broader design style of the surrounding code. Not just the superficial things (like naming conventions), but also the structural patterns.

You do miss out on the 'sit down and create a project' aspect though. Which shows things like familiarity with project structure, (python specific) virtual environments and paths etc.

These are good skills to have when a dev is debugging as they could get tied up for a long time dealing with something as simple as a relative path issue.

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

#62

Post by lucb1e »

nitrogen wrote: post #54
lucb1e wrote: post #51

Earlier quoted context omitted.

> fit into the broader design style of the surrounding code[, including] the structural patterns. That might require one to be familiar with those ahead of time. If that's what you're hiring for, that's perfect of course, but I personally haven't had much experience with design patterns outside of a few C# ones in school five years ago. Yet I see myself as a competent amateur programmer (and C# isn't even my strong s…

It's kind of like learning a subject from the final exam. If you can pick up on the patterns of an unfamiliar language and/or codebase and make your code look like it fits in, you're probably good at both reading and writing code, and working with a team. I can't speak for the parent commenter, but by "patterns" I am referring to multiple layers: Detail -- Indentation, spacing, line length, naming convention, placeme…

Fair enough, if that is meant then I imagine any competent programmer should be able to do that. I kind of figured that indentation and nesting levels were what they considered to be "superficial things [like] naming conventions". Cross-file organisation might be too large to adequately demonstrate in an interview, presuming it's not a whole-afternoon type of thing that seems popular in the USA (or at least I haven't seen them in Europe, I'm sure they must exist if only I post a comment saying they're not popular here).

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

#63

Post by llimllib »

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'm not anything other than a C tourist, and I see that the man page says it returns either NULL or a "unique pointer value that can later be successfully passed to free()."

I'm kind of at a loss about why it can return either of those two things, somebody want to take a shot at explaining it?

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

#64

Post by aunty_helen »

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.

Building software mostly requires working in teams though. If you want to go it alone as a contractor there's no need to be applying to HR depts

I mean, forgive me for stating the obvious, but they're not trying to make you come out of your shell because they want a friend to talk to.

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

#65

Post by innomatics »

ravenstine wrote: post #35

This would be great because if the code stinks to high heaven then I won't work there. When they think I'm not a fit for not understanding their code, the feeling would be mutual.

I agree with you in the sense that I only want to work places that recognize and value great code.

But everywhere has code that stinks. And it's hard to find people with the skills and experience to get rid if it. Before it can be gotten rid off, it must be understood.

In a sense it might be valuable to use the poor code in a reading screen. Firstly so we can agree it stinks, and the reasons why. And secondly, to find people with the attitude required to clean up messes that they didn't create (good scouts).

Even when the job is greenfield, or extending great code, I'd rather have engineers with the battle scars of doing tough maintenance.

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

#66

Post by oconnor663 »

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 ?

Huh. My first answer was "I don't know", and then I googled it and apparently it's implementation defined. So...my first answer was correct? :)

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

#67

Post by anyfoo »

0x20cowboy wrote: post #31

I think we should just jump to the end game and make interviewees do ultra man triathlons while solving differential equations. Then at the finish line, they knife fight each other to find the one we let go to the next stage in the interview. That way we can be sure who has stamina and the best competitive programming problem solving skills. Something like squid game will truely find the A players. I mean, we wouldn’…

I did the reading of existing code thing in interviews a lot a while ago (and somehow forgot about it when switching teams, this reminded me to reintroduce it), with the probably common twist of having intentional mistakes at various levels in the code, and it was absolutely great.

I feel it really gives you a good impression of the level of experience the candidate has with actual coding, and opens up for a lot of related discussion, such as security implications. Without, as the article mentions, the tediousness and artificiality of whiteboard coding (which I don't want to completely dismiss, however).

We're going to be working on a lot of code together, so it makes sense to have the interview about doing exactly that.

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

#68

Post by jra_samba »

llimllib wrote: post #63
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'm not anything other than a C tourist, and I see that the man page says it returns either NULL or a "unique pointer value that can later be successfully passed to free()." I'm kind of at a loss about why it can return either of those two things, somebody want to take a shot at explaining it?

Both NULL and a unique pointer value can be safely passed to free() :-).

Answers to this question taught me about the candidates taste and understanding of good API design :-).

Both NULL and "unique pointer" are correct answers, but all modern implementations only chose to return one of these. My follow-up question is "why ?" :-).

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

#69

Post by ineedasername »

Reading probes the most fundamental skills. Reading code is probably 95% of what a developer does as part of their job.

This is true. Most of the time I'm only reading my own code, and over the years I've been motivated to code better by having to go through crap I wrote early on.

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

#70

Post by bluefirebrand »

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…

> Bonus points for no PR’s and trunk driven development as that shows a very mature team.

I'm not sure what Trunk Driven Development is, could you elaborate?

Post reply on HN