Interview Questions (was: Brainbench)

[Avishalom Shalit]

ok now that the subject line has changed to reflect the interview process,
here is what i think the ideal interview is (experienced this both as
interviewee and as hiring manager.)

it should be a very short internship,
i.e. here is a masked part of a problem we are working on, lets discuss
this for a bit, then i'll let you work on this 2 hours and we'll meet again
to discuss.

when I interviewed (for another company some time ago) the entire algo team
showed up for the post work review, and this happened twice, it was a 7
hour day. (~3.5 hours per problem)

when i interviewed , i started with a homework question and then discussed
it in the interview. (and asked followups)
nothing like seeing someone do actual work, while looking over his shoulder
on an actual computer.
here, this is the entry
point, have a look. http://upstream.shalit.name/
-- vish




On 5 September 2012 23:12, Joel Bernstein <joel at fysh.org> wrote:

> On 5 September 2012 23:15, Daniel Perrett <perrettdl at googlemail.com>
> wrote:
> > The fib(n) task as stated tests three things of the candidate
>
> You're missing a key point of interviewing. The task is used to test
> how the candidate thinks, how they ask questions, how they explore a
> problem space etc. It has to be discussed and interpreted - simply
> marking an emailed submission of code to solve fib(n) would be
> unhelpful.
>
> As an interviewer your job is to measure their abilities/deficits with
> regard to understanding and exploring new subjects, at least as they
> relate to the kind of work you'll be asking them to do. It's not even
> just about assuring yourself that they're capable of doing the job,
> you need to be sure it's a job that will satisfy and interest them.
> I've never set anybody the fib() test but I find it very enlightening
> to work through a programming task with a prospective candidate.
>
> Really I find interviews are less about individual questions or tasks,
> and more about where the conversation goes based on them, and the
> interviewer's abilities to steer the conversation and to assess the
> candidate based on those discussions. Which is one reason why
> pre-interview screening tests for developers only go so far. It is
> arguable of course that my methods may select for more articulate
> programmers but I do try to ensure that the interviews are relaxed and
> friendly. If a capable engineer can't communicate in those
> circumstances there's always a doubt about how much they will be able
> to offer in a team anyway.
>
> /joel
>