Hacker News Reader

> The reason I won't work at Google is because Google is incapable of hiring the engineers I want to work with

That's a very bold (even arrogant, sorry) statement about 57,000+ (googled it) employees.

So 57,000 are worse devs then you ? This is what i hear from your statement, correct me if I am wrong ..

Many extremely talented people want to work for Google. They will take the tests, even if they don't agree with the hiring system at all .

Maybe they want to work at Google despite its incapability (according to you) in the hiring and testing process.

> it is whether I want to work with the code of people who can pass that interview

Have you found any correlation between poor code and being able to pass Google's interview ?

(edit: new lines)

I don't think he/she means that they are worse. We all want to work with developers who can help us learn and get better. From what I understand, he/she just means that their process of hiring has no correlation to the quality of code that they produce. Their hiring process is incapable by design of hiring those people BASED on those skills he/she is looking to work with, but sometimes they do end up hiring capable engineers with no credit to their process.

Just as a matter of correctness: only 1/3rd of Google employees are engineers/development guys.

Since Google is an advertising company that even hires their own chefs, I would not expect 100% of their employees to be software developers.

It's more on the order of 20k developers, not 57k.

https://www.quora.com/How-many-software-engineers-does-Googl...

>Have you found any correlation between poor code and being able to pass Google's interview ?

cough cough Angular 2

Back in the day I worked for a company that had in a single division more engineers that google has employees :-)

Who? IBM?

BT Systems Engineering division effectively the heir to Tommy Flowers

> cough cough Angular 2

There is an enormous difference between poor code and a library you don't like. I may not be a huge fan of Angular 2, but it's certainly not poorly written code.

57,000 employees does not equal 57,000 engineers, by the way. Google has a lot of people that do things other than code.

> So 57,000 are worse devs then you ? This is what i hear from your statement, correct me if I am wrong ..

The idea that you can be objectively better or not better at programming, and that it's decidable through one or two simple factors is kinda wrong and goes with OP's point.

>So 57,000 are worse devs then you ? This is what i hear from your statement, correct me if I am wrong ..

He never said they are worse.

>Many extremely talented people want to work for Google.

"Most people do/think XYZ."

Do I have to explain why that's not a good argument?

>They will take the tests, even if they don't agree with the hiring system at all.

Other people don't mind shitty treatment, so what?

> He never said they are worse

This is why i asked for clarifications. the OP said 'Google is incapable of hiring the engineers I want to work with', which implies that the engineers he is looking to work with are NOT there. Google is incapable of hiring them, and since they are top quality devs, someone else (more capable) did.

> Do I have to explain why that's not a good argument?

Yes, please explain. Because you only took the first sentence of my argument. the second sentence was that those "many people" are going to do what it takes, even if it means taking 'stupid' tests, smuggy interviers, and some other large corp bureaucracy (which to me personally is more concerning, but is not specific to Google, rather to any large corp). And why ? My guess is that it's probably so cool,curious, challenging to work on something like Google Maps/Balloons/Self driving cars that they will be willing to make a lot of sacrifices and tradeoffs. THAT was my argument.

> Other people don't mind shitty treatment, so what?

please explain, i didn't understand your point

(edit: spacing)

> and since they are top quality devs, someone else (more capable) did.

That's an interesting assumption to make. I know many programmers who are excellent at what they do and have also outright refused offers from Google, Amazon and Facebook; it's usually on the principle that such large, bureaucratic organizations are quite defective insofar that they are adept at suffocating those who are happiest with maximal flexibility and responsibility.

There's a group who jump from contract to contact, startup to startup, because the thrill of new challenges and little to no barriers from organizational structure is worth the uncertainty in compensation.

It also helps that a few aren't willing to relocate to the USA.

