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

281–290 of 565 posts

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

#281

Post by KnobbleMcKnees »

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…

Riddles posed to me at engineering interviews: ~12

Riddles I've encountered while working as an engineer: 0

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

#282

Post by ratww »

refactor_master wrote: post #256
IshKebab wrote: post #243

Earlier quoted context omitted.

Art, architecture, writing, music, I mean pretty much every creative industry.

Hence why I said engineering industry. Would you ask a chemical engineer to bring a recipe for a proprietary drug synthesis? The creative industry doesn’t exactly aim to obfuscate its methods. Even better, would you ask a chemical engineer for their spare time projects? How would that even come about?

I graduated and worked for a few years as an electrical engineer. I had/have a portfolio of sorts and would gladly bring one to a job interview, including previous projects.

> Would you ask a chemical engineer to bring a recipe for a proprietary drug synthesis

Nobody is asking for anyone to bring complete codebases, either. Not to mention that, in chemical engineering, if something is proprietary enough, there are patents. Those come with credits.

I get the feeling that programming is the only industry paranoid enough to treat the most utterly mundane work as if it was bomb codes, averse to recognition enough to not credit people and disorganised/rushed enough so that 99% of companies are unable to let workers share their findings with others in the field.

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

#283

Post by buf »

anyfactor wrote: post #277
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…

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.

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

#284

Post by mhagemeister »

nickcoury wrote: post #8
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…

My favorite front end interview did this exact thing. The interview started with an issue taken straight from the Preact GitHub codebase. The interviewer provided the issue text and the commit right before it was fixed to pull down onto my machine. I had an hour to figure out how to build and reproduce the issue, Take in the high level structure of the code base, figure out how to drill down in a debugger to find whe…

Preact maintainer here.

That's amazing! I didn't know that our little project is used in interviews. Happy to hear that you liked working with the code base!

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

#285

Post by weatherlite »

ChrisMarshallNY wrote: post #100

This makes a great deal of sense, to me. But I am also the type of developer that would do well at this (experienced and older). Young folks, right out of school, or with just a couple of years of experience, would not do as well. I’m pretty convinced that one of the goals of LeetCode tests is as a “young-pass filter.” It controls for people close to college age, where those types of problems are common, as well as p…

I get your point but its not like recent grads have it super easy getting their first job; you have decades of experience interviewing (part of which is Leetcode which you have probably done many times); for them it's probably the first time doing this. On top of it all many places don't want juniors at all.

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

#286

Post by someweirdperson »

wildpeaks wrote: post #206
zdragnar wrote: post #119

Earlier quoted context omitted.

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.

I agree, the PR is invaluable to preserve context: the trunk history remains simple and linear thanks to squash merges, and you can still see the fine grained commits (and matching discussions/reviews) in the closed PR. It's also a way to give insight when onboarding new developers: if something is surprising, they can see why things came to be this way, not just accept the result at face value.

Explanations should end up in comments, documents, and the commit-comment of the squash (creating a good one takes some time when squashing).

The PR and original branch show dead-ends that should not be required reading to understand things.

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

#287

Post by actually_a_dog »

jseban wrote: post #275
olliej wrote: post #209

Earlier quoted context omitted.

No, every project I have worked on has review gated commits. It is a /basic/ step in ensuring that a project maintains a high quality codebase. Review does cause delays, because reviewing takes time, but we've generally found that the speed "gained" through poor change control is more than made up for through bad code. Review also shouldn't be causing ego antagonisms. You're coworkers. You have to be able to work tog…

> 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 the end product, which is what all members of an engineering team should be working toward.

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

#288

Post by xarope »

anyfactor wrote: post #277
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…

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.

This is definitely a concern. I've previously worked for e.g. eye bee... and despite having written massive amounts of code in c, java etc, I'm probably violating some major NDA if I show any of that code, or discuss details of a first-in-the-world active-active HA cluster solution in the 90s.

By comparison, my github or personal code would be just a bunch of perl, rexx, sh/bash and python scripts written just to automate some work. I doubt anybody would think those should be cleanly written, highly maintainable, modularised, etc...

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

#289

Post by boomlinde »

zdragnar wrote: post #119
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. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.

Where I work, development is trunk based and without pull requests, and all code is reviewed. When I want to submit code, I push it to a staging area that tracks master. This causes the commits to appear in Gerrit where (conflict-free) rebasing can be performed with a single button and the code can be reviewed. During the staging I can change anything about the commits to my hearts content. Once everyone is satisfied, someone with the authority to approve the change approves it and I submit it, upon which the patches are applied as-is on the branch I staged it for.

Creating a separate branch, pushing this to your public copy of the repository and then asking someone to pull from that branch into their master branch seems absurd to me, especially if it's just 1-2 commits, and the idea of reviewing code (which I think is extremely important at team scale) should not be conflated with the concept of pull requests.

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

#290

Post by throw14082020 »

anyfactor wrote: post #277
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…

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.

On average, who's going to be better at writing code, the one who has done a side coding project in the past 10 years whilst developing, or the one who hasn't but only worked a job? (assuming everything else is equal) - The one who has more time for side projects might also have more time for work, too. Unfortunately, it does remove good people, since not everything else is equal.

IMHO It's still better than leet-coding questions because most developers don't need to use the skills gained from practicing leetcode when at work, whereas open source contributions and projects are valuable. Also, someone with no time outside work and family would struggle with both leetcode and having side projects.

Post reply on HN