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

381–390 of 565 posts

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

#381

Post by deepsun »

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.

Mmm, no?

I'm an employer right now in my small company. Don't see any reason to screw up my employees, on the contrary, I see it's much better to work in a friendly environment. There's no such "unimportant but necessary to the business" things.

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

#382

Post by buf »

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.

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

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

#383

Post by linspace »

ignoramous wrote: post #363
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…

> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. I hope they weren't some gatekeepers you ran into... " don't use emacs and fish and the dvorak keyboard? you don't fit in here ."

It would be quite absurd to dismiss a candidate based on the editor and yet I find it more important that a particular cloud provider, which quite often is a requirement.

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

#385

Post by linspace »

astonex wrote: post #87
ddaalluu2 wrote: post #48

Earlier quoted context omitted.

Quoted post unavailable.

>I cancel all interviews where I'm supposed to talk to some HR girl instead of an equal Seems like those interviews are doing their job then if they screen you out

Ha! One could think that the psychological screening is meaningless... until you are involved in hiring people. Of course, 95% candidates will pass, otherwise humanity would be doomed

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

#386

Post by ornornor »

whitesilhouette wrote: post #360

I do almost the same but a bit differently. Like a lot of people have suggested here that they can't share their company's proprietary code (neither can I). So I have cooked up some sample questions asking people to code for a app involving REST and CRUD (because that's resturant what we do at office). It's not much work and can be done in 2-3 hours. Then I get down to discuss their answers and the 'why' questions ar…

> It's not much work and can be done in 2-3 hours.

I bet it’s much more work than that. It’s maybe 2–3h for you, who has reviewed dozens of submissions, have designed the problem, and know what the actual solution is.

For the rest of us, it takes trial and error, implementing, polishing (because of course you want to show your absolute best code when being judged solely on your code) and it’s probably actually taking 2–4x as much time as you think it does. No applicant will ever tell you that because they don’t want to look bad.

Try and have people on your team do the challenge, you’ll see how much time it actually takes.

I personally pass on these. If it’s more complex than “implement array.flatten”, it’s going to take way too long and I decline to go further. If it starts with “implement a web app that…” or “an api that…” I don’t read any further and bail.

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

#387

Post by shawnz »

someweirdperson wrote: post #286
wildpeaks wrote: post #206

Earlier quoted context omitted.

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.

Maybe they should not be required in the ideal state, but I don't think it's wise to design your processes to only accommodate the ideal state.

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

#388

Post by [deleted] »

ignoramous wrote: post #363
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…

> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick. I hope they weren't some gatekeepers you ran into... " don't use emacs and fish and the dvorak keyboard? you don't fit in here ."

[deleted]

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

#389

Post by zo1 »

boomlinde wrote: post #289
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.

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…

I don't understand at all what you're saying. Sounds like you push your code to a branch called master that tracks master but sits on a separate repo and then you apply your commits after approval via patches? Seems like you're recreating the concept of branches using repos and then using patches instead of merging.

Either way, just so you know, this kind of attitude and that you think it's a-ok to use such a convoluted process for what is effectively the same thing would 100% mean me not hiring you. That may not mean much on some random forum on the net, but you will encounter it a lot as the industry is definitely not aligned to this odd flow you described.

Post reply on HN