Hacker News Reader

Comment by pavlov | Hacker News Reader

One of the replies by a Googler explains the rejection succintly:

"I suspect that you are awesome as a developer in a certain place, but that Google—at least as a software engineer—wouldn’t be the right fit for you. They really do want computer scientists. The ability to figure out what to build isn’t valued all that highly, because that’s not fundamentally the responsibility of the software engineer."

What irks me is that a lot of companies have imitated Google's hiring process without ever stopping to consider whether it's right for them. Do they want engineers who are computer scientists rather than engineers who can figure out what to build?

In Google's case they explicitly don't want the latter and hire accordingly. The company is structured to make this work -- there are product decision makers who understand software and can feed work to the CS-focused engineering teams.

My feeling is that most other companies would be much better off hiring engineers with a more user-oriented mindset, yet they end up explicitly filtering that out because they want to hire like Google.

View on HN

Another interesting example is Shazam, which listens to 10 seconds of music and identifies the song. When I encountered it, I knew immediately that its implementation must be based on a fourier analysis of the sound to generate a fingerprint. That's because FA was a required part of my engineering curriculum.

No matter how good a programmer I was otherwise, without knowledge of FA I'd probably hack around for years with one inadequate ad-hoc solution after another. If I was really clever, I may even actually reinvent FA, badly.

This is where having proper engineering/mathematical training pays off. Just being a great programmer is just not enough.

For another minor example, I was given the minor job once of printing what was on the graphics screen on the printer. I knew that constructing a coordinate transform matrix was the answer, and had it running in a couple hours. A coworker, an excellent programmer, who had never heard of matrix math, was completely astonished at this and thought it was just black magic.

Yet if you look at the engineering team at a company like Shazam, I'd bet a small minority of them actually work on song fingerprinting.

Shazam is an app company. Most of the people there will be working on UIs, serving requests fast enough, integrating with partner APIs, and other standard software development where they never once need to feed audio packets into libfftw or whatever.

Your other comment seemed to suggest that you feel the Boeing model should apply here, and the people who don't work on the math-heavy product core should be considered technicians. Is that the right interpretation?

They also need a decent database to find the song from a five second sample occurring anywhere in the whole up to say 8 minute song, for their whole song library

Also in some cases have access to not well known artists altogether.

I'm suggesting that a well-rounded team has a mix of skill levels and expertises.

In my experience this is where the ability to learn from literature would really help. In this specific case you’d encounter Fourier analysis pretty damn quickly if you started to read around the subject. Likewise whilst I think my formal teaching gave me a grounding I actually value the self-learning aspect from my degree more. The hard problems are the ones you’ve not heard the solution too before. The main thing a formal education provides is a leg up and hopefully a solid set of skills to help find answers to hard problems.

I can confirm that without specific education, reading around things like audio analysis and audio fingerprinting, Fourier comes up pretty quickly, and did before Shazam was a thing.

Honestly, I think tenacity and an ability to learn and move quickly are the most valuable engineering skills one can have.

>> Honestly, I think tenacity and an ability to learn and move quickly are the most valuable engineering skills one can have.

I agree. Nowadays the information is abundant and so easy to reach. One only needs to be able to understand and learn. From there, sky is the limit.

The only place where I think this doesn't apply is within an extremely specialized space. I think that very few engineers of that type are generally necessary, though. At the same time, I'd imagine that if you do have the academic background for extreme specialization, you're probably going to be able to demand a pretty high paycheck.

Not sure about your examples. I mean, when working as a programmer, we encounter tons of things we've never heard before but we do the research, we study what's needed to complete the task and we complete the task... e.g. it is quite easy to search about audio recognition - you encounter fingerprint, then you do the research...

Your examples make sense when you're isolated on some island without a connectivity, but that's not the case usually.

Also, I think companies like Shazam have separate people/teams in "science/research department" and "engineering department".

It‘s easy to google how Shazam works now, since they exist.

I‘m pretty sure that googling for „audio fingerprint“ or „algorithm for recognizing a song“ wouldn‘t have gotten you the answer in 2002.

You need to know the maths if you want to invent something new. If you just want to reimplement existing stuff, maybe you can get away without it.

(Inventing new stuff is actually pretty rare for programmers. I don‘t think I‘ve actually invented much, despite having worked as a software developer for more than 15 years...)

