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

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

#231

Post by pojzon » Sat, Apr 16, 2022, 7:10 AM UTC

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…

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.

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

#232

Post by jonathanlydall » Sat, Apr 16, 2022, 7:11 AM UTC

pojzon wrote: post #228

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…

This is precicely why only few companies will do this kind of interview. Good candidate would instantly notice the team is being labeled as seniors but instead are a bunch of crappy devs with years of experience. Code does not lie. If you are crap you gonna produce crap code. Ive recently hit such a mine. Lies during interview. Gonna sit here through vacations and jump the ship. Was sold on working with experienced p…

They have 10 years of experience, but unfortunately it's just the same year of experience repeated 10 times.

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

#233

Post by itronitron » Sat, Apr 16, 2022, 7:11 AM UTC

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…

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?

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

#234

Post by cphoover » Sat, Apr 16, 2022, 7:11 AM UTC

pelario wrote: post #225

haspok wrote: post #223

Problem is, reading is at least an order of magnitude easier than writing. In terms of natural languages, if you can read and mostly understand a text in another language, let's say you score 8/10. At the same time it is completely reasonable to expect that you would not be able to write the same text, and if you had to, it would be at 5/10. Then if you had to do it in a speech, you would score a measly 3/10. I'm not…

I suspect you have not read enough code.

In my professional experience there is a lot of poorly writtem, convoluted spaghetti code, that is extremely hard to follow. Im not sure why people seem think reading code is easier than writing code... this is often not the case.

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

#235

Post by chrismarlow9 » Sat, Apr 16, 2022, 7:18 AM UTC

spike021 wrote: post #163

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

100% agreed. A trend I've noticed the past couple years is that people make the excuse of "code should be self-documenting" so they don't need to add comments. But then very helpful contextual hints that are not otherwise documented anywhere, like the one you provided, are completely non-existent and the original dev has left the team, it's been 2-3 or more years since the last time someone touched it, etc. Code shou…

Not disagreeing because I think comments can help solve confusion immediately in clever code. But when I tell people the code should be self documenting it implies there will also be:

some form of git history to go along with it

some single page architecture type of doc. No technical info, just like a README saying what this thing does and some 101, maybe a diagram.

The "doc as part of the code" for me is really just a easy way to generate a "reference" for function signatures and specific code interfacing. And if you start off that way the reference is at least always up to date, because it's caught in review (ideally).

As for updating the README that's just on the dev team to remember.

I will say my opinion changes a bit with huge polyglot mono repositories. In those cases you need great docs and organization.

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

#236

Post by john_the_writer » Sat, Apr 16, 2022, 7:20 AM UTC

morelish wrote: post #222

Yeah I had an interview like this recently. First part of the interview proceeded well as they asked me to read different bits of code and how different language features worked. Then I was asked a brain teaser that I bombed. And that was the end of the interview.

I was once asked how I would sort 1000 bolts.

I said. I have 5 year old twins, I'd give it to them and have them sort it.

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

#237

Post by refactor_master » Sat, Apr 16, 2022, 7:21 AM UTC

itronitron wrote: post #233

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…

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?

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

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

#238

Post by buf » Sat, Apr 16, 2022, 7:22 AM UTC

itronitron wrote: post #233

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…

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.

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

#239

Post by mbeex » Sat, Apr 16, 2022, 7:22 AM UTC

itronitron wrote: post #233

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…

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?

It hasn't to be the 'best' work. The actual value comes from the conversation.

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

#240

Post by jseban » Sat, Apr 16, 2022, 7:22 AM UTC

BFLpL0QNek wrote: post #150

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.

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 are accepted, only some with slight modifications.

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. And if there's disagreement in a review: the resolution of that is completely unknown, and can often blow up to a really nasty conflicts.

I have so many terrible experiences with PR's where you get hostile nonconstructive comments on your work, on github, from a person that literally sits next to you. It's the creepiest thing ever.