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

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

#501

Post by vmception » Sat, Apr 16, 2022, 6:44 PM UTC

gavinray wrote: post #498

vmception wrote: post #478

Earlier quoted context omitted.

My bet is that it doesn't work. My experience is that they are assuming that, just like those recruiters and hiring managers that look for “an active github” and swear by that

If you can write software, have you never once encountered a bug in something you use or a tiny feature that would have made your life so much easier + just done it yourself? I understand not wanting to do a ton of weekend projects and having other hobbies, but it's wild to me to think that being able to do these sorts of things but never doing it happens. It's sort of like a car mechanic who doesn't fix/tweak his ow…

A car mechanic isn’t evaluated for a job by whether they fix their own car as a successful one may own a luxury car that must be serviced at a specific location.

Since analogies compare dissimilar things with at least one similarity, I think you lost the one similarity and undermined the point you thought you were making

What does a programmer seeing a bug have to do with this conversation? What exactly are you imagining? I’m imagining how silly it would be for me to run a custom version of a chrome extension that wont get any updates just because I didnt like how a feature was implemented, I’m guessing you are imagining something else?

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

#502

Post by mstipetic » Sat, Apr 16, 2022, 6:55 PM UTC

Riverheart wrote: post #485

mstipetic wrote: post #261

Earlier quoted context omitted.

I’ve never understood this. I’ve had Teams grill me on questions I know most of them wouldn’t pass and they themselves said they’re struggling with delivering things. Some weird dick measuring thing

Or they don't have the time or manpower to fix/learn things and are trying their best to hire someone to help right the ship before bringing you onboard. Such a negative take.

Which engineer that is that good would spend years of his time improving a low performing team?

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

#503

Post by ChrisMarshallNY » Sat, Apr 16, 2022, 7:07 PM UTC

weatherlite wrote: post #419

ChrisMarshallNY wrote: post #404

Earlier quoted context omitted.

Yup. We're in a "bubble," right now. It's an industry, where people make pretty sick money, for little experience. In fact, younger folks often make better salaries than older folks. I worked for over 35 years, and never made as much as many kids right out of school, make, at FAANG (or is it now "MAANG"?) companies. I was able to save and invest enough money, though, so that, when I was given the cold shoulder, at 55…

> when I was given the cold shoulder, at 55 Have you tried reaching out to people on your network who worked with you in the past? I think this together with your experience is a very strong asset. Reach out, tell them you want work, you might be pleasantly surprised that your age isn't much of an obstacle.

Nah... I stopped bothering. The whole industry has changed, and the older folks have become just as bad as the younger ones, because they swim in the same river, and have to compete with them. One of the most disturbing interviews I had, was with an engineering lead who was in his sixties, and was extremely hostile. He would have been my boss, if I had pursued it further.

No thanks.

It really was just easier for me to throw in the towel. Like I said, I'm quite fortunate to be in the position that I'm in.

But it isn't work, if you enjoy what you do, and that's where I'm at. I never want to be in a position again, where my work is ignored and/or disrespected. I love to work, and take great pride in the Craft. That is treated as a "quaint anachronism," these days, so I guess I'm on my own.

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

#504

Post by gavinray » Sat, Apr 16, 2022, 7:25 PM UTC

vmception wrote: post #501

gavinray wrote: post #498

Earlier quoted context omitted.

If you can write software, have you never once encountered a bug in something you use or a tiny feature that would have made your life so much easier + just done it yourself? I understand not wanting to do a ton of weekend projects and having other hobbies, but it's wild to me to think that being able to do these sorts of things but never doing it happens. It's sort of like a car mechanic who doesn't fix/tweak his ow…

A car mechanic isn’t evaluated for a job by whether they fix their own car as a successful one may own a luxury car that must be serviced at a specific location. Since analogies compare dissimilar things with at least one similarity, I think you lost the one similarity and undermined the point you thought you were making What does a programmer seeing a bug have to do with this conversation? What exactly are you imagi…

  > What exactly are you imagining?

Submit a PR to whatever tool it is you use that fixes the bug so it stops bothering you

Build some small tool to automate a task that you have in your daily life

Write a program based around one of your hobbies that caters to something niche so there's no good tools for it already

Anything of this sort, I guess.

I do a lot of open-source work but it's selfish -- I submit those PR's because they are things I wanted/needed and it would be silly for me to have a fork and try to keep it up to date with master.

Maybe it's different for other people but I constantly run into bugs/missing features in tools I use for both job and personal stuff. If I didn't do this there would be so much I'd have to hack around or flat-out wouldn't be able to do.

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

#505

Post by jhomedall » Sat, Apr 16, 2022, 7:25 PM UTC

jseban wrote: post #268

lastdong wrote: post #263

Earlier quoted context omitted.