People tend to underestimate the age of working knowledge a lot.

Shazam wasn't an original invention, similar things were implemented in hardware in the 80s, and original research in this area done even much earlier.

Sure, though, as you go back in time, the probability that the environment you could get exposed to that knowledge in overlaps with academic circles probably increases.

Seriously, consider that the PARC people were working on perceptrons decades before they became truly feasible. There is almost always prior art to build on.

The most valuable engineering skill I find is the ability to say "I've run into a problem, I am not the first person to run into this, let me research how other people solved similar problems so I can understand my problem and it's edges better".

I'm pretty sure you'll get more than enough 90s, 80s or even earlier papers by searching "audio recognition", classification, etc...

Also, having studied math in the university and knowing where to lookup things when needed is one thing but demonstrating the knowledge on the blackboard during the interviews is another, especially if you're a mid-career professional and don't have a time nor willingness to allocate month(s) for preparation.

Yes, I know Google Scholar didn't exist in 2002, but there were papers anyway:

https://scholar.google.com/scholar?q=audio+fingerprint&hl=en...

> job once of printing what was on the graphics screen on the printer.

I've had several variants of this, and the problem was not one of coordinate transform but either futzing with the API to actually get at the printer, or re-layout the items on the screen because transforming a 16:9 screen to a 1:1.6 piece of paper will look weird.

FA is the first thing that anyone who remotely googles for "identifying music technical implementation" pops up. The idea that someone couldn't figure this out on their own just because they didn't have rich parents who could afford to send them to some school is quite mistaken.

Put yourself in their shoes. You're you. You weren't sent to a school. What would you do to figure out the problem? Would you really hack around for years without success, or would you look up related material, read, study the problem, and check for existing solutions and scholarly articles on the topic? You know, all the things that a Real Engineer does.

And you'd get results quickly. Because you are a real engineer regardless of whether you went to a school.

I’d just like to add to all the people responding with “google didn’t exist back then” in the comments here, that libraries did exist. I found a great wealth of usable and applicable information in mathematical encyclopaedias, handbooks and software engineering books and journals (even 5 year old ones) in the public library where I live.

Let's say you did some research that suggested FA was the right solution. Now what? FA is not a freshman topic, it's a senior topic. You've got 3 years of math background you'd need to learn first to get to the point of being able to properly understand it (rather than blindly using it as a canned formula).

I'm speaking from experience. It's a generational gap, I think, which is why it's hard to understand. But it's true.

FA is using cosines up and down the spectrum to convert a set of samples (audio, image, etc) into a frequency spectrum (the magnitude associated with each cosine).

I didn't have to look that up. I just know it. And I'm no genius. This isn't nearly as difficult as it seems.

Especially because universities usually spoonfeed you information at an absurdly slow rate. There's value in that – I'd wager you could whip me if we have to bust out some paper and solve some integrals. But then again, I can just get a computer to do that hard work for me. I know what integrals mean and why they're useful, which is far more important than the rote memorization of techniques to solve them.

Now, if you want to argue that there are specializations that you can only learn in university, you'll get no disagreement from me. Distributed systems is a perfect example. On the other hand, I know those fundamentals too because I completed 6.824 on my own time. It's freely available.

And yeah, matrix math is a piece of cake too.

The world has simply changed. Information used to be valuable and guarded. Now all that matters is raw talent and motivation.

And credentials, sadly. But the world is slowly learning those aren't a great proxy for talent.

It's probably hard to empathize because you were well off enough to go to university. But you have to remember that intelligence is mostly genetic (probably), so talent can come from all walks of life. What would you have done if your parents had a massive divorce and someone squandered what little your family had? Are you sure you would have gotten a scholarship? When your parents never instilled the value of university into you from a young age?

> universities usually spoonfeed you information at an absurdly slow rate

I have to chuckle at that. I went to Caltech. A year of high school physics went by in about 4 lectures. I had to study about 40-50 hours a week just to keep from drowning. I would not have survived without help from the professors, TAs, and fellow students.

I don't disagree that a motivated, talented person can learn all that on their own. I've seen it happen, exactly once. The rest just employ ad-hoc hacky workarounds.

BTW, at the time Caltech had a specific policy that financial means would be no barrier to admission or attendance. They'd do what it took to make it work. I attended a very ordinary public high school in a working class neighborhood.

> matrix math is a piece of cake too.

