
Ask HN: Which companies have the best engineering culture? - CSMastermind
What do you like so much about them?
======
pdt256
CJ Affiliate

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.

~~~
napo
Sounds like the triangle of success.
[https://www.youtube.com/watch?v=yy0lEzhc8yo&t=29s](https://www.youtube.com/watch?v=yy0lEzhc8yo&t=29s)

------
jshute
Google. monorepo with almost full visibility, code search/cross
referencing/review tools, good infrastructure support, great videoconference
and collaboration tools, a culture of written knowledge vs. oral lore, clear
strategy in many parts of the business (loosely coupled, tightly aligned).
Perks, pay, vacation are excellent. Work life balance is generally good. World
experts in relevant subject matter are never far away.

~~~
kenmicklas
The things you mentioned are mostly true, however the technical culture is
very reactionary and the promo process rewards worse engineers on average in
my experience. Most of the better engineers I knew there ended up leaving
after a while.

~~~
ariwilson
Did you work there? The promo process, especially at the higher levels, does
reward ability-to-explain-and-contextualize over pure technical ability, but
my opinion is that senior engineers need more of the former than the latter
anyways. Deeply understanding your product and what is necessary to make it
better can be more important than the ability to pump out algorithms and
models.

~~~
kenmicklas
Yeah I used to work there. Not sure about the higher levels but the incentives
in the L3-L5 range were very messed up.

------
gspilio
I recently started working at Asana and I was pleasantly surprised how people
constantly strive to empower each other and make them feel secure in making
decisions and picking up responsibility. Mentorship has been gret as well. It
has been by far the best environment I have worked in so far.

~~~
gspilio
A small list of articles for people who would like to read more about life in
Asana:

[https://wavelength.asana.com/work-life-
balance/](https://wavelength.asana.com/work-life-balance/) (describes the
fractal of work-rest)

[https://wavelength.asana.com/work-plans-high-level-
objective...](https://wavelength.asana.com/work-plans-high-level-objectives-
roadmap-week/) (how we think about planning)

[https://wavelength.asana.com/workstyle-
aors/](https://wavelength.asana.com/workstyle-aors/) (how we think about
responsibility)

~~~
mlthoughts2018
I once completed an intense take-home machine learning test for Asana, and the
process of getting feedback for my solution was one of the worst, most
political experiences I've ever had while interviewing. I don't know if I got
paired with a bad engineer or what, but it was a hugely bad outlier in terms
of machine learning interviews.

~~~
gspilio
I am surprised to hear that. Would you be willing to share more details with
me?

~~~
mlthoughts2018
I actually mentioned it in a Hacker News thread a few years ago, and someone
named Jack contacted me from Asana to try to provide feedback by email and
help clarify what happened.

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.

~~~
erinakinci
I appreciate your honest feedback here! I’m currently the hiring manager for
this position, and I agree that this doesn’t sound like a good experience. I
disagree that a take-home assignment is inherently a bad idea - I actually
have found a lot of value in seeing the work people produce there and feel
it’s the part of the interview that’s closest to what the team actually does
day-to-day - but I also don’t want candidates to feel like their efforts are
being graded in a way that’s unfair or lacks transparency. Because of that, in
the time since you interviewed, we’ve updated the rubric to be less subjective
and better set up to reward the diverse ways someone could show data science
skill, updated the text of the assignment to more clearly indicate what we’ll
be evaluating, and made it standard practice to share with candidates right
away where they did well and where they lost points. If I'm reading your
concerns correctly, I think those changes are likely to address many of them.

~~~
mlthoughts2018
Sounds like you’re doing a lot of good work on the process since the time of
my experience.

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.

~~~
erinakinci
I continue to agree that it doesn't sound like this was a good experience. I
think you'd find that our data science interview process is actually
substantially different today and changes many of the things that felt
frustrating to you when you went through it a few years ago, including an
increased focus on discussing past experience. Thank you again for your candid
feedback.

------
bsvalley
What do yo mean by engineering culture? Sounds like a broad term. It depends
on the company, the department and even down to the team. But from my own
experience and friends feedback:

\- 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

------
iamcasen
I'll toss my hat in the ring for SoundHound. I worked there a few years back,
and it honestly felt like family. I was going through a lot of changes in my
personal life so I decided to leave, but I regret that now. I should have
stayed there for at least 4/5 years.

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.

------
a-dub
This stuff varies way too much team by team regardless of company level
mandates.

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.

------
hetspookjee
I wonder about 2Sigma. I seem to naively assume that contributing to a lot of
open source projects equals great engineering culture, and this company does
seem to have a lot of lead devs from large OS projects.

~~~
mlthoughts2018
I've heard a lot of bad things about the culture there. The main complaint
I've heard is that the company sometimes organizes new projects in a directly
competitive manner: multiple internal teams will be assigned the same project
and given the set of criteria for evaluating the work. Then at whatever
deadline, only the team that "wins" gets bonuses associated with that work.

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.

------
acconrad
I've been at some great places. The problem with culture is it changes. I
could tell you companies that are great, but they could change in 6 months if
they get new management. I can also tell you places that suck now that _were_
great a year ago.

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.

------
commandlinefan
Well, I can definitely give you a long list of ones that don't...

~~~
sidcool
Which ones would be in the top 3?

~~~
pc86
Everyone is tied for last.

------
muzani
It's hard to judge without being in there. Most people can only judge from
blogs by the founders, which is why Basecamp and Fog Creek get mentioned a
lot.

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.

~~~
otalp
What place has no monitor??

~~~
muzani
Plenty of companies, sometimes giant ones, ask you to bring your own laptop.

------
yurylifshits
JetBrains is among the best.

~~~
handbanana
Go on...

------
ianrtracey
Atlassian's is great

~~~
handbanana
Go on...

~~~
ianrtracey
20% time that people use. Quarterly hackathons that the whole company partakes
in. Healthy budget for travel, classes and conferences. Engineers have lots of
weight on product decisions and ideas. Cloud teams use modern tech stacks and
are doing cool things with infra/AWS. Founders are highly technical and still
like to be involved in some high level technical decisions.

~~~
pc86
Are the hackathons during work hours? Maybe that's how they get some of that
20% time back :)

