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

51–60 of 565 posts

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

#51

Post by lucb1e »

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.

> 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 suit), just not one that often works on large code bases. These patterns seem like something I'd learn in a matter of days on the job... but that would not show in an interview.

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

#52

Post by joshgachnang »

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?

Yup, this is what my current take home (2 hours) project is. Read about 200 lines of code, implement about 30 somewhat complex lines in a real working project. And then there's a code review by a "junior" candidate for them to read and review, filled with about 10 bugs in 50 lines. I much prefer it to giving out algorithms questions.

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

#53

Post by Silhouette »

I always preferred this style of technical interview because it has two critical advantages over tests based on coding from scratch in an interview situation.

Firstly, you can work with realistic code. It can use your real tech stack and there can be enough code with a realistic structure to see how a candidate finds their way around.

Secondly, you can make it open-ended. For junior candidates it might be best to stick to simple questions like what does this short function print and see if they can reason through some basic logic. But for more experienced candidates it can be a general code review.

Your example code can include anything from superficial mistakes like typos and unnecessary duplication to strategic problems like inflexible designs or inconsistent models. You can include obvious or subtle logic errors and performance problems appropriate to the level of the role.

Ask each candidate to talk you through what they're thinking about as they read the code and see what level they work on and how much they find in the time available. Are they methodical? Do they flag the trivial stuff but not get hung up on it? Do they spot the O(n^2) algorithm? Do they spot that algorithm but then start talking about worst case vs amortized performance and using a profiler to decide whether changing to a theoretically better but much more complicated algorithm would be justified?

In this kind of environment you can quickly tell if you have an awful or outstanding candidate. For the majority who fall in between you have an objective basis for comparing their performance. And all without any trick questions or LeetCode junk at all.

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

#54

Post by nitrogen »

lucb1e wrote: post #51
paulgb wrote: post #47

Earlier quoted context omitted.

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.

> 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, placement of braces and parentheses.

Flow -- pacing, grouping of blocks of code, levels of nesting, when and where to break up functions into spaced blocks or helper methods.

Architecture -- class boundaries, interfaces, cross-file organization.

There are higher layers but I haven't named them yet in mind and they aren't as well tested by this kind of interview.

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

#55

Post by jra_samba »

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 ?

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

#56

Post by jasoneckert »

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 Grand Master level in Microsoft Solitaire Collection.

Her: Yes.

Me: Well, we won't waste any more time then. Welcome to the team.

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

#57

Post by burnished »

eBombzor wrote: post #23
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.

That sounds terrible. That just implies, "if he doesn't have an amazing interview now, he's definitely an idiot".

What? Can you explain how that is terrible? I fear that the implication you are deriving says more about you than it does the method.

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

#58

Post by xboxnolifes »

jbluepolarbear wrote: post #39
jrochkind1 wrote: post #15

> because reading is easily an order of magnitude faster than writing. Hmmmm, really?

Is it not for you? I’m at least 10 times faster at reading code than writing code.

Does "finding the source of a bug" and "figuring out the correct thing to write to fix a bug" fall under reading the code or under writing the code?

I feel like the answer to those questions determines which is faster. One may say that you only compare (lines_read / time_reading) and (lines_written / time_writing) to find an answer, but if we remove all "time spent thinking" from both then it kind of feels like a meaningless comparison.

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

#59

Post by xtracto »

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.

Back when I was a hiring manager for programmers I liked setting a "code challenge" where we gave the candidate a simple game and he had to transform it into another game.

For example, we gave you a tetris game, you had to change the code to make a snake game. Or change an Othello game to a "number sliding puzzle" game.

It was very interesting comparing people that really made an effort to use the game code vs candidates that just deleted most of the stuff to implement their logic.

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

#60

Post by staunch »

I still think Triplebyte gave me the best interview I've experienced, and I've done ~100 over the years at all kinds of companies. I've also interviewed people ~1000 times myself.

It was even more impressive because the person doing the interview wasn't super competent and yet they still managed to do a fairly comprehensive technical evaluation in ~2 hours.

One section was a debugging session where you had to get tests to pass. The code and tests were quite decent, which made it quite easy to show off. Every company should do this.

Too bad the Triplebyte promise (not having to do phone screens) was a joke and their business model wasn't good, but that part of Triplebyte had major promise.

Post reply on HN