But you have to know what it is to even recognize that it is the path to a solution.

Slow relative to learning the interesting bits. It took three years to get to FA? Seriously? That's a glacial pace relative to solving real world problems.

I agree you came out of it far better prepared, but drowning you in math for math's sake was merely hazing. Mostly.

Regarding your financial point: it's remarkable how hard it is for the upper echelon to empathize. It's not about the money. The money doesn't matter. It's the whole way of life leading up to college that kills you. The mindset. The motivations. The infighting. Being sent to some small religious school in the middle of nowhere because your dad thought religion was going to take over the world and it was super important for you to know a thing or two about god, then being tormented there because you're the only one in a school of 300 with an intellectual curiosity.

You think you would've stood a chance in an unfair fight? :)

Your mom and dad are owed a debt of gratitude. Family structure is the basis of power in life.

> glacial pace relative to solving real world problems / hazing

Sorry, I can't agree. My experience in post college real world problems was I was very well equipped to do so, compared with other newly minted engineers. And the techs who didn't have degrees weren't even on the radar.

> the only one

I was regularly assaulted in public school for being a nerd. Does that count?

> mom and dad

Mine were very special to me. But they were mine, and I'm heavily biased. Stepping back a bit, I don't believe they were exceptional, or better than the parents of my friends, etc.

> empathize

Get up and go comes from within, it is not installed by parents.

I wanted real bad to be a ham radio operator as a teen. I could not remotely afford to buy the equipment. I tried to build my own, but utterly lacked the skills, and could not get either the tools or the parts. Nobody helped me. I didn't know any hams, or anyone who knew anything about electronics. It was extremely frustrating.

For me, being at Caltech was very much like someone turning the lights on. I was around people with similar interests, classes were fun (despite being terrifyingly hard), lab equipment was all available, it was heaven. Nothing like public high school.

BTW, I was on partial financial aid from Caltech. They fronted me a loan, which I paid back after graduation. I'm sure they would have provided a full ride if my father couldn't pay anything.

'Without knowledge of FA I'd probably hack around for years with one inadequate ad-hoc solution after another.

Yeah, learning to read and appreciate papers and academic literature is an important skill.

Simply doing some reading before reinventing the wheel...

That's the skill.

On the flip side here, though, once you have that ability it generalizes very well. My original educational background might be in biology, but I know how to read a technical computer science paper and where to find them. It means that I may not have knowledge intuitively, but I know where to find and learn it.

I'm not at all against proper maths training because it can help with many aspects of an engineer's daily work.

How's your example different though from specific industry knowledge that typically doesn't come with your usual engineering curriculum?

An engineering degree is foundational.

For all the responders who suggest this kind of thing can be picked up on the job by competent professionals, in my years at Boeing, I never saw a single tech pick up stress analysis, calculus, kinematics, heat transfer, dynamic analysis, etc., on their own. Not one. Frankly, I felt that was a crying shame.

Nearly everyone needs a structured environment and program to learn that stuff.

> Frankly, I felt that was a crying shame.

It is. Given the right environment (which might include coaches or teachers) it should be possible to pick up knowledge about stress analysis, kinematics, heat transfer, dynamic analysis on your own.

Calculus is a slightly different matter because it's indeed more foundational than the other areas you mentioned. Still, I think calculus can be learned without a formal education programme, too. After all, most of it has pretty obvious areas of application.

How many people on the Shazam team needed to come up with the fourier analysis? How big was the Shazam team? What did the rest of them do?

This is my problem with only hiring comp-sci to build software and get stuff done. They all want to hire the John Carmacks of the world, but Doom would have never happened without John Romero. It's a waste of a PhD to spend it porting low level driver software from one architecture to another, but that type of work needs to be done, even by companies like Google.

And honestly, there's a difference between the high-level big-idea fancy stuff that Computer Science focuses on, and the low-level, details of implementing things correctly and performantly. They are not the same skills, but that's all been lumped together under this software engineering profession.

> This is where having proper engineering/mathematical training pays off.

Rather, this is where personal research skills are needed.

I cannot imagine a programmer "hacking around" without researching existing solutions for obviously difficult problem.

To put it differently, none of the colledge Comp Sci "training" has yet been of any use in my 20 years of programming work.

> none of the colledge Comp Sci "training" has yet been of any use in my 20 years of programming work

