Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

medium.com

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#41

Post by ep103 »

nostrademons wrote: post #34
ep103 wrote: post #31

Earlier quoted context omitted.

Where do you even look for these types of jobs? I started in algorithms and business logic, and over the years have been expanding through the front end, all the way to photoshop. I can't design worth much scratch, but once a designer gives me a few pictures I'm well skilled from there until we hit database optimization. But most jobs I've worked at and see have two very seperate categories: 1) Front End Developer, 2…

The best place to be if you want to learn both algorithms and frontend webdev is a startup, because they're so short on people that you'll basically have to do everything. All my jobs before Google were startups, and I suspect that if I ever left, all my jobs after would be too. The other important thing I did was to never let people stop me from exploring other stuff on my own. Most of my algorithmic experience was…

Wasn't really looking for a place to learn. And yes, that's why I've largely worked in startup companies. Was just wondering if there was anything else out there I was missing.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#42

Post by coolrhymes »

I don't agree 100% with the author on not asking them algorithmic questions. Its a process on how they go about solving it rather than just the outcome. Maybe for the web developer position, you might not need such type of questions, but for a full stack developer the answer is unequivocally yes.

I made a mistake by hiring someone who knew django [who originally wrote plugins in WP] and the coding was just plain horrible. One such example.

`for foo in queryset: foo.prop = 'i m bar' foo.save() ` Simple things like this, where a good engineer would know because of O(n) nature of the code, the so called programmer didn't.

And then there are guys who fork every possible repo, have blogs about how-tos, etc but really can't code for nuts.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#43

Post by RogerL »

gamegoblin wrote: post #4

I 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…

Yes, and no. ;) These are important things to know. But, they are also easy to know. I don't care too much if somebody doesn't know them, it's just knowledge. All I care is if they can learn and understand it.

I am not always on my A game, but when I interview I basically probe until I find an area where they are not strong or familiar. I don't care too much about the questions they get right (they've already been vetted as to actually knowing the language they claim to know). It's just knowledge. But, when they get to something they don't know, that is when it is interesting, and telling. If they can't give you the time of search on a binary tree, awesome! Awesome because now you can actually measure how they think and take on new info, rather than regurgitate stuff (some people have prodigious memory, and can mirror back almost anything, after all). Ask them how they would figure it out. Ask what the structure of a tree is. Ask for the math for # of leafs vs depth, that sort of thing. Help them out when they get the deer in the headlight look. Once they get an answer, immediately change the question and see if they can derive the answer for that new question (say, switch from binary tree to trie).

In some ways college was hard for me - for whatever reason I didn't internalize a lot of the algorithm stuff until I got to grad school, where I ended up TAing for the grad level algorithms course after awhile.

Of course, a common thought is that the algorithms question are meant to test thinking, not memory. I claim that is hogwash. Most of these classic algorithms were invented by giants in the field, alongside other giants that did not think of the algorithm. And some random person, off the street, is supposed to just re-invent a classic algorithm off the cuff? Right. Chances are great that unless you are Google, if that person actually did do it they'd end up so bored at your company that they'd leave in a few months anyway.

Look for what the candidate doesn't know, give them the info, and see if they can synthesize it and do something with it. Don't try to see if they are CAR Hoare - they aren't, and you don't need to hire him anyway. IMO, of course.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#44

Post by marcosdumay »

nostrademons wrote: post #32
ndr wrote: post #11

Earlier quoted context omitted.

[pedantic] Technically, look up on a balanced binary tree is still O(n) as it says nothing about the ordering. If it was a balanced binary search tree then it would be O(log(n)) which I guess is the answer you gave. [/pedantic] A part from that I totally agree with you on the importance of knowing by heart the implications of some technical choices.

(I upvoted you because you're pedantically correct, but being even more pedantic: if it's not a balanced binary search tree, is "lookup" even a valid operation on it?)

Well, lookup is a valid operation on any dataset.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#45

Post by thedufer »

zainny wrote: post #40
timr wrote: post #13

"Being a great business web developer and being a great algorithm developer are not mutually exclusive, but they are also not interdependent. The type of developer that would perform well at this kind of challenge is potentially a recent graduate, fresh from an algorithms class or one that is more focused on micro-optimizations than the big picture." Oh, good grief. Being able to answer basic algorithmic questions in…

I would argue that, say, a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter (infrastructure, taste, independent thought) precisely because they have zero real world experience.

