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

31–40 of 69 posts

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#31

Post by ep103 »

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…

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) Application Tier Developer, and don't expect or really allow much cross between the two.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#32

Post by nostrademons »

ndr wrote: post #11
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…

[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?)

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#33

Post by kenster07 »

I find it curious how so many computer engineers tend to have borderline religious beliefs when it comes to the topic of CS fundamentals.

This is an ineffective way to hire front-end devs, which is the scenario described in the article. In Javascript, there is limited room to implement fundamental algorithms, because many of them have already been implemented in native code, and they will pretty much always outperform a customized Javascript implementation for large n.

When doing front-end dev for a living, you will not be able to keep your fundamental algorithms chops by just doing your job. You have to go out of your way to keep them fresh. As a result, interview questions about fundamental algos for a position like front-end development will be biased in favor of those who are recently took CS algorithms classes, who do not necessarily have any more intrinsic potential as a front-end web dev, and who likely have less work experience.

As a consequence, it would seem that any employer that uses fundamental algorithms as a major factor in hiring front-end devs does not have a realistic conception of what the job actually entails.

And the same argument applies for any programming job where fundamental algos are not coded regularly.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#34

Post by nostrademons »

ep103 wrote: post #31
nostrademons wrote: post #30

Earlier quoted context omitted.

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…

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 actually on my own initiative, either nights-and-weekends side projects or 20% time, although I've had a couple projects at Google where I do backend stuff. Compilers are cool because they're largely self-checking: it's immediately apparent if you don't understand the concepts, because your programs will give wrong answers.

There's a very good reason why the job descriptions are separate: they really are separate skills, and it's fairly rare to be good at both. But not impossible, and there's certainly less of a difference between frontend & backend dev than there is between backend dev & leadership.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#35

Post by gizmo686 »

ndr wrote: post #11
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…

[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.

The lookup time of a binary search tree is also in O(n). Personally, regardless of the algorithm, I prefer to just say that it is in O(Ackermann(n,n)).

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#36

Post by mamcx »

klibertp wrote: post #27
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.

Anecdotal: just last week a CS graduate at my work produced Python code so horrible, that our tech lead refused to comment on it. Have you heard about storing an app's - no, an app part's - settings in a __builtin__ module? And that's a tip of an iceberg in this case :) Well, being a programmer I am able to answer both simple and a bit more complicated CS questions, although I worked hard on my own to be able to as I…

This.

A "simple" thing like the kind of language you used to learn first have a huge impact in how you code or solve problems.

And if, for example, people learn first C, then try to workaround the limitations of it... in python.

I learn first foxpro. And my personal experience is that it give me a huge boost in database/data manipulation than the regular developer. To this day (I do integrations between several ERPs made with different languages and databases) the system that I have meet with people with strong C-like and algorithmic stuff are qualitative worse, by a LOT (take in account, is not normal to meet GREAT GREAT developers, so YMMV), that people that start with DBase languages (yes, DBase/Fox was HUGE in my country ;)).

Is like this. If a person that learn by the CS path have a problem, inside his C/C++/Java:= Amazing. But when the same problem is inside a database engine :=Not amazing.

Is weird! Some folks have tell me I'm a great developer (I know I'm not. I'm very average) because I know SQL! I could figure how solve stuff with Sql/Sql languages naturally, but then... I'm inside C/C++/Java and I lost if need to do a black tree...

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#37

Post by RogerL »

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.

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? So often, no. I think the ability to craft high quality code and to act as a empirically oriented engineer is a somewhat rare skill, and one that is quite orthogonal to proving the correctness of Prim's algorithm, or remembering how to implement Union Find efficiently.

Furthermore, it is not necessary. I have worked with plenty of people that I would work with any day, in any project, that had no real algorithmic chops. Oh, they may know that databases use something like B+ trees, but they'd be hard pressed to describe the data structure, let alone implement an operation on it. But they could, if they needed to. Half an hour with a book, a few experiments, and they'd be off to the races.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#38

Post by LordHumungous »

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…

In college an old physics professor of mine once told me that you don't really know something until you can clearly explain it to other people. And you can't explain things to other people unless you have the basic concepts memorized. I think about that every time people complain that it's not fair for interviewers to ask them to explain basic programming concepts.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#39

Post by zainny »

This exact topic came up yesterday in the HN post "Bullshit Interviews": https://news.ycombinator.com/item?id=6304911 (https://coderwall.com/p/yn9g2a)

I repeat now what I said then: I think there's a very simple rule anyone can and should follow to not fuck up interviews: Don't ask people to do things in the interview you wouldn't expect them to do in the job. Examples:

(1) Do people in this job regularly write code on the whiteboard? Lack access to a search engine? No. Then don't do it in the interview.

(2) Do people in the job design spice racks for blind people? No. Then don't ask them to do this in the interview.

(3) Do people in the job regularly find themselves coding something on the level of fizz buzz? Yes? Go ahead and ask!

(4) Do people in the job regularly find themselves writing code to find loops in a graph? Yes? Go ahead and ask (though, let's be honest - this is exceedingly rare in comparison to how often it is deployed in interviews)

Verify people have the skills they need to do the job you're hiring for. It really is as simple as that.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#40

Post by zainny »

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.
Post reply on HN