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

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

#371

Post by [deleted] » Sat, Apr 16, 2022, 11:26 AM UTC

jollygoodshow wrote: post #331

throw14082020 wrote: post #290

Earlier quoted context omitted.

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

[deleted]

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

#372

Post by EdwardDiego » Sat, Apr 16, 2022, 11:26 AM UTC

In the past, I've taken existing code that needed a good refactor, checked the unit tests gave a good working/not working signal (i.e., deterministic pass/fail), set up the candidate's preferred IDE/editor, and asked them to refactor it to be better, according to their definition of better.

Then we talked about the things they did and why that was better.

Probably the best "coding exercise" I've ever done in terms of getting to understand how someone approaches a typical code base.

But sometimes candidates were very unsure about how to approach it, they found it hard to proceed without knowing exactly what "better" was.

I stopped using this, as I realised that my approach was unconsciously selecting for a certain type of person, one who resembled myself and it excluded people who could be amazing devs within clear parameters.

TL;DR interviewing is hard to get right, this reading idea is a good one.

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

#373

Post by greymalik » Sat, Apr 16, 2022, 11:28 AM UTC

buf wrote: post #283

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.

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.

> Everyone in this thread seems to be hung up on sharing code from an employer

Probably because you said “Bring code you've written”

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

#374

Post by beardedetim » Sat, Apr 16, 2022, 11:29 AM UTC

jseban wrote: post #264

heurisko wrote: post #251

Earlier quoted context omitted.

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

> Sometimes junior, or less skilled people, have something valuable to say. Especially if the code could be simpler. Yeah and sometimes they are naive, dogmatic and overconfident, and on a crusade to change all the things! because they have read some blog post by uncle bob, and this tool is putting them in absolute power every time they do a review. > In a stalemate, the PR could be sent to a third party. I've sugges…

I've never thought of a PR as causing conflict. For sure, you're right now that you've explained it, but as an engineer I've never felt that way.

But I'm okay with the conflict! There should be conflict at work! Ideas should be freely expressed and those ideas are going to meet contrary ones!

What wouldn't be healthy is a place where that conflict isn't resolved or doesn't lead to a better idea winning. Or where only the Lead "wins" because of their position.

There shouldn't be arguments, no one should yell or be hurt. For sure that's a bad place to work. But conflict about where to place a piece of code? Sure! Conflict about if we name it Foo or Bar? Why not?! That conflict is like the sharpening of Iron! It hurts _today_ but can strengthen and make _you_ better let alone the organization as a whole.

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

#375

Post by jseban » Sat, Apr 16, 2022, 11:30 AM UTC

jahnu wrote: post #272

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…

Last person I hired to work with me in my previous job I walked them through the entire code base, architecture and CI setup. This gave the hire a chance to best understand day to day work and me a chance to know which parts they understood immediately and which they would need to learn. Works perfectly for me.

A for effort!

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

#376

Post by greymalik » Sat, Apr 16, 2022, 11:32 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…

> The one who has more time for side projects might also have more time for work, too

So you’re expecting people to work more than 40 hours a week?

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

#377

Post by jen20 » Sat, Apr 16, 2022, 11:34 AM UTC

jseban wrote: post #356

olliej wrote: post #345

Earlier quoted context omitted.

What tool are you talking about? I've had patch review as back and forth comments in email, in bugzilla, in myriad other bug databases. If you can't send out an email with your patch as an attachment, and get feedback, then we have a problem, and the problem is not the adversarial nature of review.

But why would you use such a remote asynchronous late stage feedback loop, if you are literally sitting in the same room as your collaborators, during the whole development process?

> if you are literally sitting in the same room as your collaborators

Your very premise is wrong. At any sufficiently large company, you are unlikely to be sitting in the same room as every collaborator and stakeholder, or even proxies for them.

As a simple example, the team I currently work on (on one project of several) is 10 people across 8 US cities in all four US mainland timezones, and the stakeholders and collaborators are across Australia, Asia, Europe and the Americas. A good majority of what I do is pair programmed, yet the pull request workflow is essential to letting _others_ know what is happening and why, and to allow them to have asynchronous input into the process.

You might argue it would be better for the team to be in a room somewhere. Maybe so, but the people this project demands live where they live and could not even agree a common location for that room to be if they wanted to. And it still wouldn’t help the other projects…

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

#378

Post by jen20 » Sat, Apr 16, 2022, 11:37 AM UTC

jseban wrote: post #313

actually_a_dog wrote: post #306

Earlier quoted context omitted.

There is nothing about github hat prevents you from working that way. I don't see what your issue is. But, I will say that I don't want people who can't separate criticism of their code from criticism of themselves on my team. You can certainly have whatever feelings you want, as long as it doesn't get in the way of producing the best possible product, all things considered.

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

> nobody can completely separate criticism of their work from criticism of themselves

Yeah I really hate those pesky automated linters running in standardised environments telling me I’ve screwed something up.

(/sarcasm, hopefully clearly!)

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

#379

Post by anyfactor » Sat, Apr 16, 2022, 11:42 AM UTC

jollygoodshow wrote: post #331

throw14082020 wrote: post #290

Earlier quoted context omitted.

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

I just can't understand the worldview differences of some interviewers.

Everyone has a finite amount of time, they have other shit to do. The vast majority people irl just code for work. Are they bad programmers? Of course not.

I would say for the average employer paying an average salary, demanding you to showcase a portfolio of hobby project is plain obnoxious. The interviewer can hope the interviewee does some hobby projects and lives and breathes coding but demanding it as a baseline assessment for an interview is absurd.

For the average programmer when they have absolutely have nothing else to do maybe they will work on their sideprojects which even takes a backseat because they have to keep learning new crap every other week to make sure they are up to date.

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

#380

Post by BlargMcLarg » Sat, Apr 16, 2022, 11:45 AM UTC

beardedetim wrote: post #374

jseban wrote: post #264

Earlier quoted context omitted.

> Sometimes junior, or less skilled people, have something valuable to say. Especially if the code could be simpler. Yeah and sometimes they are naive, dogmatic and overconfident, and on a crusade to change all the things! because they have read some blog post by uncle bob, and this tool is putting them in absolute power every time they do a review. > In a stalemate, the PR could be sent to a third party. I've sugges…

I've never thought of a PR as causing conflict. For sure, you're right now that you've explained it, but as an engineer I've never felt that way. But I'm okay with the conflict! There should be conflict at work! Ideas should be freely expressed and those ideas are going to meet contrary ones! What wouldn't be healthy is a place where that conflict isn't resolved or doesn't lead to a better idea winning. Or where only…

>But conflict about where to place a piece of code? Sure! Conflict about if we name it Foo or Bar? Why not?! That conflict is like the sharpening of Iron!

I dearly hope this is sarcasm. This is about the same level of absurdity as developers taking ages to pick project/file names. I'm not railing against a review's abilities to find bugs and make sure someone else understands. GP is right in pointing out how many fruitless review discussions exist over personal differences in what to call a function name because "I think X sounds better than Y", despite every party involved understanding the code and what it does.

If only linters could solve these trivialities.