Lessons from 3,000 technical interviews

Re:Lessons from 3,000 technical interviews by ktRolster on Wednesday December 28, 2016 @05:49PM (#13274351)

I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems. If you have trouble with those, I'm going to really wonder if your programming skills are really very good to begin with.

[ Parent | on HN ]

Re:Lessons from 3,000 technical interviews by ubernostrum on Wednesday December 28, 2016 @06:03PM (#13274438)

Those are bad examples, but real interview questions tend to be "implement from scratch, live and without reference to any materials, these things you've forgotten about because you could take them for granted for such a long time".

Also these days the trendy interview problem is longest common subsequence, which ends up testing "how recently did you review dynamic-programming techniques", not "can you code".

[ Parent | on HN ]

Re:Lessons from 3,000 technical interviews by richmarr on Wednesday December 28, 2016 @06:34PM (#13274620)

> I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems

I'll be honest, this is indistinguishable from "I am good at X and I'm great therefore X is a good measure of ability".

Maybe worth rephrasing

[ Parent | on HN ]

Re:Lessons from 3,000 technical interviews by graffic on Wednesday December 28, 2016 @08:12PM (#13275025)

They're not particularly difficult. You usually take the algorithm definition and implement one, as you did in the university or in the Coursera algorithms course. Fun, you might learn a thing or two about the language you're using.

If the point of the exercise is a TRIVIA question, leave the interview. On the other hand, if the point of the exercise is not to get the right solution but see how you think and how you use basic programming blocks, then you're in the right place.

I've used the linked list question. And the goal is not for me to check if it is "not difficult" for you. Because I might not be able to teach you what a linked list is in 5 minutes while you're nervous in a technical interview. But to work on technical problems and see the following:

- Can you speak your mind so your peers know what are you doing?

- Will you ask for help?

- Will you accept help and feedback?

- Can we have a discussion about something that there are many "right answers"?

- Do you know the basic building blocks of the language you decided to use? <-- This plus javascript plus references is very funny.

[ Parent | on HN ]

Re:Lessons from 3,000 technical interviews by richmarr on Thursday December 29, 2016 @05:04AM (#13276551)

You refer to the interviewers as 'peers' but that's very much not the relationship that exists in an interviewer. The context is different, therefore the behaviour is different.

What you're describing is a confidence bias filter, dressed as an objective test.

[ Parent | on HN ]

Re:Lessons from 3,000 technical interviews by Terr_ on Thursday December 29, 2016 @03:58AM (#13276376)

Individually, with minor refreshing-study, perhaps no.

But in practice it's merely one of hundreds of things that might get instantly sprung on you as you stand before a whiteboard. In addition, developers with actual jobs can't stay in a continuous cycle of "exam cram" to the same extent that unemployed recent graduates can.

[ Parent | on HN ]

Re:Lessons from 3,000 technical interviews by Apocryphon on Wednesday December 28, 2016 @06:47PM (#13274676)

Traversing is a linked list is far simpler than implementing a B-tree.

[ Parent | on HN ]