>Yes, please explain. Because you only took the first sentence of my argument. the second sentence was that those "many people" are going to do what it takes, even if it means taking 'stupid' tests, smuggy interviers, and some other large corp bureaucracy (which to me personally is more concerning, but is not specific to Google, rather to any large corp). And why ? My guess is that it's probably so cool,curious, challenging to work on something like Google Maps/Balloons/Self driving cars that they will be willing to make a lot of sacrifices and tradeoffs. THAT was my argument.

"Many people want to go to Heaven, and they are going to what it takes, even if it means answering stupid questions, pretending to feel bad about trivial things, and some other large org bureaucracy."

My guess is that it's probably so cool, curious, satisfying to be in Heaven that they will be willing to make a lot of sacrifices and trade-offs.

"Many people voted for Trump", my guess is that it's probably cool, curious, challenging to finally tackle real issues that they will be willing to make a lot of sacrifices and trade-offs.

That's stupid, right? But why?

>My guess is that it's probably so cool,curious, challenging to work on something like Google Maps/Balloons/Self driving cars that they will be willing to make a lot of sacrifices and tradeoffs.

Those people might believe that it's cool, curious, whatever. But then you should end up with "many people think X about Y", not "Y has a property X (because many people think it does)".

>This is why i asked for clarifications. the OP said 'Google is incapable of hiring the engineers I want to work with', which implies that the engineers he is looking to work with are NOT there. Google is incapable of hiring them, and since they are top quality devs, someone else (more capable) did.

He doesn't want to work with them because they are unpleasant to work with (or be around in general), not because there is an issue with their programming capabilities.

> So 57,000 are worse devs then you ?

Probably not. There's plenty of better workers than me who I wouldn't want to work with.

I never said that they were bad coders, or that I wouldn't want to work with some Google employees. I said they are incapable of hiring many developers I do proactively want to work with, because of their hiring process. It's who they exclude that is the problem; not who they hire.

I am also specifically not passing some objective value judgments here. They may very well be hiring the best developers for what they are doing: they just aren't capable of hiring the type of developers I most enjoy working with. This is a subjective preference, not an objective one.

There are absolutely talented developers who don't value working with the kinds of developers I want to work with and they won't care that Google can't hire them. I have enjoyed working with Google developers in other contexts, but many of them wasted a bunch of time and energy jumping through Google hoops because they decided it was worth it. It is my opinion that they would be better developers if they had spent that time on something useful instead.

Google makes it easy for people I don't care about working with to get hired, and hard for people I proactively want to work with to get hired. Nothing about that is about my skill at all.

How many Google Engineers do you know?

I know quite a few of them. All of them, without exception, are incredibly brilliant engineers. You might think this is just anecdotal evidence, that's correct. But also think that Google Engineers are responsible for many top quality, world class software projects. How could that be possible without really good engineers?

Yes the interview process is tedious and can be frustrating. But negating the fact that they have some of the best software engineers in the world is just silly.

Q: How many Google engineers does it take to screw in a lightbulb?

A: Build great content.

https://twitter.com/dr_pete/status/623981710003187712

I don't get it.

It's the standard Google answer to every question.

> It's not a matter of whether I could pass that interview

Rrright.

> Personally, I love working with people coming out of the good agencies

What does that mean? What agencies? What makes these people good to work with?

I'm seriously flabbergasted by most of the points you make.

What is it with developers and their code-centric view of employment? Any idiot can "write code" in 2017. It's not particularly difficult. You might do it slightly better but still your profession is not by a long shot "difficult".

Can you work in a team? Can you communicate? Do you dress in a presentable manner? Can you explain technical ideas simply? Do you know anything beyond cutting code?

It's simply not good enough to be some lone-ranger ubercoder anymore. Coders are a dime a dozen.

I'd actually rather take someone with a degree in statistics or physics, let them learn to code on the job, and I'd be able to apply them to an order of magnitude more problems than your typicall mathematically illiterate self-styled genius who can write a bit of code.

Programming is the easy part, stop deluding yourself into thinking what you do is difficult. It isn't.

