Live data from Hacker News

Software Engineering Insights from 10 Years at Google

addyosmani.com

131–140 of 151 posts

Re: Software Engineering Insights from 10 Years at Google

#131
post #118

Earlier quoted context omitted.

Without leet coding, named algorithms (binary search, dynamic programming, and other esoterica) or data structures (only requiring knowledge of arrays, assoc arrays, loops is enough), coding interviews still allow you to demonstrate your thinking ability. You can construct various simple problems (that require only loops and arrays) that can easily be mapped to real world problems and see how well the programmers per…

You see but here is the thing... Let's say I am interviewing, for their corresponding roles, one of the Aerospace Engineers responsible for the design of the latest Airbus, or a specialized heart surgeon with 10 years of experience, or a Civil Engineer that lead 5 year projects building bridges crossed daily by thousands of persons. What kind of look would they give me....If I start throwing them the type of mental p…

But that is not a mental puzzle. It's a straightforward march of thinking.

Programming as a craft, generally, does not have a "great filter" like medicine, civil engineering or aerospace. The longer one survives in these fields, there's a really small chance of surviving out of luck and not out of experience.

If you look at carpentry instead, the mental part of the craft is also one thing you can test. For example, you might provide a limited set of tools (like arrays and loops) and require a solution to a carpentry problem. The mental part is not tested by puzzles (by puzzle I assume there's a set of tricks you need to know, or in the case of programming, a particular algorithm), but by problems. Problems might be more concrete for carpentry.

The problem above with buses can be reframed into whatever the area of programming expertise is for a candidate. There's a simple underlying structure in the problem that can appear in web dev, networking, databases, that maps directly to that bus problem. If you cannot figure out the buses, then how will figuring it out for something else be simpler? The solution is just loops and arrays, there's no fancy algorithms, there's no fancy math, it's pure art of programming.

Like I said, it's only one part that you're testing, which is thinking/problem solving. It can also be affected by personal anxieties or whatever. Failure at a particular problem does not mean much. But I would not say that these kinds of coding tests break hiring.

I mean, I hear people are being asked to pick if they're more hardworking or creative, or to describe where they see themselves in 10 years, or some other similar abstract silly stuff. I'd much rather someone asks me about buses.

Re: Software Engineering Insights from 10 Years at Google

#132
post #122

Earlier quoted context omitted.

It's not your code, it's Google's and I don't see how this is an anti-pattern. It is actually one of the best thought out solutions to balancing source code supply chain security and productivity. The fact that the industry has moved towards git and allows employees to clone proprietary codebases onto developer machines anywhere in the world is pure insanity.

It’s also Google’s laptop but maybe they should have me remote into it instead of letting me touch it. Who knows, I might steal it…

To Google, a laptop is worthless compared to their intellectual property.

Re: Software Engineering Insights from 10 Years at Google

#133

Earlier quoted context omitted.

Usually don’t take their advice if they are literally making a mistake while delivering it.

Hah. In truth, I deserve that feedback. I’ve been slacking on adding proper CI/CD to my blog, while my apps on Netlify/Vercel don’t have this issue. I’ll take this as the proper kick in the pants to work on that.

I meant that as a half joke bro, keep up the great work!

Re: Software Engineering Insights from 10 Years at Google

#134
post #90

Earlier quoted context omitted.

Software Engineers are not Engineers they are Professional Musicians. They need their Algorithms and Data Structures knowledge, the same way a Jazz musician needs the circle of fifths and a deep understanding of Harmony, to do sophisticated improvisation over a Jazz standard. If you need to go on tour with your rock band you don't go to a Music conservatory and start interviewing musicians based on their knowledge of…

Without leet coding, named algorithms (binary search, dynamic programming, and other esoterica) or data structures (only requiring knowledge of arrays, assoc arrays, loops is enough), coding interviews still allow you to demonstrate your thinking ability. You can construct various simple problems (that require only loops and arrays) that can easily be mapped to real world problems and see how well the programmers per…

You throw some good arguments and although I am not in agreement with such methodology let me ask would you apply the same process when hiring a senior engineer with a demonstrated experience of N+ years in tech you're looking for?

Isn't that off putting and isn't that ingraining distrust from the very beginning?

Re: Software Engineering Insights from 10 Years at Google

#135
post #90

Has someone collected all these self-aggrandizing posts that spew from ex-Googlers and current Googlers? It feels like a pre-requisite for their promotion packets. These all sound about the same and are altogether unhelpful. Note the copious links to terms and inlined quotes rather than an actual study, or any evidence at all...just vague rewording of colloquial expressions commonly traded around. The only use seems…

Software Engineers are not Engineers they are Professional Musicians. They need their Algorithms and Data Structures knowledge, the same way a Jazz musician needs the circle of fifths and a deep understanding of Harmony, to do sophisticated improvisation over a Jazz standard. If you need to go on tour with your rock band you don't go to a Music conservatory and start interviewing musicians based on their knowledge of…

I can't agree with any of these perspectives, or the analogy to being a musician. Also, I find it to contradicts itself.

Initially, you say: you need the core knowledge of algorithms and data structures (like the circle of fifths and harmony) to do sophisticated improvisation.. so you're advocating for the importance of having a strong technical background. OK, fair.

But I don't get your analogy to a rock band going on tour, and they either have it or they don't? What is the software analogy to going on tour? Is this working in a startup, when you just need results rather than finesse? How does this tie back to your initial point about jazz musicians needing a core base of knowledge?

You also bring up the myth of the self-taught, scrappy musician (or programmer) who, against all odds,'has it' and is able to exceed the abilities of others who are the hardest-working and most studious.

I find this concept pretty toxic. The Eric Claptons and the Jimi Hendrixs of the world are a rarity, a complete exception. Although often cited because they are incredibly visible, compared to the hundreds of thousand if not millions of others who either developed skills and capabilities through education and/or self-taught effort. Often without 'having it'. I think it can be pretty discouraging when everyone holds themselves up to ideal of Claptons and Hendrixs.. rather than considering there might be multiple, varied and nuanced paths to being an excellent engineer, or musician.

Re: Software Engineering Insights from 10 Years at Google

#136
post #132

Earlier quoted context omitted.

It’s also Google’s laptop but maybe they should have me remote into it instead of letting me touch it. Who knows, I might steal it…

To Google, a laptop is worthless compared to their intellectual property.

It's more the principle of the thing–if I wanted to steal code from Google their "no source code on laptops" policy wouldn't stop me at all. And given that I don't actually want to steal code the policy sucks, so the real question is what the benefit is here by treating me like a criminal.

Re: Software Engineering Insights from 10 Years at Google

#137
post #135
post #90

Earlier quoted context omitted.

Software Engineers are not Engineers they are Professional Musicians. They need their Algorithms and Data Structures knowledge, the same way a Jazz musician needs the circle of fifths and a deep understanding of Harmony, to do sophisticated improvisation over a Jazz standard. If you need to go on tour with your rock band you don't go to a Music conservatory and start interviewing musicians based on their knowledge of…

I can't agree with any of these perspectives, or the analogy to being a musician. Also, I find it to contradicts itself. Initially, you say: you need the core knowledge of algorithms and data structures (like the circle of fifths and harmony) to do sophisticated improvisation.. so you're advocating for the importance of having a strong technical background. OK, fair. But I don't get your analogy to a rock band going…

I mean that learning everything about Music theory can not guarantee you will ever be able to have the natural skills required to be a professional musician. And you give a guitar to a few adolescents, and in a few weeks some will be at the same stage while others while come back to you playing most songs they hear on the radio.

What I think is toxic is to make many believe they can get a Computer Science education and become a professional Software Developer. The same way finishing a five year Music degree might still mean somebody is terrible at the Piano.

Re: Software Engineering Insights from 10 Years at Google

#138
post #96

Earlier quoted context omitted.

It's somebody's blog post that's passing by and will be gone tomorrow. I don't think we have to worry about it being overly "elevated". On the other hand we have a bunch of people spending too much time on hacker news, often with all the insight of someone who spent 5 minutes scanning a wikipedia article. I'd worry a lot more about the long term effects of elevating this self congratulatory content, but where's this…

> somebody's Addy is pretty well known in the frontend community. He's published a bunch of books, has hosted the Totally tooling tips podcast, gave a bunch of talks on performance, and has appeared in popular frontend publications, such as the Smashing Magazine.

[deleted]

Re: Software Engineering Insights from 10 Years at Google

#139
post #118

Earlier quoted context omitted.

You see but here is the thing... Let's say I am interviewing, for their corresponding roles, one of the Aerospace Engineers responsible for the design of the latest Airbus, or a specialized heart surgeon with 10 years of experience, or a Civil Engineer that lead 5 year projects building bridges crossed daily by thousands of persons. What kind of look would they give me....If I start throwing them the type of mental p…

But that is not a mental puzzle. It's a straightforward march of thinking. Programming as a craft, generally, does not have a "great filter" like medicine, civil engineering or aerospace. The longer one survives in these fields, there's a really small chance of surviving out of luck and not out of experience. If you look at carpentry instead, the mental part of the craft is also one thing you can test. For example, y…

Ok. Let's put your theory to the test by making this more concrete:-)

You are working as an Interviewer for a FAANG and the six candidates today for a SWE position are:

- Linus Torvalds

- John Carmack

- Fabrice Bellard

- Guido van Rossum

- James Gosling

- Donald Knuth

What "puzzle" are you proposing?

Re: Software Engineering Insights from 10 Years at Google

#140
post #139

Earlier quoted context omitted.

But that is not a mental puzzle. It's a straightforward march of thinking. Programming as a craft, generally, does not have a "great filter" like medicine, civil engineering or aerospace. The longer one survives in these fields, there's a really small chance of surviving out of luck and not out of experience. If you look at carpentry instead, the mental part of the craft is also one thing you can test. For example, y…

Ok. Let's put your theory to the test by making this more concrete:-) You are working as an Interviewer for a FAANG and the six candidates today for a SWE position are: - Linus Torvalds - John Carmack - Fabrice Bellard - Guido van Rossum - James Gosling - Donald Knuth What "puzzle" are you proposing?

The proof of their experience is publicly visible. That is not the case for most individuals, including me.

FizzBuzz is not a puzzle solvable only with an obscure trick, and easily maps to real world, the buses problem too, and I can list more problems that are solved with 1-10 lines of code but the initial attempt used 20-50 because the structure of the problem was not fully exploited, unnecessary passes over the data, too much intermediate state etc. (all of the listed bloat appears in real world all of the time)

There are no tricks, no maths, no algorithms, no data structures involved. Your ability to pattern match these little bits should grow with your experience.

Post reply on HN