And you don't immediately give a recent grad a large project with no oversight. You give them time to learn that stuff, and they'll pick it up with experience. But someone who demonstrably cant understand how computers work? That's who you need to avoid.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#46

Post by timr »

nostrademons wrote: post #30
timr wrote: post #20

Earlier quoted context omitted.

I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.

FWIW, I was hired by Google in the depths of the 2009 recession because "You have both solid front-end skills and deep algorithmic knowledge, and that's not a combination we see very often." I work with a number of Ph.D's from top universities who are doing cutting-edge machine-learning and ranking algorithms. Many of them cannot code themselves a UI if their life depended upon it, let alone stay up-to-date with emer…

I believe the core of what you're saying: it's fairly rare to find someone who is algorithmically excellent, and who already knows all of the details of web dev. But I think that's largely a matter of interest and specialization, not capability.

But I stand by my larger point: I wouldn't hire a web dev who wasn't fluent enough in basic CS that they couldn't pass an algorithm interview. They don't need to be able to design machine learning algorithms, but things like basic algorithm analysis are essential.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#47

Post by zainny »

rvivek wrote: post #16

Interviewing process is constant optimization just like every other workflow process in a company. Disclaimer: I run interviewstreet.com which helps companies screen & hire programmers using coding challenges. We have had a substantially HUGE number of developers screened (might not be able to reveal the exact number) through the process and using the data points, here's what we found (btw, this is also constantly op…

I am actually pretty decently ranked on Interviewstreet because I do have a personal interest in algorithmic stuff (I was top in Australia for a little while :)). I used to do your codesprints just for fun.

My feedback to you would be that Interviewstreet is heavily heavily geared towards academic algorithmic questions which the average developer would not have a chance in hell of solving. For example, in order to solve some of your old Hacker Rank questions within the time and memory constraints you pretty much have to know the studied and documented solution you would only ever be exposed to in doing a masters degree in CS. Heck, your problem descriptions were often thin veneers around the exact academic statement of the problem.

Despite the fact that I'm someone who actually does excel at these types of problems, I think they are absolutely the wrong way to hire people and whenever I've seen companies actually use Interviewstreet it makes me cringe - and yes I know companies set their own questions, but you lead by example and so most questions are abysmal.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#48

Post by timr »

RogerL wrote: post #37
timr wrote: post #20

Earlier quoted context omitted.

I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.

Along with other responders to your post, I have dealt with plenty of really smart people that cannot program. I don't mean 'pick up a framework' - learning an API is right up a clever person's alley (I frequently carefully distinguish between clever and smart, and am doing so now). But, can they string together nested logic, design in a way to minimize dependencies, is their code readable, is it testable, and so on?…

"I have dealt with plenty of really smart people that cannot program."

Straw man. You obviously have to make candidates prove that they can code, in addition to knowing algorithms.

That said, you can have the people who know how to use a database, but can't at least explain a B+ tree. That's a combination of laziness and incompetence that shouldn't be tolerated. You can't possibly understand how to build performant database systems if you don't know how they work.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#49

Post by zainny »

timr wrote: post #20
mamcx wrote: post #19

Earlier quoted context omitted.

Why limit a "Stealth Incompetents" to one that is a "web developer"? A person recently graduate from the U. Perfect scores in algorithms and that stuff. Now, is in a company. That make web things. Don't know databases well (if any). Don't know JS. Don't know html5. Don't know CSS3. Don't know django, or ruby, or whatever. But know BIg(O)! Know how do a Black tree!! And that is almost useless in his job! You know what…

I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.

I once worked with an individual with a PhD in Mathematics who wrote some of the most god-awful code you could possibly imagine. In an algorithmic test, he would have bested anybody I can think of.

Intelligence and usefulness at tasks are incredibly complex topics for discussion. If you think you can reliably go from A to B, you're dead wrong. The only reliable metric is, if you want skills A, test for A. If you want skills B, test for B.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#50

Post by thedufer »

The argument about whether to ask algorithmic questions reminds of the "can an airplane on a treadmill take off?" question. There are two sides who arr sure that they're right and the others are wrong, but they're just answering subtly different questions.

In this case, the people against always seem to come back to questioning why you would ask something that's just memorization, while the pro-algorithms side is pushing for questions that candidates wont know the answer to, so they can see how they think.

I am in the second camp, if you cant tell.

Post reply on HN