Ask HN: Which companies have the best engineering culture?
What do you like so much about them?
I was sold when I read this statement:
"We have business decisions made by business people, and technical decisions made by technical people. While we are accountable to fulfill business needs, business does not dictate our programming languages, tooling, technology choices, or even how we spend our time. It is common for engineers to solve technical annoyances on our own."
Individual contributors are empowered to make decisions. I am a recent hire and our team has been mob programming because we decided that was the best way to move forward on a legacy project. We are free to choose when to pair program or work individually when we deem necessary.
I cannot imagine going back to following orders from the highest paid person in the room. This is a true meritocracy culture.
Inside maybe, outside not so much.
I wouldn't rely on anything google does outside Ads (not that I do), GCE and maybe Android.
They have a (somewhat deserved) reputation for destroying services seemingly at random.
It seems like a clear strategy would avoid just abandoning projects.
These strategic choices give them the best chances of having a viable solution either for the market as a supplier or for themselves as a user when they need it, but also makes the number of failed efforts they are going to need to kill higher than it would otherwise be. Or, in short, the strategy creates corpses.
One of my former bosses was an ex-Google manager and had the same opinion. I guess Google's monorepo grew out of a historical accident from their early customizations of Perforce, and had nothing to do with any supposed engineering benefits that are used to rationalize it now. Then other companies adopted it for the same shallow cargo-cult copying reasons they also use Google's interview hazing approach. And it became an empty marketing icon, e.g. with the ACM article on monorepos.
Any more, I think monorepo vs. project repos is just a bunch of bikeshedding, and the real value of a monorepo is easier centralized surveillance. I grant this might be an important priority for megacorps, but it still doesn't mean it has anything to do with good engineering practices or culture.
- search engine and combined family of backend and web services for search features (autocomplete, image search, machine translation, session-based personalization, etc.) at an online ecommerce site with a top 300 alexa rank
- legacy code base for large-scale integrated air defense system simulations at a research lab (code spanned from 80s to 00s)
Both projects well into the tens of millions of lines of source code, much of it old FORTRAN and C in the IADS codebase, requiring us to maintain old compiler toolchains, etc.
The defense simulation stuff was one centralized repo for security purposes, with lots of bespoke extra pieces of code on this researcher’s machine or that researcher’s machine. It was exceedingly hard to work with, but obviously is not a fair comparison to a large tech company which has 1-2 orders of magnitude more code and has customized tooling for it.
The search engine codebase was split into over a hundred different component-specific git repos, and despite the occasional CI headaches, was a joy to work with because component vcs history and project workflows were so well separated.
https://wavelength.asana.com/work-life-balance/ (describes the fractal of work-rest)
https://wavelength.asana.com/work-plans-high-level-objective... (how we think about planning)
https://wavelength.asana.com/workstyle-aors/ (how we think about responsibility)
While I appreciated the extra feedback, and the tone of the communication was reasonably polite, the actual commentary of the feedback seemed unreasonable and totally subjective to me.
One of the key issues was that the code test on one hand encouraged someone not to spend too long, and to choose a simple statistical model and work on explaining how it works, but on the other hand the reviewer rejected it because it wasn't "results-oriented" or "focused enough on final conclusions."
It seemed obvious that given the nature of the take-home test, nobody was looking for a model that definitively solved the problem or had amazing accuracy. Just something small-scale, but with a meaningful discussion of the trade-offs and basic discussion of how you fit a model, diagnostics, items you would work on if given more time, etc.
But the feedback I got was that my approach needed to be more "results focused" and that in my write-up I was overly cautious to say not to draw any significant conclusions from a simple model on the toy data set or to read too much into a model that needed to be completed in a couple of hours. They said someone "couldn't thrive" in the Asana environment if they weren't able to work in a more results-driven and conclusion-driven way.
I felt the criticisms were extremely subjective and political. As a candidate, I can't read someone's mind about how "results oriented" a vague take-home modeling assignment needs to be, let alone that I have limited personal time which I can devote to it anyway. I sank a lot of time into writing code for a reasonable "first attempt" kind of model, and providing some diagnostic charts and discussion.
It felt like Asana really wasted my time on it, and that in the end the feedback reflected some unspecified and vague properties that couldn't be inferred or understood from the test instructions or talking with any of the engineers. It was just random. My same solution for the same test at another company might have been viewed as a great one, even from a "results-oriented" point of view because it would be unreasonable to expect that from a short take-home assignment.
I actually got a job as a deep learning engineer not long after that, and then got my most recent job as a machine learning team manager. My experiences working on machine learning models in production and hiring engineers for my team has only reinforced to me that such a manner of take-home data science project is really a bad way to do things.
As long as the full set of evaluation criteria and expectations are made clear, and they sincerely fit into the time limit given, a take-home test can be perfectly fine.
The trouble is two-fold
- the test creators usually drastically underestimate how long the data canonicalization / normalization process takes just to get up & running with a toy data set. This stuff plus cursory data exploration always takes an hour or two — so code tests asking you to just hack together a model plus a write-up in a couple of hours are just not realistic.
- tests are often subverted for political reasons. Someone doesn’t want to hire a candidate who is more skilled than they are; someone wants to recommend their college friend for the role; someone just prefers to work with extraverts but the candidate comes across as an introvert on the phone — whatever it is. Then arbitrary and secondary aspects of a test solution get amplified for debate to steer the decision in a political direction.
Nobody wants to believe their teammates would do this, and many times people do it without realizing. But I’ve seen my own team doing it in the past during interview evaluations, and it’s particularly bad when debating over how to assess a take-home test submission. As a candidate I experienced it a few times too, notably with Asana as mentioned before.
The other sad part of that Asana interview was that nobody in any part of the Asana pipeline ever asked me about my work experience. Every interview was tech questions, programming questions, and the take-home test. Not a single question about my work history.
In the test feedback, the reviewer suggested I might not work well in a product-oriented environment — yet nobody had asked about my work experience in a product-oriented environment at an education technology company. That’s just one example, but there were others.
It saddens me a lot that the tech industry is like this. It’s so myopic to believe I could assess someone’s subjective disposition towards being results-oriented or customer-focused or product-minded based on some random 3-hour test, and never even so much as ask them about their actual work history, where they actually solved problems and delivered products.
It doesn’t feel good to be told, “based on this ambiguous code test, you’re probably not good at thinking about product development,” when you’ve got plenty of product-development items on your resume you’d be happy to share yet are never even asked about.
- Innovation: Space X
- Responsibility: Apple
- Just chillin: Google
- Perks: FB
- Resources (hardware): Apple & FB
- Resources (brains): Apple & Google through Acqui-hiring
- Learning: Space X & Apple
Managers there really care about their reports, and their development. It's a relaxed, family friendly atmosphere, and the technology is truly the best in the world. The CEO is pretty much the inventor of deep learning, and they have nothing but good prospects for the future.
Your best bet is to apply to the places that seem like they might be aligned with your interests, and when one decides to move forward and produce an offer, use that time to really kick the tires and talk to the management and the ICs on the specific team you'll be working with.
I've found that regardless of what sort of culture upper management may be trying to build, at the end of the day your experience will be mostly made up of the specific things you'll be doing and the people you'll be doing them with.
It may not affect open-source teams though, only the finance side, and it could have changed since 2014-2016 when some of my former colleagues were there.
I also think it's telling that Wes McKinney decided to create Ursa Labs. I know Two Sigma is partnering in the early stages, but I read it as clearly a sign that he wasn't empowered with whatever he was promised by them.
So then maybe the real test for great culture is if they can maintain it for an appreciable amount of time? It's a really tough one to answer.
I'd say a good guideline is to stay away from open offices, or places with no monitor. Geek perks like mechanical keyboards are nice too.
made me decide I probably didn't want to work there. (This was 2015, maybe things have gotten better?)
* Fog Creek
* Stack Overflow
* (sometimes) Microsoft (private offices, supposedly going away)
* RedHat
Basically anywhere that passes the Joel Test. In my experience, that seems to be accurate - with more emphasis needed on a quiet, low interruption environment.
But it seems like so many Y Combinator companies don't embody these quality-first principles, and comments or posts espousing them even here on Hacker News seem to get consistently downvoted or quickly pushed out of the spotlight, or undercut by comments about how wanting an office is "whining" or hijacking the discussion into a debate about headphones vs. real estate costs vs. Agile teams, none of which are relevant.
I really wonder why Y Combinator, as a clear thought leader in the technology start-up space, doesn't vocally support private offices more, given Graham's own unequivocal endorsement of them in an essay about foundational ideas about software productivity and quality.
The same could be said about other topics beyond offices too.
I have wondered this, as well.
Although it's admittedly not entirely charitable, my best guess is that it's because, even to YC, appearances and "social proof" matter more than promoting engineering productivity.
Still, if startup success isn't actually predicated on the benefits that private offices would bring, then there's not much point in YC supporting them.
Sadly, I can't imagine there's anywhere near enough data. The best we'd likely find is cubes-versus-open.
Even concrete stuff like "offices going away" completely depends on your team.
There is an extremely thin line of commonality that you can pretty easily discern by reading blog posts and watching videos of the CEO and folks like Scott Guthrie; I find what I see in those communications to be genuine.
(disclosure: At Microsoft, and liking the culture)
Sure, company politics can interfere with this on occasion but it's rare. I read the question more as, "Which companies have the best philosophies regarding how engineering should be done?"
Could be a difference of course, but it's not clear.
There's a lot more and I am happy to answer any questions.
Most of the day goes into pair programming on the planned stories for the sprint. Usually TDD is preferred, but the pair decides their style of working. Tests are a must. Usually there's a build monitor to track test failures.
Tech huddles are called in case of important technical decisions or if there are hurdles. Stories start with a Kick-off to dissect all aspects of it in detail. These are attended by business analyst, quality analyst, tech lead and the pair.
Dev box testing helps catch defects early. So on and so forth. There are sometimes evening meetings with clients depending on time zones, availability etc. Features are demoed in this meeting to get feedback even before they are deployed to Dev or Staging.
Overall the org is unstructured but empowering. There's very little hierarchy.
Are you tied at the hip to your pair? Can you come into work, take lunch, leave work, vacation, and go to the bathroom on an entirely different schedule to your pair? Essentially, does pairing erode autonomy and freedom to a degree?
The rest doesn't sound that bad, but also nothing spectacular
What would spectacular look like?
Is your schedule dictated in any way by your pair? If your pair likes to take lunch at 11 and you like to take it at 1 is that a Big Deal in the sense that you'll be less productive than another pair? How much is the typical "one person talking/thinking, one person typing" and how much is just two people programming next to each other?