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

421–430 of 565 posts

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

#421

Post by rickosborne »

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?

Not OP, but I follow a similar process when I have to do coding interviews. I work around the "no public code" problem easily: "great, then pick an open source library you use regularly and let's go through and look at some of the things you do with it, what you like about the API design, and some things you stumble over or wish were better".

I've had candidates go through everything from jQuery to D3 to Spring to just parts of the Java SDK.

Also, in my experience, the percentage of people who have _zero_ public code is small. Maybe 10%. Certainly not half.

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

#422

Post by csmpltn »

jahnu wrote: post #416
buf wrote: post #382

Earlier quoted context omitted.

Hi, comment OP here. I decided to blog about this. It's cheeky, apologies. https://siliconvict.com/articles/6-how-to-hire-actually-good...

No worries at all :) > Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are. I don’t know what to tell you. It’s just so wrong it’s kinda wild how sure you are about this. At least half of the excellent colleagues I worked with in the past 10 years don’t fit your criteria. You’d be lucky to hire any of them.

I agree with you, this cannot be regarded as a healthy approach to hiring and comes off as delusional.

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

#424

Post by ithkuil »

NateEag wrote: post #396
someweirdperson wrote: post #286

Earlier quoted context omitted.

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.

I'm personally a fan of small, clean commits, rebasing without squashing before merge, always making a merge commit, and writing a clear, through merge commit explaining what the branch does. That way, I can treat the series of merge commits to trunk as the simple, linear overview of history, but when I'm bug-hunting I get small, clear commits to search through with git bisect. It also means I get more useful blame o…

Do you ensure your clean commits all pass all CI tests?

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

#425

Post by ravenstine »

pojzon wrote: post #231
innomatics wrote: post #65

Earlier quoted context omitted.

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…

If you want me to clean up the mess your ppl created over the years -> be ready to pay me hefty premium or equity. Often times it requires not only a lot of skill but also a lot of work. I can do it but be prepared to pay me 2-3 times the normal wage.

I see a few people didn't like what you said, and that's mystifying to me because while I understand the point of view of the business owner, as well as the reality that nearly all code stinks more or less, at the end of the day your #1 obligation is to your own interests. There's no reason people should choose to work on projects they don't like if they have no financial need to do so, or if the pay isn't enticing enough.

Attitudes will change in the next decade when vulnerabilities in software and tech become more obvious, serious, and regulated. Right now we're all happy hogs feeding from the trough of few meaningful standards, but the time will come when we are blamed for human lives lost as a result of bad code, and it's no longer going to be funny that we get paid so much to write such shit. As well, doing whatever companies pay us to do will become more shameful. From much of what I read here on HN and what I've seen in my own experience, way too many software developers will do practically anything for money and prestige.

This is why the selfishness of only wanting to work with teams that write decent code is actually more beneficial for society than "fail fast, bruh". Already, the tech bruhs aren't revered so much as they were even a handful of years ago.

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

#426

Post by jpgvm »

Silhouette wrote: post #117
swayvil wrote: post #45

Earlier quoted context omitted.

Yes, that would do nicely. Doing it because you choose to. Because you like it. That's key.

The trouble with this argument is that it excludes a huge proportion of the best developers out there. A lot of people got into programming because they enjoyed it but after doing it all day at work they want to do something else with their personal time. And the more experienced someone is with programming the older they are likely to be and the more likely it is that they will have other interests and commitments c…

Most contributions to opensource happen on company time atleast in my experience. I don't code much outside of work yet have plenty of OSS contributions because in the course of my work I discover bugs, desire new features, etc. All the best developers in these circumstances will atleast attempt to get their changes merged so they don't have to carry patches.

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

#427

Post by leaflets2 »

olliej wrote: post #346
jseban wrote: post #313

Earlier quoted context omitted.

> I don't want people who can't separate criticism of their code from criticism of themselves Yeah good luck with that, nobody can completely separate criticism of their work from criticism of themselves. You are making your job as the team leader way to easy for yourself, "I only hire robots, that's how I solve all these pesky people issues".

and yet many people on this subthread alone have worked in review-required jobs, and have not had a problem with it. They've also provided reviews for other people's patches, and presumably were also able to do it without personal attacks. It's the bare minimum of professionalism. If you are unable to separate feedback on your work, from attacks on your person, you are lacking some fairly fundamental skills needed fo…

> If you are unable to separate feedback on your work, from attacks on your person, you are lacking some fairly fundamental skills

Or for any job role at all?

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

#428

Post by hiptobecubic »

ithkuil wrote: post #424
NateEag wrote: post #396

Earlier quoted context omitted.

I'm personally a fan of small, clean commits, rebasing without squashing before merge, always making a merge commit, and writing a clear, through merge commit explaining what the branch does. That way, I can treat the series of merge commits to trunk as the simple, linear overview of history, but when I'm bug-hunting I get small, clear commits to search through with git bisect. It also means I get more useful blame o…

Do you ensure your clean commits all pass all CI tests?

Yes, generally. I don't really understand why anyone commits broken junk and then leaves it there.

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

#429

Post by kurko »

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.

Trunk driven does not mean mature team 100% of the time, but if you have a mature team trunk-driven is more efficient than PRs.

It only works if either everyone is senior, or it’s a project of 1-2 devs, or if people are pairing most of the time.

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

#430

Post by hiptobecubic »

berkes wrote: post #332
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…

You can have perfectly fine, high quality, peer reviewed code without PRs. Only if some regulation requires sign offs from e.g.other depts. PRs are inevitable. In all other situations they are at best an inneficient workflow and at worst a Kafkaesque circus. Peer programming, daily checkups, a rock solid CI, and, above all, trust in the professionalism of your team are some ingredients for high quality, high throughp…

Peer programming is just code review again, except now you're only allowed to write when two people are available.
Post reply on HN