Live data from Hacker News

When hiring developers, have the candidate read existing code

freakingrectangle.wordpress.com

151–160 of 565 posts

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

#151

Earlier quoted context omitted.

I find questions like this lack an on-ramp. Either you know or you don't. If you don't it gives you 0 indication of the skills. I once flunked a faang interview because the interviewer mispronounced (or used the correct pronunciation I was unfamiliar with) of "arp protocol" I had no idea of what was being asked and was racking my brain for something I didn't think I had ever used to down every computer in the library…

No, that's not true. If you know anything about C and writing secure code (which I what I was probing for) you know about using malloc(). You know because you have to know something about the internals of memory management. Imagine you just read a 4 byte value off the network, and it's part of a protocol that specifies how many more bytes there are to read. You might (in error, ahem... :-) pass that value to malloc()…

>If you don't know or can't guess because you don't know how malloc() works, then you're not the person I'm looking for.

Yea. It would be that way.

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

#152

Would really like to see one day a post about 'when hiring developers, read their CV and have a technical discussion about their past work in relation to the role required' becoming a thing.

I do that extensively when hiring and it is valuable. But sadly, many people can hold a technical discussion without actually being able to read/write code. I'd like my orchestra to have a lively discussion of music theory, but I still need to hear them play the violin.

My company requires just easy leet code exercises. If you can pass that and you can hold your technical discussions - the stuff you have on your resume is likely true.

If I interview someone it's because I like their past experience and think they are a good fit and/or have growth potential. I just need to know if they're lying and if they fit the team personality wise.

What knowledge do I have to gain in having them do medium & hards besides that they can solve medium & hard exercises, which aren't really applicable day to day?

This is equivalent to fizzbuzz without fizzbuzz. But that's just my opinion and I do not work at a FAANG...

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

#153

Would really like to see one day a post about 'when hiring developers, read their CV and have a technical discussion about their past work in relation to the role required' becoming a thing.

I do that extensively when hiring and it is valuable. But sadly, many people can hold a technical discussion without actually being able to read/write code. I'd like my orchestra to have a lively discussion of music theory, but I still need to hear them play the violin.

I agree, and it comes up in every discussion about interviewing, here and elsewhere: People claiming that the "coding interview" is unnecessary and maybe even demeaning if the candidate presents the right credentials and can talk the talk, and people who know from experience that they are sadly necessary anyway.

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

#154

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…

[deleted]

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

#155

Earlier quoted context omitted.

I'm not anything other than a C tourist, and I see that the man page says it returns either NULL or a "unique pointer value that can later be successfully passed to free()." I'm kind of at a loss about why it can return either of those two things, somebody want to take a shot at explaining it?

Both NULL and a unique pointer value can be safely passed to free() :-). Answers to this question taught me about the candidates taste and understanding of good API design :-). Both NULL and "unique pointer" are correct answers, but all modern implementations only chose to return one of these. My follow-up question is "why ?" :-).

When malloc returns NULL, it's saying that there was some error.

However, IIRC the only malloc error is ENOMEM. It's unclear why malloc(0) would run into that. (If malloc(0) did run into an ENOMEM, then NULL would be required, but the result of malloc(0) need not tell you anything about subsequent calls to *alloc functions. However, there is a possible malloc guarantee to consider.)

There's some interaction with realloc() which may favor NULL or a non-null pointer to 0 bytes, but that's too much work to figure out now.

Suppose that malloc(0) returns a not-NULL value. Is malloc(0) == malloc(0) guaranteed to be false? (I think that it is, which is how ENOMEM can happen.)

So, the "right" answer is probably malloc(0) returns a unique pointer because then the error check is simpler - a NULL return value is always a true error, you don't have to look at size.

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

#156

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…

> demo/quick mob session Are you suggesting that a meeting to review cost is going to be faster than a code review? And any comments will be lost?

And pair programming? No thanks.

I think it you are doing actual code reviews, you are doing something wrong.

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

#157

Earlier quoted context omitted.

You do miss out on the 'sit down and create a project' aspect though. Which shows things like familiarity with project structure, (python specific) virtual environments and paths etc. These are good skills to have when a dev is debugging as they could get tied up for a long time dealing with something as simple as a relative path issue.

The things you mention can easily be standardized in the company, and starting a new project or setting up a dev environment should be automated to the point that you don’t even have to think about it.

>should be automated to the point that you don’t even have to think about it.

heh I like it. I'm going to put you as an intermediate skill level dev.

So these things break and need to be fixed. They also have to be setup by someone. You also need to know when something breaks, can I rule out that it's not a setup issue, a git merge that's broken a path, a user that's pushed a local dev config file accidentally.

In order to be effective, you need to have a feel and justification for the way things are. Getting someone to setup a project correctly should be a quick and easy way to do this.

For example, I've had candidates submit tech tests with code in the top level directory instead of having it in a src or some other sub folder. Which is obviously a red flag.

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

#158

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.

> If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc.

Better yet, turn magic numbers into constant variables whose name becomes the comment. Of course, comments can also provide additional context :)

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

#159

I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.

As an interviewer, you should know what strengths to look for and how to test for those strengths.

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

#160

Earlier quoted context omitted.

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. I'm not sure what Trunk Driven Development is, could you elaborate?

https://trunkbaseddevelopment.com/

Okay now I'm wondering what the alternative is, because this just looks like "development" to me.
Post reply on HN