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

101–110 of 565 posts

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

#101

Post by devoutsalsa »

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…

I took a job once because they were honest about the fact that the code was a complete shit show, and that’d I’d have to clean it up. I’m sure this is naive on some level, but I’d say you don’t have to lie to people. Just help them imagine doing the job and let them decide if that’s how they want to spend their time.

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

#102

Post by jra_samba »

teddyh wrote: post #98
jra_samba wrote: post #86

Earlier quoted context omitted.

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

Firstly, you seemed to imply that malloc(0) always, for all implementation, returns one or the other, and one of the two answers was wrong and the other was right. Secondly, why should a C application developer know enough about the implementation details of malloc() to answer such an esoteric question? Malloc can not, by definition, be implemented in C, so it seems a bit out of scope.

Of course malloc is implemented in C. Look at the glibc source code.

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

#103

Post by whatshisface »

devoutsalsa wrote: post #101
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…

I took a job once because they were honest about the fact that the code was a complete shit show, and that’d I’d have to clean it up. I’m sure this is naive on some level, but I’d say you don’t have to lie to people. Just help them imagine doing the job and let them decide if that’s how they want to spend their time.

Bad code + time allowed to clean it up = perfectly well-defined business requirements + a license to think about code craftsmanship. That's a lot of people's dream job.

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

#104

Post by gotaquestion »

This is a clever idea. First, every team has tons of code that a new-hire would see on day one. Might as well see how they perform! Second, this truly is an important skill. I've read hundreds of libraries, if not thousands, and being able to accept not just a coding style, but a thought style, and internalize it is essential. Yeah, the more I think about this, the more I wish I had thought of it when I was hiring!

I'm kinda jealous, I'd love to do code interviews again, but I haven't been a junior dev in ... /* checks notes / ... over three decades?!? cries in yaml*

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

#105

Post by [deleted] »

lkrubner wrote: post #26

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…

[deleted]

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

#106

Post by cldellow »

lucb1e wrote: post #3

That's interesting, I've never heard testing code skills by reading instead of writing. An example would have been nice though, as I'm not sure how to find a piece of code that does something standalone that is too large to grasp in 20 minutes yet make a reasonable prediction at the output. That combination seems kind of weird. I wonder how well it would work to modify OP's idea and present a candidate with some code…

We used to have an interview process that had a take-home project.

The project was:

- you have two files: listings.json and products.json

- listings.json lists ~20,000 Amazon listings for electronics with fields like title, brand and price

- products.json lists ~1,000 digital cameras, with fields like brand, family, model

- your job is to write a script that, for each entry in listings.json, emits the best match (or no match!) from products.json

Your solution could be as naive or as fancy as you wanted. The main point was to have something for the next stage.

We'd run your submission, and use that to show you some false positives and false negatives. Then we'd ask you to debug why each false positive or false negative happen, explain it to us, propose how you'd fix it, and identify any trade-offs in your proposed fix.

Eventually, we wanted to offer a non-take-home-project interview. We already had a bunch of existing solutions from employees, so we used those to run a stripped down version of the interview that just focused on the code reading/debugging/proposing fixes part.

I think both of these interview approaches were pretty effective at giving candidates a natural environment to demonstrate skills that they'd actually use on the job -- debugging, collaboration, predicting downstream implications of changes, etc.

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

#107

Post by GuB-42 »

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?

By doing that you will be selecting for the "cracker" type. That is people who are able to get into any code, even under adversity, and do anything they want. It is a great skill to have even if you job doesn't involve removing copy protection, for example, he may be the only person who will be able to fix a bug in that old code base written in an obscure language when the last person to work on it left the company 10 years ago.

What you won't be testing is higher level skills. It may be easy to hack into a known codebase, and even do it cleanly, you just have to mimic the surrounding code. Getting the big idea and making long term choices is another set of skills, not exclusive with being a cracker, but not something you can see in 10 lines of code.

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

#108

Post by anyfoo »

lucb1e wrote: post #22
Buttons840 wrote: post #5

Earlier quoted context omitted.

Good idea. I'm not sure I know arg parsing libraries in every language though. Even so, hopefully talking about where to make the change and finding some good documentation on an arg parsing library would be good enough start for 20 minutes.

> I'm not sure I know arg parsing libraries in every language though. In my opinion, you should be free to look that up: that's what you'd do on the job as well. I also google it every time I need to use arg parsing in literally any language because I need it fairly infrequently, and frankly that's how this code came to be: too lazy to look it up again, too easy to write myself, and enjoying the writing of code. Any…

Yeah, we sometimes say stuff like "we don't expect you to know the arguments to sigaction just like that, you can ask us anything[1] or just put what you think could be reasonable", to make clear we're not looking to hire an encyclopedia.

[1] And if they do, we probably end up pulling up the man page for them because we don't remember either. It's just not the relevant part of any coding interview, the reading or the writing kind.

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

#109

Post by ibeckermayer »

jra_samba wrote: post #84
aunty_helen wrote: post #78

Earlier quoted context omitted.

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()…

I'm not a C expert and I'm stumped but curious. What does malloc(0) return and why is that important?

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

#110

Post by Silhouette »

jra_samba wrote: post #84
aunty_helen wrote: post #78

Earlier quoted context omitted.

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()…

That's one way to look at it. Another might be that if you write code that passes unsanitised input to anything and can get that code through testing and review then maybe you're not the kind of organisation that a candidate who knows about security wants to work for.

In the end this is still a language lawyer question. It's a technicality that should never be relevant. If it is you've already gone wrong several times. In other languages there might be an argument that it probably does something reasonable and any developer experienced with that language should be able to make an educated guess about what that would be even if they don't know. But you asked about C, a language infamous for having undefined behaviour in many such situations, so I don't think even that is a particularly compelling argument here.

Post reply on HN