I’m sorry you had such bad experience but you were working with the wrong people (feels like toxic even). PR reviews work best in environment where trust is key, and deciding together (emphasis on together) best approach to reach a goal is the main drive. In the end PRs should make you and the team stronger, as the knowledge is shared collectively. IMO every developer should be an admin of the repo, but more importan…

> I’m sorry you had such bad experience but you were working with the wrong people (feels like toxic even). It's the tool itself and it's imposed workflow of blocking work and gaining absolute power in demanding changes, that causes the working environment to become toxic. Nobody would ever do that in a meeting "I'm blocking this work now until my demands have been met". That would be incredibly hostile, but with thi…

I've worked on several teams that required PRs before merging, and there was never any toxic behavior. Everybody was happy with it.

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

#506

Post by mylons » Sat, Apr 16, 2022, 7:56 PM UTC

wnolens wrote: post #436

mylons wrote: post #90

Earlier quoted context omitted.

the blog author doesn’t take them through the company’s code base. the author creates code for the interview.

Yea a lot of people in this thread missed that point. It's still contrived problems, just testing comprehension rather than creation. But you can contrive much larger problems than you could ever ask a candidate to code, so you escape the ability for a candidate to practice your exact questions to some degree.

i kind of like the idea of taking them through your codebase, though. allowing the interviewer to concoct problems leads to something i'm very passionate about, and that's attempting to stifle the ego involved in the interview process. for whatever reason, intellectual prowess, and displaying it, exposes itself in interviews. the interviewer will ultimately end up trying to dominate you intellectually to satisfy their own ego. it's pretty pathetic, and rampant in whiteboarding.

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

#507

Post by mylons » Sat, Apr 16, 2022, 8:01 PM UTC

jacquesm wrote: post #352

jseban wrote: post #351

Earlier quoted context omitted.

> despite being grilled on it and the level of skill not to great they just want senior people Happens to me too, I get tough interviews, and a good salary, but the work is exactly the same as the juniors "a guy on the scrum team". I don't even understand why they hire seniors, or have that title when it means nothing. I guess they expect them to be just faster versions of juniors.

> I guess they expect them to be just faster versions of juniors. No, they expect them to be: - more independent - able to bring past experience to bear on present problems - make fewer mistakes - be able to help others rise to the next level - possibly make good team leads at a later stage

yes and no. the last company I worked at is a feature factory. They have senior, and staff engineers, on various product teams that have 0 technical influence. What they expected is you to somehow increase quality of the product via code review and writing design documents... but the quality of the product was being destroyed by a handful of people making all of the technical and architectural decisions and forcing their platform on the rest of the org. Upper management doesn't have the technical expertise to see this and thinks this approach will lead to some sort of unified performance and scalability. Maybe it will down the road, but if I can't change out the underlying database, ORM, or web framework for something that is just _better_, I'm ultimately just working on the assembly line at the feature factory as a Sr/Staff engineer.

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

#508

Post by emrah » Sat, Apr 16, 2022, 8:22 PM UTC

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.

Agreed, despite the elephant in the room that when the company is in growth stage, comments rot, documentation rots, things change rather quickly and everything including comments become a liability. I'm not saying they shouldn't be written but they also need maintaining

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

#509

Post by lovich » Sat, Apr 16, 2022, 8:25 PM UTC

hiptobecubic wrote: post #428

ithkuil wrote: post #424

Earlier quoted context omitted.

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.

My places test suite nukes my local development environment for the full integration tests. If I am working on a hairy piece of code I open up a PR and let the CI system farm out the suite to multiple instances so I can get an answer in less than an hour.

The "right" answer is probably to refactor the test suite to be more performant, but that's never going to get approved given the amount of work that would take, and it would take me longer than I plan on being at the company to get it fixed in my spare time.

I do have it passing all tests before I try to merge if that counts?

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

#510

Post by lovich » Sat, Apr 16, 2022, 8:30 PM UTC

jseban wrote: post #275

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…

> Review also shouldn't be causing ego antagonisms. Yeah but the tool itself is antagonistic, because it imposes a workflow of open source, a workflow that also is antagonistic with clear and absolute power. So using that tool suddenly brings that antagonism and power into a team which is supposed to be 100% collaborative, and it also only does it periodically and with random and different people in power. It's not h…

>So using that tool suddenly brings that antagonism and power into a team which is supposed to be 100% collaborative, and it also only does it periodically and with random and different people in power.

Is code review not collaborative in your experience? In every team I've been on/run we've split code review comments between suggestions/questions and actual "I will not let this go into prod if my name is attached to it" blockers. Code review has been 99% the first set of comments and only rarely do I see anyone actually block reviews over things like style and what not that have been mentioned here.

I can't even imagine those topics getting into code review as a blocker as if we have actually strongly held opinions on mechanical issues like that, they are integrated into the various linters used so you don't even need human eyes to catch the issue.