------
knoxa2511
I've always been impressed with the work coming out of etsy. Statsd is a great
example - [https://github.com/etsy/statsd](https://github.com/etsy/statsd)

------
reggiepret
I have read 37Signals (Basecamp's) employee handbook, and it sounds like a
great place to work, and their tech works really well!

------
JBReefer
The canonical answers seem to be:

* 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.

~~~
Floegipoky
Overall the "Joel Test" is still relevant, but a few of his steps haven't aged
well. 3 and 10 in particular.

~~~
dasmoth
10 (“do you have testers?”) still seems pretty appealing to me. I still see a
lot of value in manual and black-box testing, especially for interactive
tools.

------
mkoryak
Catalant.

------
sidcool
ThoughtWorks is pretty cool for a lot of reasons.

~~~
handbanana
Go on...

~~~
sidcool
I would be happy to answer any questions about the company.

~~~
napo
What are the reasons that make ThoughtWorks cool?

~~~
sidcool
There's a lot of freedom engineers get in choosing projects. There are teams
that are dedicatedly working only on open source projects. ThoughtWorks
organizes a lot of free events and workshops for technical development of the
community. There is a big social component in every initiative, be it
increasing diversity, equal pay, training women in tech etc.

There's a lot more and I am happy to answer any questions.

~~~
handbanana
How about describe a typical day in the life of a software dev there?

~~~
sidcool
It depends a lot on the project. Usually it starts with a team standup and
walking the physical wall. The usual one minute status on the story, and in
case of any impediments, a call out. Regular checks on emails, chats etc. may
follow.

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.

~~~
handbanana
I did think they were pair programming oriented, how unfortunate.

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

~~~
sidcool
Mostly yes, pairing is encouraged. But individual preference is respected.
Pairing does tend to be highly collaborative, though I won't put it the way
you have. Pairing obviates code reviews. It's not applicable everywhere, but
wherever it is, the benefits are very obvious and apparent.

What would spectacular look like?

~~~
pc86
I'm sorry but you didn't actually answer handbanana's question.

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?

~~~
sidcool
Let me try again. Schedule is influenced by the pair. There are times when
schedules conflict. They are resolved between the pair. There are no rules
around it. It's more two people thinking and programming. If necessary the
pair separates for some thinking time and reconnect to discuss.