I don't have a CS degree. But I have taken college CS courses, and have been able to apply them directly to solve problems I worked on later.

Probably depends on how they make curriculum. Some of the things I remember having been taught:

  runge-kutta
  analythic geometry
  turbo pascal (or one of his relatives)
  DFA/NFA

Some of the things I find useful at work:

  memory and cache behaviour on different archs
  Dijkstra's algorithm
  posix

I mean, chance of being lucky to learn exactly the things that will be useful in programming (as opposed to other less volatile arts) is a small one.

It sounds like a self congratulatory post rationalization of the Google hiring process. People good at algorithms are not necessary to build what a huge chunk of Google engineers work on (basic CRUD apps). Additionally, being good at CS alone without software engineering knowledge results in crappy, untestable software with a poor user experience so CS knowledge isn't enough.

The best L6+ SWEs I worked with there were amazing due to their ability to distill requirements for complex products into sustainable software architectures. Other than the few groups working at the cutting edge of a CS field (<10% of SWEs), algorithms knowledge outside of complexity analysis (to avoid bad code) was essentially useless and software engineering was all that mattered.

Many employees at Google just defend the hiring process because they don't want to question the system that makes them feel superior to the hundreds of thousands that have applied over the years.

"Google doesn't build software, it advances computer science."

This hits on something that really bothered me in some of the Quora responses, particularly from those who had worked at Google: they smugness and superiority. In some ways, for some people, it could be well earned: someone took an idea from abstract concept to implemented algorithm and maybe even to a library or product and changed the world, to some degree.

Other software engineers, performing more mundane tasks, might also change the world. Howell's product certainly made a very positive difference for me and I leveraged this to get my own work done faster. I think we can all come up with many examples of software that's impacted our lives that doesn't revolve around a unique computer science discovery but instead, like Homebrew, solves a problem in a practical and accessible way.

This isn't in the text, but I am left with the feeling that software engineers who ended up (because life, etc.) working in less math-heavy roles are somehow inferior, and I just don't believe that. Working through BS level comp-sci coursework at a decent college is a significant achievement for those students, at that age, and should not be diminished. But to imply that those working in the field who have not had the good luck to have found interesting computer science problems to solve, who have instead worked at simply improving existing products or focusing on products that meet another need (i.e. accounting, communication, etc.) are not "really" software engineers is, in my opinion, going too far.

Back when I worked at Boeing, development teams were evenly split between technicians (draftsmen) and engineers. The latter had engineering degrees, the former didn't.

They often did exactly the same work. A lot of the techs were very, very good and had an excellent intuition about design and how things worked. But they got paid less for the same experience level, and sometimes grumbled about that.

The trouble was, sometimes intuition, experience, and high intelligence just wasn't enough - mathematics was needed, an ability to apply engineering principles to go beyond book solutions was required. And the techs were dead in the water on that, and that's where the engineers were needed.

I think Boeing's brilliance was realizing that both techs and engineers were needed to make a well-rounded team. Even the seating was engineer-tech-engineer-tech-engineer-tech to ensure that we worked together side by side.

I get that, if he applied to a particular compsci-heavy function... he's just not a good fit. That's fine.

But any HR department worth its salt has a good idea of the company's needs in general (i.e., the other 1000 functions that Google has), and could ascertain and recognise talents and strengths in Max, and find a fit.

The notion that, as Max puts it, 90% of Google employees and a significant fraction of developers worldwide use a technology you built, but that there's no fitting function for you at a large technology company with a highly diverse set of tech initiatives, is frankly ridiculous. There's obvious talent, drive, ability-to-deliver etc there.

> But any HR department worth its salt has a good idea of the company's needs in general (i.e., the other 1000 functions that Google has), and could ascertain and recognise talents and strengths in Max, and find a fit.

The more I read stories about hiring, the more I get the feel that all too often hiring people are preoccupied with trying to come up with reason -- any reason at all -- to reject a candidate. Instead of looking for talent to cultivate, they look out for "losers" to show the way out. They must be the bad applicants, and thus anyone who makes it through must be good, right? So clever, aren't we!

> They really do want computer scientists. The ability to figure out what to build isn’t valued all that highly, because that’s not fundamentally the responsibility of the software engineer

