3 ms·

Not saying this approach was correct, but given a choice, what type of interview would you prefer? Hackerrank? In person, programming challenges, smaller take-h

Not saying this approach was correct, but given a choice, what type of interview would you prefer? Hackerrank? In person, programming challenges, smaller take-home assignment, other?

TallGuyShort 7y ago
As both an interviewer and interviewee I prefer in-person. Where you simply meet 1:1 with a few people - some talk to you about fit / experiences and some sit and work with you on a problem. Ideally, you would do the second in a work environment you're used to on a real computer instead of a whiteboard, and I haven't had a chance to do that before. I've seen a few poor performers slip through this before, but I do feel it gives a lot more room for people who just misinterpret what you're going for initially because there's more room for immediate feedback [1]. I've also had some disastrous experiences working with people who were amazing coders but were terrible and sitting down and talking through a problem with someone - I'd rather have a mediocre coder I can talk to. It gives the interviewee a finite time bound, and the company is spending equal manpower resources of their own (instead of giving you a 5-hour problem that you might secretly spend more on, when maybe they already are leaning towards a no but wanted to give you a final chance before ghosting). The downside here is it depends a lot on the consistency and skill of the interviewers, but I believe with good culture and training you can make most people good at this. [1] edit: Also, I think you can tell a lot about how qualified someone is by how they clarify the problem and how they communicate their thinking - not just the code they arrive at.
dbancajas 7y ago
actually talking to the interviewee and getting a sense of what he's accomplished. it depends / person so it's not cookie cutter case.
gcheong 7y ago
I prefer a small take-home project with a follow-up meeting to go over it. The follow-up meeting to discuss the project is crucial though, as I get to asses if I think the critique of the code is reasonable and I can make more in depth comments about the project (what was good, bad, areas I might improve if I had more time, etc) not the typical thumbs up/down with no clue as to why that is typical of companies these days.
wycy 7y ago
A very small-scale assignment with a work/difficulty level on the order of magnitude of an Advent of Code single day challenge seems reasonable. And a follow-up discussion afterwards is crucial to ensuring that the interviewer has put an appropriate amount of effort into actually reviewing the interviewee's code so that it wasn't all just a waste of time.

Not saying this approach was correct, but given a choice, what type of interview would you prefer? Hackerrank? In person, programming challenges, smaller take-home assignment, other?

TallGuyShort 7y ago

As both an interviewer and interviewee I prefer in-person. Where you simply meet 1:1 with a few people - some talk to you about fit / experiences and some sit and work with you on a problem. Ideally, you would do the second in a work environment you're used to on a real computer instead of a whiteboard, and I haven't had a chance to do that before. I've seen a few poor performers slip through this before, but I do feel it gives a lot more room for people who just misinterpret what you're going for initially because there's more room for immediate feedback [1]. I've also had some disastrous experiences working with people who were amazing coders but were terrible and sitting down and talking through a problem with someone - I'd rather have a mediocre coder I can talk to. It gives the interviewee a finite time bound, and the company is spending equal manpower resources of their own (instead of giving you a 5-hour problem that you might secretly spend more on, when maybe they already are leaning towards a no but wanted to give you a final chance before ghosting). The downside here is it depends a lot on the consistency and skill of the interviewers, but I believe with good culture and training you can make most people good at this. [1] edit: Also, I think you can tell a lot about how qualified someone is by how they clarify the problem and how they communicate their thinking - not just the code they arrive at.

dbancajas 7y ago

actually talking to the interviewee and getting a sense of what he's accomplished. it depends / person so it's not cookie cutter case.

gcheong 7y ago

I prefer a small take-home project with a follow-up meeting to go over it. The follow-up meeting to discuss the project is crucial though, as I get to asses if I think the critique of the code is reasonable and I can make more in depth comments about the project (what was good, bad, areas I might improve if I had more time, etc) not the typical thumbs up/down with no clue as to why that is typical of companies these days.

wycy 7y ago

A very small-scale assignment with a work/difficulty level on the order of magnitude of an Advent of Code single day challenge seems reasonable. And a follow-up discussion afterwards is crucial to ensuring that the interviewer has put an appropriate amount of effort into actually reviewing the interviewee's code so that it wasn't all just a waste of time.