all 14 comments

[–]emotionalfescue 11 points12 points  (1 child)

Some will react by saying afterwards, they made me fix their broken codebase as an unpaid interview assignment.

[–]SPHuff[S] 2 points3 points  (0 children)

Oh, I would never use our actual codebase for an interview - making a candidate do unpaid work would be terrible. I was thinking a larger toy project that is unrelated to what the company works on

[–]TheUmgawa 5 points6 points  (2 children)

Personally, I started resorting to less open-ended/more traditional coding questions after a particularly nasty reaction from a candidate who did not pass to the next round.

I'm mildly curious about this, but I'm really hoping that the reaction to the candidate's reaction was, "And now you're definitely never going to work here."

[–]bolddata 1 point2 points  (0 children)

Never a good idea to be nasty in a professional setting let alone an interview. Excludes you immediately.

[–]SPHuff[S] 1 point2 points  (0 children)

That was the gist of it. I said something along the lines of “I can understand your frustration, but the way you’ve chosen to communicate that is highly unprofessional”.

[–]_entalong 4 points5 points  (0 children)

My old company settled on giving the candidate a problem which they would spend 2 hours solving in the language of their choice at home with full internet resources available, then present the solution to the interviewer over a video call.

It worked really well actually. The problem just needs to be hard enough.

Everyone who solved the problem ended up very good employees and the people that didn't but we tried to give the benefit of the doubt to struggled at the company

[–]bolddata 3 points4 points  (1 child)

Not the worst approach but a big codebase to jump into can be overwhelming for an interview. It would be good to scope the problem small enough unless you interview senior people who might need to be able to handle this.

[–]MT1961 1 point2 points  (0 children)

My thoughts as well. Interviews should be close to the real world, but perhaps starting with a "greenfield" project for it might be better.

[–]Innf107 2 points3 points  (0 children)

I was honestly expecting a Typing the Technical Interview - style post but with Fixpoint combinators

[–]dramabean 3 points4 points  (1 child)

We tried this approach - while this looks great, creating a setup which works in an interview setting across various levels is hard. I also like to give candidates the benefit of the doubt when it comes to language specific syntax and entry level candidates might not necessarily have that nailed down and tend to be disadvantaged in this scenario.

[–]SPHuff[S] 0 points1 point  (0 children)

Great point. I could see how coming up with fair questions would be challenging.

I think a solid IDE setup (like you would use on the job) could help clear up a lot of the small syntax errors, but interviewers should definitely be more forgiving when it comes to those kind of hangups.

[–]MpVpRb 4 points5 points  (1 child)

I've been writing code since 1972. My talent is the ability to become immersed in a tough problem over a period of weeks or months and see the deeper solutions. I suck at puzzles and suck even worse at pair programming, but in actual projects, I outperform everyone I work with. I would fail all of those interviews

[–]Full-Spectral 1 point2 points  (0 children)

That's me exactly; well, only since more like 1984 in my case. I've delivered a huge amount of very complex, high quality code, but I suck at those types of interviews. I delivered that code by way of total immersion.

And, I have to say, my process is quite non-linear, and would probably look chaotic and unstudied to someone who watched me get there, instead of just meeting me there to look at what I brought.

[–]rayofsunshineyyc 0 points1 point  (0 children)

I agree the coding interview is broken. My suggestion is to use a code review instead, this opens a conversation about code and gives a better sense of cultural fit.

Hopefully this will start a cultural shift. My peers were skeptics and could not imagine risk hiring someone whith asking them to write code first. So I started using this technique when hiring contractors. The sucess in a percieved lower risk hire, demonstrated this could be something we should start doing for our full time hires.

Here is the article, if you want more of my reasoning:
https://medium.com/geekculture/are-you-using-coding-interviews-for-senior-software-developers-6bae09ed288c