As a former Googler myself, I 100% endorse this analysis. Engineers at Google are well respected and have a fair amount of freedom along some axes, but UX/product decisions are not one of them. There are many engineers who enjoy working within those constraints. Ultimately, I decided that I wasn't one of them (which is why I'm no longer at Google).

Also, this at the end of Max's answer:

> I am often a dick, I am often difficult

...really wouldn't work well on most teams at Google. Google's culture has an allergic reaction to jerks, even brilliant jerks. On the whole I think this is a good thing, even if it selects against some highly capable people.

Google is a big company, and there is a lot of variance between teams. I don't think this is a great generalization.

I have only worked in one small area, but my intuition is that if you end up doing something that's very much a part of the public face of the company (say, a flagship mobile app), your experience will probably be similar to other product-driven app companies, where there are people who specialize in making product decisions and people who specialize in implementation. Whereas if you're down in the bowels of the infrastructure for transforming protobufs into cat videos, you may never meet a product manager for your whole career.

That would explain why Google's products often have very obvious flaws. The developers who know that the issues are fixable are being ignored.

yeah, like gmail marking emails from people on the same business account as spam (for years) and account switching for google drive not working (for years) to name a few of my pet peeves.

Google does some great work, but their products are far from perfect, and many have been canned because they failed in the marketplace.

Handling of robots.txt files with BOM is trivial but google does not do that so your robots.txt file my not work as expected.

From https://developers.google.com/search/reference/robots_txt?hl...

"An optional Unicode BOM (byte order mark) at the beginning of the robots.txt file is ignored."

At least they document it.

It's also a hot load of horse shit. Google has something like 40,000 engineers on staff. Do you think they're all experts at CS?

> a lot of companies have imitated Google's hiring process without ever stopping to consider whether it's right for them.

Truth be told, this is common across virtually all businesses, regardless of size and scope. Hiring is tough, since even the most well-meaning family oriented business doesn't want to put time+money into someone who isn't going to be a fit; at the same time, many employers aren't sure how to properly scope out what they want from an employee, and the end result is searching for "good ______ interview questions" and using those as the interview.

Taking the time to find out what you actually want instead of just "...the best!" is usually a better idea, but it also means taking a lot of time to really break down your needs first. I've seen interviews get past the last interview and to the final deliberation on the results only to have people arguing over the purpose of the position, which is pretty egregious in my mind.

I also imagine that it's certainly possible that at another time he may have been hired at a large behemoth like Google for another role, but by writing such a public letter, hiring him would be kind of silly now; the atmosphere is kind of poisoned.

Luckily Apple decided to hire him.

There are two kinds of software engineers.

1. The cautious engineer who joined a big corporation immediately after finishing university and who might change companies maybe once or twice in their whole careers. They never take risks, never get fired, achieve steady career progress, steady bonus every year, steady pay raises, steady promotions every couple of years, can spend hours learning algorithms, never having to spend any time to strategize their next negotiation or career move...

2. The risk-taking engineer who joined a startup straight after/before/during university and who went through companies like toilet paper for the first 10 years. Always directly exposed to market forces, ready to jump ship at any time; always keeping one eye on the lifeboat. Always looking for a big opportunity, willing to network hard, change countries, get exposure; do everything they can to stay independent of anyone else and completely self-reliant.

After finishing university, I started with path #2 but was exhausted after the first startup I joined failed so decided to try #1; unfortunately my past experience had made the corporate environment way too depressing for me. I just couldn't relate to the other employees there so I had to go back to path #2. It was difficult and painful but I got to build up my character and my confidence.

Holy False Dichotomies Batman! For the record, I am neither of those things. In fact, I'm not even close to either description.

Well they're extremes so there are bound to be people who fall in between. But I think that most engineers would be closer to one side or another.

Basically you stated that there are entrepreneurs and then also people who just wanna put bread on the table, just like any other discipline.

There are two types of hair dressers: ones that open their own shop (startup), and others that join existing shops (corporate)

What about the 20 percent projects. Don't some of them become real Google projects. (Of course, what to do for your 20 percent is selected by you.)

>> there are product decision makers who understand software and can feed work to the CS-focused engineering teams.

Their product "decision makers" aka marketing dept, have been terrible of late.

Google is really having a problem with new products, the only successful ones are one they bought that were created by software engineers not a marketing dept

Maybe Google needs to start hiring engineers that have the ability to figure out what to build and allow them to build it...

Reply on news.ycombinator.com