I once stumbled upon a problem at work that, after some thinking, I realized could be modeled as a graph problem and solved by performing a topological sort. It was a good and elegant solution to the problem. But what if it hadn't landed on my plate, and instead on someone who didn't know a thing about graphs? The problem might not have been solved (which would mean great pain for our customers, since it was on a feature that customers directly interfaced with), or worse, someone else might have turned up with a horribly messy, spaghetti-like solution.
So I think companies should actually hire people who know their CS fundamentals, even if 80% of the time they'll be doing trivial work that someone less qualified could do. What matters though is having people that are ready for the hairy stuff when it comes up.
I have an education in engineering and I am entirely self-taught on the software side. I think the most valuable thing is learning and exposing yourself to as many ideas as possible. Once you know what "boxes to look in" constructing search terms and finding answers isn't that difficult.
The dirty stuff ends up being most of the work and is what counts for the most in the end product. Companies should be hiring on the ability to take care of the dirty tweaking and tuning. But this experience is something that can only be seen in past projects and that's too much work for a hiring manger to be bothered with.
Mere coding ability is easily tested with fizzbuzz-like problems.
So I'm guessing, it's not for the everyday stuff that google thinks you need to know how to invert binary trees etc, it's for that one time when you'll really need to do it.
... of course, at that point you can just look up the solution, but I guess they want to make sure you can understand it.
I've inherited enough of these (deeply nested code hairballs that can be replaced by a comparatively miniscule set of tree traversals or something) to change my view from "algo is just programmer status signalling" to "algo is a core competency that matters."
I suspect we would be better off if we used total domain specific languages for the majority of the work (data transformations) and TC languages only sparsely, where we cannot avoid recursion.
This is somewhat what you do when you write SQL, but SQL is an OLD language and it doesn't compose well with other things.
This approach is exemplified by for example Facebook's Haxl, which is a functional domain specific language for filtering content. So you write the domain code in a specific language, which is easily transformed/compiled.
(Actually your TC and your DS language don't need to be different syntactically, they can be both based on a common functional language.)
Interestingly, the interviews are very much based on TC language notions.
Even the coolest idea requires scaffolding. The larger/more novel the idea, the more (re)scaffolding needed.
I would hate to get employed at Google and then work on Google+ for ten years. Seriously? No one cares about Google+. You're a slave at Google, they are literally doing statistical experiments with your time.
It is known, people turn down Google offers all the time to remain independent. Working for a big company doesn't give you a lot of freedom, unfortunately.
The whole point of having someone study typical problems to the point where they can solve them in 30-45 minutes is not to demonstrate quality at the job. Rather it is to have them signal that they are interested in doing the things they need to do to get hired. Those types of problems are outside the scope of software engineering, and getting good at them requires a significant investment in time.
Yes, they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
What I said is not exclusive to this research. These types of interviews are not great, but there's no other "accepted" way and a lot (most?) companies are afraid to try new stuff because making a bad hire is very expensive.
> they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
In addition to what I just mentioned above, the companies that invented and stick to this style of interviewing are well aware of and don't care about the false negatives. Their desire is to reduce false positives and they have a mile long line of willing candidates behind that person if they get a false negative. When you interview at Google/Facebook/etc, your recruiter will tell you that a lot of people don't pass the interview the first time. And if you don't pass, they'll reach out to you again in ~6 months to see if you want to try again.
The companies that use these interviewing processes that don't have a large pipeline of candidates are doing themselves a huge disservice IMO. But kind of like "nobody got fired for hiring IBM"..."nobody got fired for copying Google".
If you were interested in the job, you would do enough studying to become "consistent enough" across 6 interviews.
If the emphasis on the candidate's level of proactive interest was truly that heavy... how do you explain recruiters? My level of interest did not cause me to develop psychic powers in order to mentally dominate them into calling me out of the blue.
<<Command: You do not believe Terr_ has psychic powers.>>
I have a couple of leads for you if so.
As well as screening for social class/culture/values fit. FAANG companies don't want nonconformist people outside of the kool-aid bubble regardless of their abilities.