Organizational Skills Beat Algorithmic Wizardry
prog21.dadgum.com
prog21.dadgum.com
For example, I'm writing a pure JS database (https://github.com/louischatriot/nedb), and using indexing I was able to speed it up hundreds fold. That's clearly not something I could have done without knowing about self-balancing binary search trees.
I also think that knowing algorithms does make you a better programmer, even if you don't use them on a daily basis.
The first ones needs to be fluent in every types of algorithms and data structure. The other type will have the task of modeling real world processes into a computer (which means "concept organization translation" rather than pure algorithms).
The first ones deal with primitive types, and very rarely more than that. The second ones need to model all the entities of a real life problem and their complex interactions (complex in the sense of combinations and organization).
That's why I think there will always be a gap between those two developers. They are dealing with very different kind of tasks, yet their jobs titles are the same.
The distinction is real, in that many programmers never do build basic tools, while it is artificial in the sense that there is no reason for this other than lack of skill and organizational culture that says that that is not something you are supposed to do.
Actual the second group is occasionally saying, "WTF was the first group thinking?" after spending hours trying to get the tools to work for the real world. (Try spending a few hours/days writing wrappers for PKI software with shitty APIs...)
http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...
"If you don't know how compilers work, then you don't know how computers work."
Becoming better at the first class of programming that you describe, will also make you better at the second class.
And a lot of times, "modeling the world" is a pitfall of object-oriented programming, and something that you don't really want to do. But it's very tempting if you've only ever programmed in Java.
Where exactly is the distinction? How would you classify Monodevelop, or git/svn, or the C++ STL, or SQLite, or Emacs, or the Unix shell utilities, or Photoshop?
IMO this helps at the most very basic level because it lets us consider "hey, I wonder if there's an algorithm out there that'd help me with this" and gives you the impetus you need to go looking.
Kind of a "you know what you don't know" situation of sorts.
If you're solving problems that require algorithmic ingenuity, you absolutely want these people. And if you can pair them with a good engineer who can integrate their algorithm into a non-trivial system, that's when the magic happens.
That said, I've worked with a few people who got both sides very well and they were a treasure to work with.
I can reduce that 20 line function into one line of maps / filters / reduces too, but I know I shouldn't if it's going to take 20 minutes for someone else (or me 6 months later) to get through it.
Basically, don't aim to reduce Kolmogorov complexity, aim to increase readability. These two aren't completely mutually exclusive anyway.
This is a great point. As an industry, we seem to be impressed by complex solutions (even if the complexity is unnecessary and the code unmaintainable). Writing clean, obvious code is often met with a "Duh, I see why it was written that way", but without understanding that it took a long time to get the complex solution down to that point.
Very well put.
I have to object to "20 line function into one line of maps / filters / reduces". I don't know what the 20-line function looks like, but I find use of classic higher order functions instead of loops makes code drastically quicker to read accurately.
As with human language, a larger vocabulary can be used in an "overly smartypants" way, but it can also be used to more quickly and robustly convey information between people (or to your future self).
If you haven't read the literature and do not practice with the different techniques, you are probably not writing clean code.
Good to see a realization by Google that those puzzles aren't all that useful: http://qz.com/96206/google-admits-those-infamous-brainteaser...
Google might be one company where algorithmic wizardry might be expected to be more important than most, so that's saying something...
However writing off in-depth knowledge of algorithms as esoteric or a waste of time is disingenuous in my opinion. I've seen lots of coders write over-engineered, far too complex code, but they were usually not great at algorithms.
Studying up for a Google interview was a transforming experience for me as a programmer - I realized how much I was missing and how little I'd let myself forget the basics since college. It made me a much better coder and made it much easier for me to learn new languages and systems. Understanding CS fundamentals gives you a great platform to work off, and understanding the complex issues makes you a better coder for the day to day stuff.
I asks how would you implement a b-tree index (for example). The right answer is -- "I wouldn't. DB vendors put years into getting this right.".
If you want this sort of gimmick to stop, when you are in an interview, you should just have the balls to ask how it is relevant to your potential job. Their response will give you a good idea if you really want to work there.
As an interviewer, you litmus-tests on questions like this is that they should be (a) answerable by all your existing employees and (b) reveal the thought process of the applicant. If they don't do that, find some better questions.
I consider the trick questions from Google interviewers to be hostile. The only reason not to call them on it in the interview is that you want the job and think that you can get it by being nice rather than honest.
"having balls" != "hostile". "having balls" == "telling the truth"
The point I was trying to make in an interviewer is that you really want to find out what someone is going to do when you ask them to do something that they think is stupid. Because you will eventually.
As an interviewee, you really want to find out what happens if you have to challenge the management.
You can be both honest and nice. It is just harder than trying to answer the question directly.
After a phone screen we ask candidates to complete two problems at home at their leisure. One is a simple filesystem traversal problem where we ask you to build in some runtime extensibility, and the other is a binary space partitioning problem (2D bounding box query) with a very difficult performance requirement (low 10's of ms max for 1M records).
All of our interviews are conducted by more senior software developers. Before we ever interview you we read through your code. These aren't huge tasks, but they're enough to show whether or not you use good organization. Then comes the interview...
We do use the first problem as sort of a litmus test. We figure that runtime instantiation of an arbitrary class which implements a known interface is a little on the edge of the realm of what you'll be doing day-to-day, but it's close enough that if given the problem to take home you should know how to Google the right runtime API calls to make it happen. And we're pretty flexible. If you misunderstood the extensibility requirement and when asked how you'd make it "runtime extensible" you can spit out something marginally close to "MyInterface blarg = (MyInterface)Class.forName(pluginFQDN).newInstance()," or even "I'd Google 'instantiate class by name in Java'" you're still doing more or less fine. You're doing very well if you can tell me how to add the plugin to your tool in such a way that it doesn't leak implementation details to the user either through its use or its installation procedure.
We absolutely do not use the second problem in anything close to a pass/fail manner. If you get the optimal solution, awesome. If not, no problem. Either way, let's talk about it. Let's work together. Let's have an in depth technical discussion about the various pros and cons of different techniques to solving this problem. If I say something which in the context of our discussion is by common-sense reasoning obviously wrong, will you call me out on it (preferably politely)? If I say something that you don't understand will you just nod and smile, or will you say "wait, what?" Or the single biggest problem I see surprisingly often - are you capable of in some way communicating a semi-complex idea to another person who is "skilled in the art," either verbally, on the whiteboard, or otherwise? These are the things we're evaluating on the second problem, not if you can pull a kd/quad/r/other-tree out of your ass.
For something that's purely procedural in nature, asking for a complete and proper object oriented solution would not be such a good idea. Likewise, forcing the candidate to use pure procedural method for something that definitely needs OOP.
I'm not sure I follow that last statement 100%, but if you "go against the grain" all we'd care about is that you're able to reasonably articulate the "why" behind your decisions.
A separate thread (https://news.ycombinator.com/item?id=5911017) discusses Google giving up on some of the insanity. In the original NY Times (http://mobile.nytimes.com/2013/06/20/business/in-head-huntin...) article, Question 3 covers doing away with brainteasers.
Then why don't you just do it? And you forget once for all about these algorithmic interviews and show your other more job-relevant skills.
There are times when a new algorithm (or actually a new data structure) will revolutionise the system. But taking advantage of that is an effort of reorganisaing the code.
Or given the same codebase have them add a feature and some form of testing.
There are many ways to simulate in a highly compressed manner the typical tasks of a programmer without resorting to algorithmic puzzles.
Often, you aren't supposed to write a big thing at once, but you are given some partially working code, with some incomplete set of test cases. You then have to finish the implementation, and you are also encouraged to add more test cases.
I found it especially interesting that the test cases were incomplete on purpose - you are supposed to understand and solve the given task, not just to blindly write some code that happens to pass a given set of tests.
It doesn't mean you shouldn't assess the candidate's technical skills.
Another way of looking at it is that "finding the right word" often means find the good "fit" between abstract concepts shapes or feelings, and a construct of known language items. That's precisely what you're doing as a developer.
But it is an assumption indeed... Only it is based on my personnal experience.
As for the comment mentionning google developpers, the ones i see are good enough verbally to talk about their jobs at google i/o.
See https://news.ycombinator.com/item?id=5911235
Mathematicians perform very well on programming contests, but they are usually terrible software engineers.
Anyways, I was just kidding :)
The former (e.g. a data scientist) will be good solving a problem but bad building a big architecture. The latter, the other way around.
I guess the question is which kind of programmer you are and which skills to look for.
But when i do, it's in front of computer, and i'm sitting right next to the candidate while he taps, to see his line of reasoning. Then, if he's in trouble, we talk about it, i give him hints, and see if he understand what i'm saying and fix the code.