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

301–310 of 565 posts

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

#301

Post by jseban »

actually_a_dog wrote: post #287
jseban wrote: post #275

Earlier quoted context omitted.

> Review also shouldn't be causing ego antagonisms. Yeah but the tool itself is antagonistic, because it imposes a workflow of open source, a workflow that also is antagonistic with clear and absolute power. So using that tool suddenly brings that antagonism and power into a team which is supposed to be 100% collaborative, and it also only does it periodically and with random and different people in power. It's not h…

Anyone who can't handle having their code reviewed before it goes into production is not welcome on my team. You can call that antagonistic or not, but I have always found that the best engineers are the ones who are able to separate criticism of their code from criticism of themselves. Get that type of people on your team, and code review is no longer antagonistic: it's just an egoless feedback process that improves…

I'm not criticising the review itself as much as rather the PR workflow and the tools of github, especially the blocking mechanism. It's my opinion that collaboration should happen much sooner rather than being pushed to the end with the review of a PR, and that you should have designated people who have the power to sign something off as production ready.

If a team inside a company want to gather inspiration from the open source world, they should look at how the owner teams of open source projects work internally, not how they work together with outside contributors.

And, it's a very common "solution" in tech to just simply not have any feelings, but people have feeling and that you can't turn off, and that's a very important contributor to work satisfaction.

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

#302

Post by aidos »

jseban wrote: post #253
buf wrote: post #224

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 be…

Sounds good maybe for a founder or early in a startup, but otherwise this would probably illustrate the mismatch in priorities that exists between a single person's passion project, and risk-averse enterprise groupthink.

I think it’s really important to differentiate the code and the coder. Where we use this technique, I actually say to candidates, “I don’t care about the language / quality / age / immaturity of the code- it’s just something that you should be familiar with”. If someone turned up with an open source codebase to talk about it would be absolutely fine too.

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

#303

Post by DeathArrow »

>Nobody sketches code on a white board or notepad as part of their daily work.

Sometimes when I'm trying to plan something which requires a lot of thinking I take a piece of paper, write bits of code, draw schematics of the flow, schematics of data structures. If I am planning the architecture of an application which isn't trivial, I like to go to the whiteboard and draw. Even if I have it in my mind, visualizing it helps me find improvements.

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

#304

Post by hnfong »

pg_1234 wrote: post #257
deepsun wrote: post #254

Earlier quoted context omitted.

Well it does not matter if it's alarming or not. They are in violation of their signed NDAs with their previous employer. Also, if they don't work there anymore, they should've deleted all the code (if they had it) and surrendered/cleared up all the laptops. But I like your idea, anyway I give big kudos to candidates with their own pet projects.

Almost every employer will violate their employee's rights without a second thought in ways they consider "unimportant but necessary to the business" ... as long as that continues it should be a 2-way street.

The point is not necessarily whether it's morally wrong to violate a contractual agreement when the other party is likely to do so.

It's that the interview process proposed by the G[...]P may force the candidate to do things that may be illegal to pass the interview. The candidate is of course responsible for their own choices, but the point is that as an interviewer, if you force your candidates to do this, you might short list those who have a tendency to violate contract terms.

This might work out for some, but I'd say it's a fair point to bring up.

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

#305

Post by moonchrome »

jahnu wrote: post #270
buf wrote: post #224

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 be…

Surely this will filter out ~50% of people who are good but don’t have any public code? I have a family and as such no free time for coding so I haven’t written any code I can legally show anyone else in more than a decade. But everyone who has employed me is more than happy with my work. Not to mention code is only half of why you would want to employ any developer.

>Surely this will filter out ~50% of people who are good but don’t have any public code?

It then becomes a take home assignment where you get to pick the topic.

Surely you wanted to protoype some tech but didn't have the opportunity at dayjob - so make that prototype and bring it to review.

Much higher interview value than take home assignment IMO, but you need to be competent as an interviewer to enter into a discussion on something you might not understand yourself.

And it's also higher value to the person applying because they get to protoype stuff they find interesting.

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

#306

Post by actually_a_dog »

jseban wrote: post #301
actually_a_dog wrote: post #287

Earlier quoted context omitted.

Anyone who can't handle having their code reviewed before it goes into production is not welcome on my team. You can call that antagonistic or not, but I have always found that the best engineers are the ones who are able to separate criticism of their code from criticism of themselves. Get that type of people on your team, and code review is no longer antagonistic: it's just an egoless feedback process that improves…

I'm not criticising the review itself as much as rather the PR workflow and the tools of github, especially the blocking mechanism. It's my opinion that collaboration should happen much sooner rather than being pushed to the end with the review of a PR, and that you should have designated people who have the power to sign something off as production ready. If a team inside a company want to gather inspiration from th…

There is nothing about github hat prevents you from working that way. I don't see what your issue is. But, I will say that I don't want people who can't separate criticism of their code from criticism of themselves on my team. You can certainly have whatever feelings you want, as long as it doesn't get in the way of producing the best possible product, all things considered.

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

#307

Post by bagels »

buf wrote: post #283
anyfactor wrote: post #277

Earlier quoted context omitted.

I am out. My good code are paid for and thus is owned by someone who is not me and can't be shared with a third party. The code that own is inherently bad as I want to create things as fast as possible without being bogged down by proper code writing etiquette.

Everyone in this thread seems to be hung up on sharing code from an employer or 'good code'. You could clone an open source repo and use that if you're worried. The value isn't the code; it's the conversation. "Bring your own code" is just meant to put the interviewee at ease because they are already prepared to talk about their own code.

Folks were responding to "Bring code you've written" which is different from just bringing some code.

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

#308

Post by andrewflnr »

WaxProlix wrote: post #46
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?

Only one I can think of is that a couple hundred lines (depending on content of course) can be quite a bit to grok within a 50 minute span. Especially if there are a number of places where improvements might make sense, but you have one or two in mind specifically... I've been in that sort of position tbh, where a 200 line codebase has maybe 20-30 obviously wrong parts (creds in code, calls to 3rd party service in co…

You would have to fine-tune the size, taking into account that narrowing your focus to the relevant parts of the codebase is an integral part of your reading skills.

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

#309

Post by jseban »

actually_a_dog wrote: post #306
jseban wrote: post #301

Earlier quoted context omitted.

I'm not criticising the review itself as much as rather the PR workflow and the tools of github, especially the blocking mechanism. It's my opinion that collaboration should happen much sooner rather than being pushed to the end with the review of a PR, and that you should have designated people who have the power to sign something off as production ready. If a team inside a company want to gather inspiration from th…

There is nothing about github hat prevents you from working that way. I don't see what your issue is. But, I will say that I don't want people who can't separate criticism of their code from criticism of themselves on my team. You can certainly have whatever feelings you want, as long as it doesn't get in the way of producing the best possible product, all things considered.

Yeah there's nothing that prevents you from using a tool in exactly the opposite way that it's designed to be used, but it's also pretty unlikely that it's going to happen or that it's going to be successful.

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

#310

Post by DeathArrow »

>So instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works.

While reading and understanding code written by others is an important skill, I am not sure it would be totally fair in an interview. The candidate might not be familiar with the particular coding style. The code can be very easy to read or very cryptic. I can write easy to read code, cryptic code or anywhere in between.

So since reading code doesn't solely depend on the candidate 's skills, basing hiring decisions solely on it, might not be the best idea.

I would see no harm, though, if part of the interview consists in testing the comprehension of well written code.

Post reply on HN