Live data from Hacker News

When hiring developers, have the candidate read existing code

freakingrectangle.wordpress.com

511–520 of 565 posts

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

#511

Earlier quoted context omitted.

I explicitly said not to write “why” docs to explain specific value choices, but rather document the context around the setting, and what happens when the value is raised or lowered, and why you might want to do that, so I’m thinking this isn’t a topic you’re grasping very well. You’ll be fairly lonely if you reject working with everyone who’s read Clean Code, and truly alone if you won’t work with anyone who underst…

And I explicitly said sometimes you want to write about the rationale. I didn’t actually realize you were attempting to dictate that that wasn’t allowed. That seems pretty nuts. And I think people who read Clean Code and aren’t dogmatic and condescending about trivial choices like this are pretty fine.

What you want and what is the best way to communicate are not always aligned.

And I'm not dictating anything, or being dogmatic and condescending, but I guess it's easier to think I am if you're trying to have an Internet Argument Moment.

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

#512
post #332

Earlier quoted context omitted.

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

Peer programming is just code review again, except now you're only allowed to write when two people are available.

Indeed.

The point was not that "review" is bad, or should be avoided. But that a Pull-Request is a poor way to do that review. Reviewing is crucial, IMO.

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

#513
post #325

Earlier quoted context omitted.

Who said th ex interviewee must present 'own' code there? The conversation can just as well be around a library, product or system that isn't authored or contributed to, by the interviewee. 'What architecture is used here, and what are the down and upsides in this implementation'. 'What would you do different'. 'Which part do you admire, and what don't you like'. Etc.

Don't you think it is implied? Also why would I voluntarily talk about codebases authored by anyone other than me while having in-depth knowledge about it? Nobody looks under the hood of things that interests them, let alone be critical of it’s design. Talking about product and system design is something that is vastly different than stand-alone codebase. If you as an interviewer are interested about something you ha…

> Nobody looks under the hood of things that interests them, let alone be critical of it’s design.

Do you honestly believe this?

Many people do this. I do this. It's the best way to learn¹. There are repeating Ask-HN threads requesting for "high quality Open Source Software to learn from" for example.

¹Edit: on second thought: probably not the "best" way. Not for me, anyway. Just a good way.

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

#514

Earlier quoted context omitted.

Hmm, and evaluation technique cannot be filled by something One cannot fill an abstract concept like a technique with things Maybe you mean that every evaluation technique will detect that most of the job applicants aren't good at coding? And therefore, all evaluation techniques seem to work? (Although some techniques are a lot better than others) If so, then, yes I agree. That's a good point

Yeah thats my point, but also that none are better than the other They are poor methods of screening or evaluating good candidates for the actual job duties

Ok then I understand :-)

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

#515
post #375
post #272

Earlier quoted context omitted.

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!

Honestly, it’s less stress than trying to divine magic tests that I alone would be the first to invent if they worked :)

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

#516

When hiring developers, fetch a stoic subordinate who is A) good at eye contact and B) able to maintain said eye contact without blinking. Have this subordinate and the candidate participate in a staring contest. This will show a couple of things about the candidate: A) How well they maintain eye contact (very important for communication) and B) How long it takes them to back down from a challenge; this taps into the…

I honestly can't tell if this is satire or an interesting look into an alien (to me) work culture.

Gotta tap into their primal instincts.

I would also sound a fire alarm, to see how they react to working under stress, and measure how much their pupils dilate.

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

#517
post #304

Earlier quoted context omitted.

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.

The point is not necessarily whether it's morally wrong to violate a contractual agreement when the other party is likely to do so. It's that the interview process proposed by the G[...]P may force the candidate to do things that may be illegal to pass the interview. The candidate is of course responsible for their own choices, but the point is that as an interviewer, if you force your candidates to do this, you migh…

> you might short list those who have a tendency to violate contract terms.

An asshole filter https://siderea.dreamwidth.org/1209794.html (maybe you've read already?)

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

#518

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…

This is a "Guess what I'm thinking" question. Non-psychic candidates will struggle with this challenge, so you might find it produces some false negatives. Since you already seem to know so much about debugging slow performing database queries on your particular RDBMS stack, though... what was your thinking in looking to bring on board someone else who duplicates that exact knowledge? Oh, and it'll be a missing index…

The point is to start with something open ended, so the candidate can talk as much as they want on the subject, broadly, and then, based on what they say and what they don't say, I narrow in on particulars:

"Are you aware of any differences in dialect between the SQL of MySQL and the SQL of PostGres?"

It's not like they lost points for the stuff they didn't know, I simply wanted to be sure I understood the limits of their knowledge. We hired this candidate and they turned out to be great. But I hired them knowing exactly how much they knew and how much they did know.

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

#519

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…

I had an interview like this for a senior position, it turned out to be the most enjoyable interview I've ever done. The group lead really showed himself and found out at what point would I stop and say I don't know. There's nothing aggressive about this approach unless you make it that way and finding out if people will start bullshitting or admitting the limits of their knowledge is a massive advantage to someone y…

This is a huge part of it:

"finding out if people will start bullshitting or admitting the limits of their knowledge is a massive advantage to someone you might need to depend on"

One of the best hires I ever made was a former K-12 teacher who had decided to change careers and become a software developer. She went to a bootcamp and then I hired just as she graduated from that bootcamp. When I interviewed her, I very much appreciated how clear she was about what she knew and what she did not know. She felt no need to bluff. And that foreshadowed what our communication was like once I hired her: very straightforward, with no lies or bluffing or indirections or deflections.

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

#520

Earlier quoted context omitted.

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

Submitting a PR runs into the most random etiquette expectations from a gatekeeping project maintainer that arbitrarily chooses to not merge

It requires a lot more effort and back and forth than you are describing and its disingenuous. I’m glad you’ve had a good experience with it though.

Writing an automation tool often has nothing to do with the experience and acumen required for a job, it could be a mouse motion recording to a bash script. It requires pure happenstance or contrived altruism to do it in a worse language for the task just to say “see look what I did” for a future employer

I think this requires more empathy, not in an “emotional intelligence” sense just in the concept of putting yourself in other people’s shoes and imagining what they encounter instead thinking what you encounter is normal

Post reply on HN