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

61–69 of 69 posts

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#61

Post by plinkplonk »

lhnz wrote: post #12

Aside from the main point of this article, could anybody recommend a good algorithms/data structures book? I want something that gives examples of when you should use particular techniques/theory and the benefits and trade-offs of doing so? That is, as opposed to learning the rote implementations and time complexities, I want to understand the practical application of knowledge... I recently looked at some coding tes…

"Aside from the main point of this article, could anybody recommend a good algorithms/data structures book?"

Skiena's "Algorithm Design Manual" or Kleinberg and Tardos's "Algorithm Design" or Sedgewick's "Algorithms" for folks with little/no math. I mildly prefer the last.

Once you have some math under your belt (say worked through Knuth's Concrete Mathematics), Sedgewick's "Analysis of Algorithms" or even Cormen et al. The problem with the latter is that it is too big to work through comprehensively and knowing what to leave out is somewhat tricky.

Speaking of which, has someone ever worked through Cormen comprehensively? I sometimes think I should take two months off from work for a "desert island" holiday and put in the work to do this. (I started once and was making progress but got interrupted and never went back).

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#62

Post by victorf »

philangist wrote: post #52
coolrhymes wrote: post #42

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

Coding noob here. Can someone explain the problem with the `for foo in queryset` implementation? Is it that for loops are inherently inefficient? What would be a better alternative?

I don't see a problem with an O(n) algorithm to set some property on n objects.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#63

Post by DavidWoof »

Did we all read the same article? He complains about "algorithmic interviews", the comments here are about AVL trees and sorting algorithms, but what he was actually asked to write was "a string parsing implementation".

Well, OK, I suppose it's possible they tried to get him to write yacc, but it sounds much more like they asked him to do some trivial loops and tree traversal, at the very most some basic recursive descent parsing.

This ain't rocket science, it's not complex O(n) analysis, it's only slightly above the fizzbuzz level. If you're writing code at all then I think it's reasonable expect you to understand recursion and loops, even if much of the job is just going to be hooking up jquery plugins.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#64

Post by [deleted] »

nostrademons wrote: post #28
JulianMorrison wrote: post #25

I think my answer to the "write a sort" thing would be "are you kidding? I'd use the one in the language's standard library, because I'm not an idiot. Or if I had no choice, and was using a language and environment so primitive it had no libraries at all, I'd write bubble sort because it's easy. Or if it actually mattered I'd go read up on it and learn how."

Oftentimes that's the first answer that the interviewer is looking for (without the attitude). But then they want to see you code a MergeSort or QuickSort up from scratch, and explain the difference between them. Why? Because what happens when your data set exceeds available RAM? Then you can't use the stock libraries, since they're all designed for in-memory datasets. You have to rely on external sort, which is a co…

[deleted]

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#65

Post by mamcx »

timr wrote: post #48
RogerL wrote: post #37

Earlier quoted context omitted.

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

Not only is possible, happens all the time.

Is because the abstraction level of a database engine is different of a core language.

Is possible to build a performant database systems without understand what is a BTree, or how is different from a Black tree or a hash. (I suspect, from my experience, that a lot of DBAs and database-focused developer have not much clue on that low-level stuff).

In fact, is not only possible, but build a good database is the job of the people that build good databases. But how archive that, is different from how build a performant algorithm (is more about how layout the data, how index it, how build the querys, analyzing the plans... but mainly, how layout the data)

In my life I have never ever ever think in the low-level implementation of a index as a key point in how build a database system.

(However, I will be glad in know a example in where this could provide a huge advantage)

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#66

Post by timr »

mamcx wrote: post #65
timr wrote: post #48

Earlier quoted context omitted.

"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 d…

Not only is possible, happens all the time. Is because the abstraction level of a database engine is different of a core language. Is possible to build a performant database systems without understand what is a BTree, or how is different from a Black tree or a hash. (I suspect, from my experience, that a lot of DBAs and database-focused developer have not much clue on that low-level stuff). In fact, is not only possi…

I know it's possible to build a performant system without knowing how it works, it just isn't deterministically likely.

There's also a difference between "building a database", and "using a database". I'm not suggesting that people who write SQL should be able to write a DBMS (though that certainly helps) -- just that they should know, for example, how a B-tree index will most likely perform when joining two large tables. Or how storing a text column is different than a string. And so on.

I've spent a lot of time cleaning up the messes of people who can write SQL -- sometimes, on large, heavily-used systems -- but had absolutely no idea why their multi-way joins were slow, or why doing LIKE queries over a large text column is a performance hit. These are stupid problems that anyone with basic CS knowledge can understand how to avoid.

Aside: this is also the reason why fans of certain trendy technologies (...rhymes with bongo...) are routinely pilloried for making dumb technical decisions. Those who don't understand CS in theory are doomed to learn it in practice.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#67

Post by victorhooi »

victorf wrote: post #62
philangist wrote: post #52

Earlier quoted context omitted.

Coding noob here. Can someone explain the problem with the `for foo in queryset` implementation? Is it that for loops are inherently inefficient? What would be a better alternative?

I don't see a problem with an O(n) algorithm to set some property on n objects.

I think the issue is the call to save() (I assume this is meant to be outside the comma).

Basically, it'll hit the database after each query.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#68

Post by philangist »

victorhooi wrote: post #67
victorf wrote: post #62

Earlier quoted context omitted.

I don't see a problem with an O(n) algorithm to set some property on n objects.

I think the issue is the call to save() (I assume this is meant to be outside the comma). Basically, it'll hit the database after each query.

I originally thought it might be that too, but it seems to me like you'll have to hit the database n times for n queries no matter what. Unless Django has some builtin batch save functionality.

Re: Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

#69

Post by victorhooi »

philangist wrote: post #68
victorhooi wrote: post #67

Earlier quoted context omitted.

I think the issue is the call to save() (I assume this is meant to be outside the comma). Basically, it'll hit the database after each query.

I originally thought it might be that too, but it seems to me like you'll have to hit the database n times for n queries no matter what. Unless Django has some builtin batch save functionality.

Hmm, there's bulk_create(), introduced in Django 1.4, to create multiple new objects in one DB call.

However, I'm not aware of anything that would do the same to update properties.

Post reply on HN