Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
1–10 of 69 posts
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#2I strongly believe that for many companies such problems with hiring process start much earlier - in the phase of defining the requirements (competencies). When they don't know precisely what they need (and both "ninja" and "experienced front end dev" are far from being precise), they simply can't succeed in measuring it.
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#3Every now and then, these posts come up on HN people mention how bad the interview process at certain companies is and how it should be changed.
I also work for a company that does these types of interviews. While I wholeheartedly agree that asking these algorithms/data structures or other CS fundamental questions is not perfect, precisely because it may induce quite a bit of false negatives, the engineers who does end up successfully completing the process at my company are very competent ones. So from an anecdotal perspective, the process works fairly well in the fact that it does not produce too many false positives.
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#4I have mixed feelings about algorithmic interview questions. There is the camp that says that you shouldn't memorize something you can look up, but I am of the opinion that having something memorized fundamentally changes the flow of thought.
If you just know the lookup times of various datastructures, your thought process is much less jumbled than someone who must look them up while problem solving.
I'm not suggesting that it's necessary for someone be able to whiteboard an implementation of a red-black tree, but knowing what it is, and its advantages and disadvantages compared to an AVL tree or something is very useful.
As an aside, in a graduate CS class I took (about search engines), the prof asked "What is the lookup time of a balanced binary tree" to various students, two of whom gave wrong answers before she got to me. One said "n lg n" and the other said "n". It was evident that they were basically guessing.
My point is that if you actually understand what a binary tree is, the lookup time of it should be obvious. Same for most other basic datastructures, linked list, hash table, etc. I think asked basic, high-level questions about these are totally fair game.
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#5"My experience gave me the feeling that this was more of an interview assembly line than someone really interested in my relevant skills"
That's exactly what it is...
Effective interviewing is hard, and like most things hard you won't be very good at it without some practice and study.
Asking an algorithm question is relatively easy.
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#6Every now and then, these posts come up on HN people mention how bad the interview process at certain companies is and how it should be changed. I also work for a company that does these types of interviews. While I wholeheartedly agree that asking these algorithms/data structures or other CS fundamental questions is not perfect, precisely because it may induce quite a bit of false negatives, the engineers who does e…
You value what you can judge. (Similarly, you value what you can measure.)
Being able to test the ability of somebody in algorithms to a high ability level is a useful late-stage signal.
I always thought it would be interesting to just ask "What do you want to be interviewed on?" and to tease out their strengths from this. You'd then be able to question away to whatever depth necessary without worrying that they were being forced to dance in another man's frame.
I guess the problem with that would be that the interviewer needs to know the area he is testing an interviewee on in order that he may judge it accurately. The communal ground which is intellectually testing is often the academic experience they (possibly) shared.
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#7Every now and then, these posts come up on HN people mention how bad the interview process at certain companies is and how it should be changed. I also work for a company that does these types of interviews. While I wholeheartedly agree that asking these algorithms/data structures or other CS fundamental questions is not perfect, precisely because it may induce quite a bit of false negatives, the engineers who does e…
There's a broken culture of companies thinking they should only hire the smartest people in the world. Most companies don't need brilliant people, they need competent people who will work great together.
[Disclaimer of bitterness: I'm not one of the smartest people in the world. I get rejected after one to three interviews all the time. The author of the post is right: nobody ever looks at your online code and your resume only gets read once by HR to set up the initial pre-interview.]
Testing for concrete intro-to-CS level drivel may give you a company full of people who spend 30 hours a week doing topcoder or project euler, but... you don't need that (if you do need that, good for you, but most companies don't).
It also tricks the interviewee a bit -- "Oh, they're asking algorithms questions! Maybe this'll be a fun CS research job." [six months into the job] "Uh... all I've done is write SQL and fully library-driven backend website code. Boring."
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#8I have mixed feelings about algorithmic interview questions. There is the camp that says that you shouldn't memorize something you can look up, but I am of the opinion that having something memorized fundamentally changes the flow of thought. If you just know the lookup times of various datastructures, your thought process is much less jumbled than someone who must look them up while problem solving. I'm not suggesti…
If you just know the lookup times of various data structures,
The problem isn't knowing complexity, but rather with expecting someone to code something elaborate from memory while being timed, watched, and judged by a stranger. "Code a Fibonacci heap right now, live, with no references. Begin."
Nobody is arguing you shouldn't know the complexity of everything off the top of your head. You absolutely should [1], but you should also be able to figure it out pretty quickly if you don't know it. That means understanding what lg n means and understand what 2^n means, etc. (Yes, we're agreeing here, I'm just reiterating.)
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#9[deleted]
Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer
#10But algorithm coding is just about personal programming ability.
What if the company is using a non-opensource lib?
I don't know how difficult the string parsing problem is. But interviewer may just unsatisfied about your slow implementation.