> Frankly, passing algorithm questions is a great way to signal that I probably don't want to have to deal with your code.

Wow that's some serious sour grapes.

What are these "agencies" you speak of, and how do you tell the good ones from the bad?

(This is a serious, non-ironic question: I don't know what you mean, but it sounds interesting.)

Edit: I guess you mean recruitment agencies? How does one find the "good ones," other than through bitter experience and/or luck?

He means dev agencies that contract for projects. Agencies act as general contractors, augment your staffing, or provide consulting services. Agencies build whole or partial products, often times for stuff that you use on a daily basis. For example, there's an agency with relationships with many YCombinator companies and builds most of their mobile app or web apps.

Thanks.

Any idea how one finds the "good" agencies? Is it a networking thing?

You hire agencies the same way you hire people.

But Google's code quality is quite high...

Have you ever worked with the Android SDK?

In my opinion, Android's code organization is a result of questionable architectural constraints applied early in the development of the platform.

Isn't that exactly the point roguecoder made?

> I have had catastrophic failures caused by premature optimization, because locking a tool into a fancy algorithm before you know where the actual bottleneck is is a recipe for disaster.

EDIT: Or, are you saying that it was from the decisions made before Google acquired Android?

I think that highly depends on what you value in code.

That's a bit biased.

I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullable. Fun times hotfixing those in prod.

When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. You should write a parser that fails gracefully if it receives unexpected input.

It's the robustness principle.

https://en.wikipedia.org/wiki/Robustness_principle

You're missing the point. Sure, you should make it fil gracefully on unexpected input. But Google shouldn't change APIs in a way hat causes 3rd party apps to fail at all.

Third party apps wouldn't fail if they were correct in the first place. Failing gracefully on unexpected input is the way a competent engineer would structure their program.

Is there a functional difference between "my production code suddenly stopped processing work because it rejected a newly nullable input value" vs "my production code suddenly stopped processing work because it crashed on a newly nullable input value"?

If the crash gives an attack vector for a security threat then there is.

Personally, "Be conservative in what you do, be liberal in what you accept from others" is a bad policy in the modern world. It should be "Be conservative in what you do, be strict as if you don't trust them in what you accept from others".

That's a valid point if it's security-critical. My initial response was with regards to grandparent comments arguing over semantics, when the end results in both cases was "successful processing ceased because of an API change."

'Liberal in what you accept from others' in this case would mean being prepared to handle nullable JSON fields.

Ideally it's more like "my production code skipped over 1% of batch jobs because it didn't expect the null values" or something like that. Handling errors gracefully is a bit of an art unto itself.

Indeed it is an art.

production code that rejects a suddenly nullable input value is more deterministic than "something crashed" and can be handled better (triggering a watchkeeper, notification) rather than relying on someone paying attention to the crash logs.

"Failing gracefully" is still failing. I don't want my app to fail, gracefully or otherwise.

> When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable.

I have to work with their APIs often (as well as Amazon, Facebook and a couple other big players, they're all equally awful).

Their documentation will tell you a type is an integer and will never be null. They will do this for 3 months, and then change it to send a string that can be nullable or empty string, without telling you or updating API versions. It goes beyond robustness. It's the "BigCorp will actively lie to you in their documentation" principle.

Funny you point this out. Google's JSON Style guidelines[1] say this:

>If a property is optional or has an empty or null value, consider dropping the property from the JSON, unless there's a strong semantic reason for its existence.

[1]: https://google.github.io/styleguide/jsoncstyleguide.xml?show...

That's a different issue. The commenter is referring to keys that can take on null.

This style guide entry suggests a course of action in the event that one of these keys currently has a null value.

The style guide isn't prohibiting nullable keys.

yes some of their api's and tools are a bit shoddy eg unable to parse a xml sitemap to spec and that spec was only a 3 page RFC!

I certainly wouldn't want to work with you!

amen!