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

251–260 of 565 posts

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

#251

Post by heurisko »

jseban wrote: post #240
BFLpL0QNek wrote: post #150

Earlier quoted context omitted.

Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of y…

> PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely Yeah exactly, PR's are based on the fact that you have some person who is the owner that have complete power, and many other contributors who have zero power and whose contributions will mostly be rejected. You simply don't have that situation in a company, where everyone is an owner on equal terms, and all contributions…

> Yeah exactly, PR's are based on the fact that you have some person who is the owner that have complete power, and many other contributors who have zero power and whose contributions will mostly be rejected

PRs can be approved based on two people's opinion. There doesn't need to be a central gatekeeper.

> So you get these really weird situations where more junior, or less skilled, people can block PR's and demand changes from other more skilled and/or senior people.

Sometimes junior, or less skilled people, have something valuable to say. Especially if the code could be simpler.

In a stalemate, the PR could be sent to a third party. I've suggested this many times to avoid unnecessary conflict.

I don't think it is PRs that are the issue, rather your working environment.

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

#252

Post by KaiserPro »

At first reading, I thought this would be horrible

but then I realised it would tell me as an interviewee how good/bad the code is before I join.

If there are no comments, loads of "clever" optimisations lots of "syntactic sugar" it would be a good time to GTFO.

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

#253

Post by jseban »

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.

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

#254

Post by deepsun »

buf wrote: post #238
itronitron wrote: post #233

Earlier quoted context omitted.

A lot of developers' best work is within employers' proprietary code bases, do you consider it a red flag when they share some of that code with you?

I've never been put in the situation where an engineer shared something alarming from a proprietary code base, but hypothetically if someone brought with them the code for how to hack superuser privs for an old company, that would be an ethics violation and I would pass.

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.

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

#255

Post by dhzhzjsbevs »

olliej wrote: post #209
rileyphone wrote: post #198

Earlier quoted context omitted.

Sure there are a 1% of megaprojects that require additional process, but for the rest PRs are a method to control code quality socially. They introduce delays and foster ego antagonisms, so less methodical ways to control quality are optimal if the requirements are met (buy-in + skill) and complexity isn't too great.

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…

People seem to have forgotten what code was like back in the bad old days.

Fuck that dogpile of bullshit.

You've never seen a 1200 line diy function to parse XML have you?

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

#256

Post by refactor_master »

IshKebab wrote: post #243
refactor_master wrote: post #237

Earlier quoted context omitted.

It should be. As should “bring your own code”. In which other engineering industry can you ask this of people?

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?

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

#257

Post by pg_1234 »

deepsun wrote: post #254
buf wrote: post #238

Earlier quoted context omitted.

I've never been put in the situation where an engineer shared something alarming from a proprietary code base, but hypothetically if someone brought with them the code for how to hack superuser privs for an old company, that would be an ethics violation and I would pass.

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.

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

#258

Post by john_the_writer »

innomatics wrote: post #65
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 fin…

Honestly.. It's not just the desire to clean.

The management has to be set up to allow for this. People have to be able to work towards something as a team; else we are all cleaning in different directions.

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

#259

Post by dagmx »

I'm struggling to think of code examples that would be concise enough to be usable in an interview setting, but that are complex enough to still discern their skillset to code.

If you introduce subtle issues in your code, you're most likely just testing their familiarity with a framework or language nuance.

Big issues could work.

Perhaps just providing a take home codebase that's 80% of the way there, and asking them to take it to where they think the remaining 20% should be is a good middle ground.

Post reply on HN