Can you give some examples where you hid road blocks because of your lack of education?
In that sense, asking a developer about how to balance a binary tree, is a dumb interview question.
He should only know, if he happened to have worked on exactly that type of problem, only yesterday or so.
The question is rather: If the following is the description of the algorithm to balance binary trees, show that you understand it by dealing with the details in the following examples.
The dirty secret is 90% of what happens in the real world (and on HN) is a solved problem that needs to be applied or re-applied. Someone has done it before and they've done it better than you will.
The former is a healthy and pragmatic use of your most valuable resource -- time. The latter is a cop-out. If no one actually understands what is going on at a deep level in the library, the result is likely to be an over-engineered mess. It might be that you're doing the most efficacious and appropriate thing for the task, but it might not. And with many such decisions made over the course of a project, some of them are bound to be wrong unless someone can reason about them and explain their purpose.
I find this is most important when refactoring or updating code. Some junior engineer down the line will encounter some code he doesn't understand, and track down the guy who wrote it, and at this point there is a world of difference between that guy saying, "Yeah, we needed a data structure that does X and Y so we used that library," and "Uhhh, not sure why we used that library, does anything break if you remove it?"
Stuff like "Oh hey, this problem fits a state machine approach" and "I can reduce the complexity of this sprawling if statement by making a truth table and minifying stuff"
And the good old "What you're asking for maps onto so and so problem and is fundamentally unsolvable. Can we tweak the requirements?"
Sure, you're not inverting binary trees every day, but it's useful to be able to see where a binary tree would help you solve the problem.
Just being able to look at a problem and go "hey, this is pretty simple graph traversal, I know the rules for this" has saved my bacon. Or the type theory that I picked up along the way that made type-heavy programming in Scala and Rust make sense. Or the set theory (math, but required for my CS degree, so I count it) that does bounce through my brain when I'm thinking about databases. Or even, like--"hmm, I think I can bang out a quick and dirty parser," and knowing what that parser should look like because I've studied how programming languages work and I get that for free.
I'm not the best programmer ever to walk the earth by a long shot, but I'm pretty good, and I'm pretty good because I can approach problems both bottom-up and top-down. Couldn't do both, flexibly, without a strong academic background.
Not a veteran, but I've noticed something very odd about entry level jobs - they're not challenging. And that is no accident someone hiring you is actually doing that with a clear expectation that the complexity you're about to encounter will fit into their schedules.
Higher education is very different - the professors are intentionally trying to push you, hopefully bit-by-bit out of the existing skill range into unknowns. At least mine weren't trying to teach me, they were trying to get me to learn, mostly by making my own stupid mistakes without a huge penalty attached to it.
When I moved out of my CS course (and my open-source work building compilers) into my first job, the skill required to do my job satisfactorily was trivial.
No more hard problems, just hard timelines.
Took a couple of years and changing jobs before again landing up with a problem I didn't know how to solve ("Uh, make PHP5 fast ... Go!"), which helped me grow and learn.
That was a lucky break, but I succeeded because my professors had pushed me into the deep end against my wishes (i.e more sleep) before.
At a certain point I was working on an iOS app attempting to do some really advanced animations with Core Animation/Core Graphics and my total lack of geometry and basic algebra knowledge started to show. One of my colleagues started talking about the movement of an animation in terms of radians and pi and I felt completely lost. He was speaking a totally different language to me. Up to that point I had felt somehow "proud" of being a self taught developer with no formal schooling. But when that happened I just felt completely embarrassed at my lack of fundamental knowledge and context. Now I'm struggling through undergrad mathematics classes and hoping to get to that point some day. The greatest overall takeaway I had from that experience is that math and science open a completely different world to you that most people don't even know exists. It changed my life.
I mean Facebook started out as a cookie cutter app. Heck, it was a basic CRUD app. Look at where it is today.
Outside of such unicorns there are also many examples of reasonably successful products that can be categorized as cookie-cutter. Basecamp. Trello. Snapchat. These apps don't do anything groundbreaking or operate on the bleeding edge of technology. But they are well-known and profitable.
I mean, it's great you're working on the latest computer vision algo to make the billboards in Minority Report a reality. I just spent the day wrestling with Google's client API registration and authentication nonsense so I could get per-page bounce rates.
That's why I own copies of Knuth, and Sedgewick, and Cormen, Leiserson, Rivest, and Stein.
Now, the ability to understand and make intelligent use of those resources is something that requires education (formal or self). But oddly no one (that I've heard of) ever tests for that ability in job interviews.
I wouldn't say that you don't need it, but I would say that most companies ask about the wrong bits.
If you want to sort a list, balance a tree, multiply a matrix or find the shortest/cheapest path in a graph, you should use a library that already does that and is reasonably tested and optimized, certainly more than whatever you'd write today. Most likely you shouldn't even get to choose which algorithm to use for that, and if you need to then the choice should be based not on the O() measures you might remember but on benchmarking, since the constant factor often dominates.
I have seen quite a few very large systems in which the most complicated algorithm actually implemented in the system is a set of branching if-then conditionals for some business logic. There's no custom data structure traversal - yes, it needs some data processed, but all the algorithms for that are in the DB implementation and "do X for all selected items" is literally the deepest level of iteration anywhere in the system. There's cryptography, but that's in a separate library made by someone else. There's network algorithms with state in them, but that's managed by a separate layer.
In such data processing systems all the development does is glue code that specifies what exactly should be done, but all the how part (e.g. the algorithms) is already implemented by someone else and is reused.
There are fields and apps (parts of them) that are algorithm-heavy; for example, even simple games tend to pack a lot of interesting algorithms (but even there much of that is now handled by standard libraries/frameworks). But most developers don't work on that, the majority of software dev work is cookie-cutter data processing apps where all the algorithms are out of your scope.
Those interview questions aren't about "algorithms", they are about details of specific ones chosen by their complexity and that are rarely used in practice.
[1]: http://www.seattletimes.com/business/boeing-aerospace/dramat...
Somebody needs to know how to implement sorting algorithms too. It's just highly unlikely to be you.
If you want to have an engine with 60s power, weight and fuel economy, then sure you don't need to know the science behind it. Just throw some parts together, and you'll get something that works.
If you look something up and the interviewer asks you what the O() of your approach is and you don't know, how can they feel assured you grasp these fundamentals?
I understand why these are contentious, but I find people tend to miss the forest for the trees when criticizing the practice.
It isn't irrelevant if you are attempting to implement it correctly.
> If you look something up and the interviewer asks you what the O() of your approach is and you don't know, how can they feel assured you grasp these fundamentals?
That wasn't the original question in the comment I responded to and your attempt to re-phrase it as X when it was a question related to a specific algorithm is disingenuous.
> Why would an iOS developer need to able to balance a binary tree?
---
<removed a bunch of RL-related stuff that is pointless bitching about ppl we've fired>
Exactly my point. Rarely is there one "correct" implementation. Understanding the choice you make and can support is the point of coding interviews. That's why they're so often done in pseudocode and/or on the whiteboard.
If you can look stuff up you're not demonstrating a knowledge of the fundamentals. If you don't understand complexity and optimization, you will make mistakes even if you can look stuff up later.
That's why these companies do these.
For any given problem asked in such interviews there is certainly one correct implementation and if you believe otherwise you are not providing sufficient information to answer such a question.
> Understanding the choice you make and can support is the point of coding interviews. That's why they're so often done in pseudocode and/or on the whiteboard. > If you can look stuff up you're not demonstrating a knowledge of the fundamentals. If you don't understand complexity and optimization, you will make mistakes even if you can look stuff up later. > That's why these companies do these.
Honestly? This is part of the rant I was trying to avoid.
1) I've met developers that claim SHA-1 is a secure choice in 2017 and make other facepalm worthy claims that 5 minutes of research would have told them was a bad idea.
2) We've fired quite a few people who believe as you do precisely because they are so convinced they understand the fundamentals they don't look things up and make costly mistakes.
3) I've met accountants who can't correctly handle a 4-4-5 calendar that is integral to their jobs without looking things up. Similarly, I've met ones like you that genuinely believe they've memorized the "fundamentals" and repeatedly failed waste thousands of dollars.
4) I honestly believe anyone who refuses to look things up to double check is fundamentally incompetent. We all make mistakes and the only way to appropriately minimize them is to double check (i.e look things up) before hand and have someone else review it afterward.
5) I genuinely do not want to work with anyone who does not do #4. Ever. The sheer number of times they've attempted to shift blame onto other people before they were fired is simply not worth the hassle.
As to your assertion that there is one "true algorithm," the merits of that stand for itself, but regardless being able to explain WHY is what an interviewer should look for.
"Go Google and implement some algorithm" does not provide a useful metric other than "can use a computer."
All of this also ignores a more pressing issue: that looking something up often means getting bad results. Can the applicant draw on knowledge of complexity to distill their Google search? Without that types of test your answer is "hopefully."
That's why Google, FB, etc start with whiteboard tests. Anyone can search and implement.
It isn't difficult to structure a complex question that requires research and have the answer you claim is impossible to find.
> That's why Google, FB, etc start with whiteboard tests. Anyone can search and implement.
I'm sure that is what you believe but that doesn't make it true.
> 2) and 4) and 5) are strawmen. It is -in fact- possible to understand the fundamentals and look things up.
I've never met an engineer (or any professional implementing complex processes) who simultaneously grasped the fundamentals of all areas where they needed to possess competence from memory. (Yes, that includes myself in case you are wondering.)
An answer? Sure. THE answer? No. Too much subjective reasoning in that; something that performs well with clock time may be far worse in some other metric. It always depends. You need to be able to explain it, and that's what complexity is about. Fundamental comprehension of the tradeoffs of approaches.
> I'm sure that is what you believe but that doesn't make it true.
Great. Same with you. Unfortunately, those companies agree with me and do fairly well filtering candidates.
> I've never met an engineer (or any professional implementing complex processes) who simultaneously grasped the fundamentals of all areas where they needed to possess competence from memory.
Me neither. But then again that's not what we're talking about.