When hiring developers, have the candidate read existing code • Hacker News Board

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

#331

Post by jollygoodshow » Sat, Apr 16, 2022, 9:44 AM UTC

throw14082020 wrote: post #290

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.

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

But time is the important part here - a single parent raising two kids is not going to have time to code at home versus a twenty-something year old with no responsibilities and dependants who has an abundance of free time. Selecting in that manner can also end up being a discrimination (those from poorer backgrounds are more likely to need to care for relatives, same goes for women, who on average do ten hours more of unpaid care than men a week)

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

#332

Post by berkes » Sat, Apr 16, 2022, 9:45 AM UTC

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…

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 throughput software development.

This is not an opinion. It's a scientifically proven fact. As laid out in the book Accellarate.

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

#333

Post by jhfgjhfgjhg » Sat, Apr 16, 2022, 9:48 AM UTC

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.

"Almost every employer will violate their employee's rights without a second thought"

What's your source?

"unimportant but necessary to the business"

What examples?

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

#334

Post by tiborsaas » Sat, Apr 16, 2022, 9:50 AM UTC

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.

I'd still show them my bad code, since I do pretty much the same thing. It would be a good opportunity to show how I'd refactor the side project if I could dedicate more serious time to it.

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

#335

Post by EugeneOZ » Sat, Apr 16, 2022, 9:50 AM UTC

moonchrome wrote: post #305

jahnu wrote: post #270

Earlier quoted context omitted.

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

Work created in 1-2 hours is very different from a work created in 1-2 months.

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

#336

Post by a3w » Sat, Apr 16, 2022, 9:51 AM UTC

no-dr-onboard wrote: post #135

I’m personally against this approach. I’m an appsec person. I absolutely do not know how to write most of the code I review. In my past two jobs I’ve been required to read code and explain it during interviews. I’ve never had trouble explaining what’s going on because on a very basic level, most languages use the same conventions. If this were a heuristic of a good developer, it would let me (not a dev) in and who kn…

Oh Writing Code is easy: copy and modify ;) Pros remove the edge cases that allow exploits from stackoverflow examples, but you seem to be qualified to do that.

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

#337

Post by hutzlibu » Sat, Apr 16, 2022, 9:53 AM UTC

xarope wrote: post #288

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.

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

" 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"

I do. Even though my quick and dirty scripts are not always clean either, I still profit from the times when I take some more minutes to document what a certain script does and clean out at least the rough edges.

Otherwise it means rewriting the same thing again and again, which costs more time in the end. Or it means executing something you barely understand yourself anymore, which can be dangerous.

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

#338

Post by BlargMcLarg » Sat, Apr 16, 2022, 9:54 AM UTC

pierredewet wrote: post #323

This is my preferred option also but I love reading the comments when these sorts of posts appear as it seems that interviewing is still something that causes loads of debate and no matter whether the op is whiteboard, tricky algorithm or focussed, there’s still a hot debate. Interviewing just seems broken It must surely boil down to the profession aspect. Doctors and lawyers do a period of internship after and durin…

>It could just be an American thing, though.

It's not. You'll find plenty of anecdotes outside the US. Even just outside SV is enough to put things into question, as salaries outside SV are way lower.

>Doctors and lawyers do a period of internship after and during the degree that perhaps mitigates the uncertainty around hiring.

Two problems with this.

For one, this is changing rapidly. Any institute of higher education is becoming a worker factory focusing on what the industry wants in candidates rapidly. Despite this, interviewers continue to complain about the most minor things which in reality are very easy to grasp for people with a degree and some projects.

For two, this problem still persists after having some years of experience under your belt. If an internship mitigates the need for other professions to go through this, surely having verifiable experience should do the same. But it doesn't, and it takes away a lot of time from people to build their own portfolio to get through interviews with too.

>It must surely boil down to the profession aspect.

I don't believe so. Hiring is plagued with perfectionism and idealism, looking for the perfect candidates and failing candidates over the most minor things. You could actually be the best candidate in the world, and you'll fail because you said something or did something in a way the interviewer preemptively labels as "unviable".

The problem is actually as you point out: hiring managers are pushing risks onto individuals in the name of "calling", and loads of developers are doing nothing to push back on it. Or worse, they are encouraging it. See also why the average junior requirements includes an entire IT department's worth of skills.

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

#339

Post by wingerlang » Sat, Apr 16, 2022, 9:54 AM UTC

swinglock wrote: post #320

wingerlang wrote: post #279

Earlier quoted context omitted.

Not sure how locked your computer is but everywhere I've ever worked, it's been trivial. Email the source file, zip it and upload somewhere, pastebin temporary, airdrop it, usb sticks.

You would do that? Now I'm beginning to consider if I should be asking candidates to bring some intellectual property owned by their current/previous employer as a filter.

I am not saying I would do that (I wouldn't). I am just not sure how a computer can be locked down so tightly that it is impossible to send text from it to another computer.

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

#340

Post by brongondwana » Sat, Apr 16, 2022, 9:55 AM UTC

EugeneOZ wrote: post #335

moonchrome wrote: post #305

Earlier quoted context omitted.

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

Work created in 1-2 hours is very different from a work created in 1-2 months.

Yeah, but at this point you're not left with many other options other than sticking your finger in the air and hoping you can detect if they know how to write code.