* With few exceptions, engineers aren't hired for a specific team; they go through bootcamp where they get exposure to all parts of the stack and tasks from different teams.
* Ideas usually come from engineers. Managers are there to be a sounding board/connect you with people resources as needed.
* Moving fast is valued (we used to be famously known for "move fast and break things" but now it's "move fast with stable infra". I.e., our dev infra is developed with a eye towards enabling rapid iteration.)
* Lots of internal knowledge sharing.
* Scale. Probably only Google, MS, Amazon come close.
* With only very few exceptions, every engineer has access to the near-entirety of source code at FB (Oculus, Whatsapp, Instagram...).
* Internal mobility is quite straightforward; after a year you can generally transfer to teams with available headcount without a formal set of interviews.
Of course, it's not everyone's cup of tea and like any big company it's not always 100% perfect and we don't always live up to this in every circumstance, but in general this is what it's like and what we're aiming for.
A caveat is that I originally entered FB's pipeline through a referral from a friend who interned and works at FB right out of CMU computer engineering. Referrals are often enough at these big tech companies.
What are the exceptions?
I'd imagine the exceptions are some small black boxes that try to catch abuse/spam/etc in various ways & places, or are closed off to prevent a code leak from exploiting a loophole in said software. Defense in depth, and all...
For the most part, the exceptions are acquisitions (but those get integrated eventually, see above) or some third-party IP subject to obligations.
Let's avoid putting here obvious companies and companies who over-engineer, maybe?
http://quellish.tumblr.com/post/126712999812/how-on-earth-th...
https://www.reddit.com/r/programming/comments/3m5n2n/faceboo...
As for the 18k classes in their iOS app, I don't see why this is a sign of bad engineering? I'd expect that a large number of these are auto-generated, for example from Thrift API definitions, and I'd also expect that what we see as users is the tip of the iceberg in terms of the code needed. There's obviously a lot of analytics code, and also I'd expect the resiliency and reliability needed requires much more code than we'd expect.
Scale is handled at the back-end.
As a small-company person who migrated a few years ago to one of the Big Four, I can confirm that almost every time someone tells you about "scale" they are bullshitting you. Most developers on those companies either do not deal with scale at all (anyone dealing with front end stuff) or do so by using abstractions which allow them to ignore scale (99% of developers). But scale sounds sexy so everybody pretends they have something to do with it. And it sounds better than "bloat" which is what they really mean.
The other variant of "scale" is "I have this single-computer application running on X hundred thousand servers" or some ambarrasingly parallel problem of that sort. Then they will claim boldly that something that has a 0,0001% chance of happening "happens multiple times a day here" which sounds impressive until you realize that that thing has no impact on the SLA and you get saved by the load balancer so it isn't particularly important anyway.
The 1% of people who work on real problems in the area don't need to brag on the Internet about "scale" because they are too busy working.
The light FB app probably does very well by class count metrics, but it's intended for a totally different market. Stateside, much as we may bitch about it, it apparently doesn't matter for an app in FB's position.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Facebook wants the shortest possible time between product idea and real world users interacting with it, which is why they also have a solid CI/CD pipeline. You might not agree with the tradeoff, but the pragmatism is impressive
What makes you believe this is "clever" as opposed to a poor engineering decision? I strongly suspect that FB might have delivered a higher quality product through a more traditional team-ownership development model. Throwing large numbers of developers at a single app is unlikely to lead to a well-architected holistic solution.
How is that good? You essentially don't know what you sign up for.
They must have a great culture. Look what FB did for the JS ecosystem just recently—yarn, React, React Native, Immutable. Really excellent stuff which you not only need superb people but also a good culture.
So, I'd say that excellent products, both the commercial ones but also open source, are a good indicator for 'culture'.
At one point, we had completely outgrown our space and we were constantly tripping over one another. It was miserable and everyone was constantly sick. Eventually, we got more real estate and everyone was happy, more productive, and less ill.
As long as you have the real estate, open floor plans are nice and help you feel less imprisoned than cubicles imo.
That's not help. I don't feel imprisoned in a cubicle. I like walls, the taller the better.
I'm currently in a short-wall cubicle farm where we have enough space to not to all get sick, and even there the cross-talk from multiple conversations can be completely distracting.
While management/facilities ignorance can definitely make open plan offices worse, I think they're still not for everyone. Some people seem to not mind being distracted, other people are really sensitive to it.
* you decide on a team before you start, but after you know you passed the interview
* moving fast is not valued as much
I would also add that Facebook uses a lot of Open Source, meaning your experience will be applicable elsewhere.
Here are some potential advantages about working at Google:
* Being ethical is a core value of the company.
* Google/Alphabet is more diverse (Search, YouTube, Android, Hardware, DeepMind, Waymo ...) and has more offices worldwide.
* It has an advantage in Machine Learning and Research. Google even has an internal research conference.
* Google even has it's own incubator for entrepreneurial employees (Area 120).
* Google is trying hard to make it's hiring and promotion process objective and unbiased. That's why they happen by a commission of peers.
How does it make them stand out? What does it translate to in practice?
Google's search rankings are unbiased. The ads team is separated from the search team. It's business model benefits from and supports an open internet, unlike other companies which lock users into their ecosystem.
Google is very transparent internally for a company it's size.
Google releases large of amounts of open source software and publishes research. For instance Google published a paper that explains in detail how it's Machine Translation system works.
In my 2 dozen or so ContentID flaggings, maybe two of them have been by parties with a legitimate claim to the material. All the rest have been fraud.
My most recent "pleasant" experience with ContentID was some scam copyright company claiming they owned the soundtrack to Elder Scrolls: Morrowind. The beauty of this system is that not only are they fraudulently claiming they own that content, but to get my video published I have to swear that I'm not stealing the content they actually stole.
How do I report this scammer to YouTube? Well you can't. There's no automated way, and there's no support whatsoever. They can just scam in peace for years and years and nobody can do anything about it because nobody at Google cares.
"Ethical". Riiight.
But there's no way to tell Google, "the guy making this claim doesn't own the content, he's a scammer". That's the feature I need.
I am 100% certain that the company claiming to have owned Morrowind's music: 1) Is not Bethesda (the developer of the game) 2) Is not affiliated with Bethesda in any way 3) Has no right to the music
But I have no way to communicate my research to Google. Because, guess what, those "ethical" Google employees make money off the scam, too! They take a percentage of all ad revenue, even if it's a ContentID scammer's ad revenue.
Most of the compliant about Google hiring practice has been along the line of, and I paraphrase "I was promised to be with a team or a position and then I got placed in a totally and differently unrelated position/team"
How on earth does this follow? I know that peer review is in fashion right now, but without some very strong context, this seems more like a recipe for a Keynesian beauty contest than a useful measure of merit.
There has been research that showed that this kind of decision process decreases bias.
> Google is trying hard to make it's hiring and promotion process objective and unbiased
Google tries very hard to appear to be ethical, unbiased, responsible, and generally virtuous. Sometimes this attitude results in good work. Other times, and I think more often, it amounts to empty posturing and counterproductive gestures. In the social sphere, this "be seen as good" attitude manifests itself as annoying virtue signaling, speech policing, and other behavior that you also see on American college campuses. This behavior is annoying, but very common in tech and easy to ignore.
The "be seen as good" attitude also manifests in technical culture, however. There's this weird attitude inside Google that what is painful must therefore be right, as if difficulty were its own reward. While it's true that the right thing is often painful, the converse does not hold, so Google makes some bad decisions.
Google's attitude toward developer friction is, "This process is slowing you down? Too bad. That's how responsible engineers work." This hairshirt-loving attitude leads to large teams, moving slow, and general risk aversion, and I think it leads to bad engineering-cultural choices.
Google: "This language feature causes problems? Let's ban it. We'll add headcount to make up for the productivity drop."
Facebook: "This language feature causes problems? Let's add tooling to warn developers about the dangerous usages and make sure we can quickly find bugs."
I've worked at a lot of tech companies. I don't think the people at Google are actually any more or less ethical than the people at other top-tier tech companies.
> moving fast is not valued as much
It's important not to underestimate how much moving fast makes you happy and how unhappy you become when moving to a slow environment having worked in one that moves fast.
Facebook's elevation of moving fast to a first-class goal goes a long way to slowing the kind of decay that Google has suffered.
Google's business model is pervasive surveillance, so that's a pretty odd thing to brag about.
Sorry, this could be slightly off topic for this thread. I'm curious if this kind of access also applies to all the data that users put up on the platforms? To put it in other words, how does FB prevent or work to prevent LOVINT [1] like cases? If it's the same kind of access, wouldn't working in the company make the employee uncomfortable that there are people who can look at all information?
[1]: https://www.washingtonpost.com/news/the-switch/wp/2013/08/24...
P.S./disclaimer: I personally dislike FB as a platform and as a company for privacy and other policy reasons I don't agree with (like "authentic names", for one). So my bias may be showing in my question, although it's intended to know more and not meant as an attack.
A few examples:
There are clearly defined initiation rites for new employees that make them familiar with the engineering practices.
Focus is on a few key languages (C++, Java, Javascript, Python, Go) and code reviews are practiced over the team boundaries. This makes the knowledge transfer inside the company faster.
Changing your team and role regularly is encouraged.
Single, company-wide code tree and build system makes it easy to switch teams and make it possible to build very efficient tooling.
Coding style is strictly enforced to avoid petty fights and Google's very good coding styles guides include reasoning why certain choices were made.
This is not entirely true. I've seen many people being promoted for "jumping on grenades", especially in SRE. A culture of heroism is unsustainable, but individual acts of heroism (when required) should always be appreciated.
I would love a fair comparison.
Also, what do you prefer over Python?
I don't have preferences as such. My main problem is that over the past few years my perl skills have been in such high demand that I haven't had much time to do substantial other programming stuff (this is a class of problem you want to have). I have been playing with python's maths libraries (particularly sympy) lately, and along with jupyter it's pretty neat stuff.
There are for sure better and worse companies in each category, but even within big companies there is huge variance and it depends what you are looking for.
Though some generic observation:
1. Product companies tends to have better culture than software consultancies.
2. Companies which got strong technical leadership and software is a key component rather than add on (e.g. some banks).
3. Good litmus test is to ask employees, do they have hackathons/educational budget/internal tech talks.
4. Another litmus test is to ask how hard is to push feature to production/release or about developer tooling. Good companies tend to have convenient tools.
Of course even those 4 points got exceptions.
I'm a designer rather than an engineer, but I've always been a bit puzzled by the popularity of intra-company hackathons. It seems like a great way for management to keep employees working longer hours for less pay – an overnight hackathon that results in, say, 80 hours of additional work from a small team only costs the company some pizzas.
If "everyone" does it individuals are less inclined to say "No."
But if it's a free for all, do anything you want style, and participation is optional (truly optional, not fake-optional via management peer pressure), then it's a good sign.
I suppose there's an argument to be made that a good employee can make it mutually beneficial (use the time to learn a new, marketable skill that can get them a raise or a better job), but still...
We did this when I was at Guidewire and it was amazing. I explored Event Sourcing during a hackathon and eventually went on to build it into a product using those skills - it's a really happy memory. In another hackathon I built easter eggs into our internal seating chart application - the vibe of everyone hacking together was great.
This was a hackathon where it was broad enough that "reading an interesting programming book" counted, and nobody really bothered you if you did something completely different.
1. We do hackathon once a quarter during work hours.
2. We do 24h hackathons, but it's really fun!
3. Well we work so long that we don't have time for hackathon.
4. We care so much about work-life balance, that we don't do hackathons.
Depending on what you are looking for, you may be satisfied with different answer.
Plus I like pizza.
I understand that some people don't enjoy these kinds of things the way I do (and to be honest, I can't do 24 hours of anything any more). As programming jobs become more integrated in society I find that hacking culture is changing. There are many more 9-5ers these days than when I first started. As much as I understand it, and as much as I think it isn't necessarily bad, it makes me a bit sad.
They are merely X days provided by the company where your regular duties are no longer your priority. Instead you are encouraged to learn and/or create.
Some may work more hours. Some may work the normal hours. That's it.
If it imposes restrictions on what can be worked on and limits creativity and doesn't put learning first, it's really not a hackathon.
Hackathons don't have to be free labor for pizza.
This is so crucial. I currently work at a bank and it is frustrating. The business side forces technical decisions on you, is generally not very understanding of technical challenges, is micromanaging, etc.
On of the "in between" things I really like is working in the IT department of a non-tech company. In that space, there's opportunity to do really well, even if you aren't in the top echelon of tech talent.
Typically, that's not because these companies don't care about technical expertise, but because they want developers with a good balance of tech expertise and business expertise. Someone that's willing to spend enough time with the the business side of the house and listen to their views is highly valued.
Following from that, compensation is one of the easiest ways to measure professional "success", which is why large, highly-compensated companies are commonly viewed as the pinnacle of software engineering.
Whether that's a fair or accurate assessment is a different question.
Because of the democratization of "big data" and the (relatively) recent uptick in large internet services, serious scale is an engineering challenge that a few have been tackling for awhile, but many are facing for the first time. Think any company that has recently realized their data needs are bigger than what Excel can handle.
The joy I get from writing software comes from creating and using good abstractions. When optimizing for these things, you have to hang up all the fun toys, bring memory bookeeping to the forefront of the codebase, and abstain from nice language features / write things in obtuse ways to squeeze out performance.
I'd much rather solve distributed systems problems with channels and futures and maps at my disposal, than make a C program even less readable for 5% more performance.
Just taste, I guess. Distributed systems are a more interesting problem domain, to me, than throwing away all the nice stuff that's built for us and writing hand-tuned use-case-specific reimplementations. I'm sure both can be (and have been) taken too far.
Also from a personal experience I think their interviews / hiring methods are better than all of the other big players.
I get that devs are supposed to test their own code, but they are surprisingly bad at it overall and unit tests, despite being a great meme, just don't cut it.
Some examples of quality issues: new limit to how many items can be in the start menu. I see bugs/rendering issues in Word for the first time ever (Windows and Mac). Edge is glitch when opening/closing tabs.
The downsides are the mega-corporate culture, with all the bureaucratic dysfunction and vicious internal politics that entails (it's not quite IBM but not for lack of trying), that its famed private offices are gradually shrinking / going away, and the pay is decent but not amazing. And obviously if you rabidly dislike the MS software stack, you won't like it there.
However, one of the largest faults I've seen in my years working is the arrogance. I have personally found startups to be some of the most humble in that regard, they'll push you to make design choices other shops won't have you make, and if you mess up, your job is much more on the line. This humbles many engineers, and in my opinion creates a better culture.
Larger companies breed arrogance, people learn their niche, there's "in breeding" so to speak. Engineers learn and specialize, and believe they are the smartest or most knowledgeable. This will create arrogance. Where as startups will train everyone to be tricks of the trade, masters of none. And people will learn to improve generally.
Not universal, but I find most startups I've interviewed with extremely arrogant. The nicest workplaces for me have been the old and steady companies with boring software.
Things I see a lot in startups: Lack of real world business experience, so terrible management. "we're the best" attitude pervasive in everything. Hyper focused on the technology used over the job at hand. Unrealistic expectations in general. I'm gonna be rich because I'm awesome founders club.
You know, the faulty "If you don't think you're the best, then you never will be" advice everyone seems to believe (not just in startups).
The overwhelming majority of the company are engineers, and they have a large commitment to OSS, which was one of the initial selling points for me. Not to mention, Rasmus Lerdorf works there, and several of their engineers contribute to HHVM.
I would venture to say that this more or less applies at any company of a sufficiently enormous size. It's just hard to generalize.
I will definitely agree with posters here who have said different strokes for different folks. Megacorps of all kinds, regardless of internal culture, are just different from startups.
https://labs.spotify.com/2014/03/27/spotify-engineering-cult... https://labs.spotify.com/2014/09/20/spotify-engineering-cult...
These kinds of problems with Spotify, SpotifyHelper, SpotifyWebHelper etc. have been well-documented for years. It would kill me to work for a company with such low engineering standards.
[1]: https://www.youtube.com/channel/UCO1cgjhGzsSYb1rsB4bFe4Q
Source: close friend is an ex-valver.
I had a year stint at Cloudera working remotely, meeting up with our distributed team 3-4 times/year. I was smitten with the approach they took in implementing 18 different open source project into enterprise big data offerings. They had proper software development lifecycle. There was/is lots of talent and maturity. I absolutely loved my team, the maturity and the culture at Cloudera.
https://www.fastcompany.com/3056662/the-future-of-work/she-c...
If I wanted great pay and cutthroat competition, why wouldn't I just work in finance? The finance industry isn't stupid. They have developer efficiency teams too.
Another example - you were a valuable developer, but got a crippling, chronic disease which makes it harder to concentrate. There is no hope of your productivity ever going back to "reasonable" levels. What is loyalty in this case? Should they still pay you for the years even though you can't contribute?
For your second example, loyalty would be working with the employee to find a more suitable position in the company (or outside of the company) and helping with medical bills and any rehabilitation.
That's completely at odds with Western individualistic culture though hence it's rare here. Netflix is not really an exception - if you are the "weakest link", they will just fire you after your yearly review instead of waiting for a panic fire of bottom 10-20% of staff when stock price plummets (like most other corps do).
[1] http://www.slideshare.net/reed2001/culture-1798664/40-The_Ra...
I think it is more enjoyable to work with people who are competent and performing well, so keeping poor performers around hurts the morale of other employees. Plus, the caliber of people Netflix hires can easily find another job where they'll be a better fit, so showing them "loyalty" by keeping them around probably hurts them as well.
It's a very collaborative environment and requires that each person is good at figuring out what's important to work on. For those suited to it, it's a hard place to beat.
The degree to which Twitter open-sources its work is another thing that I like.
They have amazing engineers, contribute a ton to open source, their devs travel around the world, write blogs and generally do really cool stuff. They put emphasis on clean code, maintainability and testing.
I don't think there's a faster way to send me running away screaming. I'd actually take "100% Visual Basic" over "100% Pair Programming" if I had to choose one at gunpoint.
I was skeptical. Now I greatly prefer it. It would take a ludicrous raise to shift me to a company that doesn't do it as a regular practice.
Pivotal is a for-profit company. We pair program because we think it's more effective for most engineering activities (not all: most) than soloing.
I'm vastly more productive in a pair. I don't take 3 hour "5 minute" Facebook breaks. If I get stuck, my pair usually has an idea, so rather than spending a day fighting I spend minutes. Usually the discussion with a pair comes to a better design, sooner, than nutting it out by myself. Working with a pair makes me accountable -- I am far less tempted to take shortcuts with tests, code, readability, design or other important properties.
Many folk will say well gosh, they don't need a pair for these things. I envy you, brave superhuman. I have ADHD and the crippling disability of being merely mortal, so pairing is awesome for me.
As an introvert I don't think I could handle the "pair all day" approach.
The literature is, I believe, pretty thin and equivocal. However the suspicion is that pair programming is pretty much the core loop of bouncing back and forth, reduced to the smallest possible size.
It also avoids some of the antipatterns I've seen with code reviews -- widely distributed patches, reviews getting stale because they were too hard for a Monday, then a Tuesday... then a Friday ...
> As an introvert I don't think I could handle the "pair all day" approach.
You can take a break if you need one. Lunchtime is fixed at an hour. I typically go and spend it alone with a book.
There is sometimes a confusion between intro/extraversion and sociability. I'm quite sociable, I genuinely like talking to people, but it drains me because I lean towards introverted. So the lunchtime recharge is very helpful.
Each pair finds their own balance.
At some point you're going to need more than one person to understand the code and they either go through that learning process months down the road or right now when they can be most useful in shaping that code.
It's not simple mathematics.
That said, I never much enjoyed using Pivotal Tracker, and Trello seems to do more or less everything it does but in a nicer and more client-friendly way.
Trello is a good tool. I've seen it used on several teams in roles that Tracker doesn't neatly fill.
Most places you work have one or two people who really care. They care about people. They care about process. They care about technology, software design, about doing the right thing the right way.
At Pivotal that's everyone. I've yet to meet a single example of the shrugging "eh, it's just a job" archetype I've previously found elsewhere.
It's so incredibly hard to create this kind of a self-reflective, self-correcting culture. Pivotal's done it and under conditions of enormous growth.
Really. It's the best job I've ever had, by a country mile.
Edit: one more marker.
People come back to Pivotal. It's the first company I've seen with reverse attrition. It's common for Pivots to head to other companies and then come back in less than a year. There's no bridge-burning: if you head out from Pivotal to do something new, you leave as a friend and you can return as one.
Reverse attrition doesn't mean anything.
On the flipside, we absolutely smash out the work here. I love being able to finish stuff every day, every week.
I'd love to work there but dont know what I can do.
Facebook has an incredibly high hiring bar. I never once met someone who I didn't feel was qualified to be there. I was seldom the smartest person in the room.
The high average engineer quality allows the company to give developers almost complete autonomy. At Facebook, you not only get to choose your team, but once you're on that team, you, not some PM or manager, decide what to work on. You're evaluated on impact twice a year, and Facebook has an expansive and nuanced understanding of "impact" that rewards things like developer productivity improvements, side projects, and removal of bad code.
Facebook encourages cross-team collaboration in a way that Google only dreams of doing. There's a single codebase unified under "fbsource", of course, but also a lack of OWNERS files. That means that it's your job as an engineer to decide what code to add, not some team of blessed approvers. There's no readability process. Teams are trained to expect people from all over the company to contribute code. It's a dream job if you want to wear lots of different hats, or if you have a maniacal obsession with following a problem to its root cause and fixing it.
One engineer famously traced a sporadic failure to a single bad register on a single core on a single server. He was recognized for it too: Facebook has a "fix of the week" program that highlights heroic fixes and clever hacks.
Facebook management "gets it" in a way I haven't seen anywhere else. Developer productivity is paramount. When something goes wrong, management doesn't overreact. The general ethos is to apply tooling to make developers better, not to add process to make developers slower.
Best of all, Facebook is fun. The code review tool, Phabricator, has built-in meme support! The internal Facebook groups are full of interesting discussion and trolling (of the good sort). The people there all feel like, well, characters. They're memorable in a way I haven't seen at other technology companies.
Best of all, at Facebook, there's none of the insufferable technical grandstanding you see at other companies. It's hard to describe --- at other companies, people with just enough competence to be annoying regularly create elaborate word-salad design documents that would fit right in at /r/iamverysmart. At Facebook? People say what needs to be said.
The most striking thing about Facebook is how it does more with fewer developers. At Facebook, you feel incredibly productive. There's always enough to do. Teams are much smaller than equivalent teams at other companies, but somehow move faster. Management trusts you --- I never once heard "you can't check that in: the technical risk is too great".
Oh, and the pay is fantastic, especially if you demonstrate extraordinary impact.
Is Facebook perfect? Of course not. After all, I'm not there anymore. Some people ragequit. The company is growing more corporate over time, little by little. Traffic in MPK is nasty. Traffic in SEA is worse. The tooling has some room for improvement --- but you're welcome to send patches! The playfulness isn't for everyone. The open allocation policy sometimes leads to duplication of work, forcing people to discard their hard work. There are few hard rules, and sometimes you don't know where you stand in the power structure.
All that said, I'd go back to Facebook in a millisecond if circumstances lined up. Despite Facebook's flaws and its inevitable slow decline, it's still the best fucking engineering culture on earth right now.
One question: how much emphasis is placed on day-to-day visibility? Is it legitimate to hide in a corner for a few weeks trying something out?
Yes.
> massive refurbished warehouses
I wouldn't say "warehouses" --- the visual design is quite good, with a modernist bent. Frank Gehry designed the last few new offices.
But yes, the offices are very open. Fortunately, you don't have to be there in order to code.
I think the expectation is that you just be an adult about your work habits. Make sure that you're not slowing down the people you work with. It's up to you to figure out how to do that. One strategy is to just be in the office, but there are other options too.
(I'd say "teammates", but close collaborators aren't necessarily teammates at FB. You might work closely with someone every day and share only Zuck as the lowest common manager.)
Facebook culture also has a big social aspect. I think I made more personal friends at Facebook than I made in the entire rest of my career. One downside (according to some people) of this effect is that Facebook tends to become your social life. Personally, I appreciated the personal relationship formation, since it's rare to see so many smart people in one place.
Large tech firms:
================
Google, Deepmind
Microsoft, Skype, Yammer
Palantir Technologies
Bloomberg
Start-ups
=========
Improbable.io
Swifkey
Hailo
VisualDNA
Editd
State
Opengamma
Duedil
…and plenty more good ones in stealth.
Gaming:
======
Mind Candy
EA Games (Playfish)
Playfire
Foundry
…and the list can go on forever.
Not software engineering firms, but have plenty to offer software engineers:
Investment banks:
================
Morgan Stanley
Goldman Sachs
JP Morgan
Barcap
....and plenty more.
Tech-driven funds:
=================
Man AHL
G-Research
KCG (Getco, Knight, Automat)
…any plenty more you've probably never heard of.
They rebranded to "Edited", but I can confirm that they have an amazing culture.
Actually, I haven't seen many poor organizations produce good software, lots of good organizations produce bad software.
For example, when I worked for IBM in the 90s, the organization (in Austin anyway) was great, but they couldn't get anything to market that wasn't garbage.
People give regular tech and non-tech talks, at weekly and monthly events. There is a lot of good stuff given by smart people.
The engineering culture here has been formed by years of bringing modern software practices to clients in industries where quality is important, like banks, airlines, government. There's a lot of great knowledge here, although sometimes I feel that it's a bit too inward facing. For example many many talks are given internally but not so much in the wider community.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newswelcome.html
We detached this comment from https://news.ycombinator.com/item?id=13316569 and marked it off-topic.
About monthly, the supermarket's tech leads, myself, a project manager working with me, and anywhere up to about ten Infosys employees would meet up physically in the supermarket's offices. Only one of the Infosys employees would ever address the table, and rarely at that. The others all had identical laptops (perhaps even identical clothes?), and all took notes during the meeting, but never spoke, apart from just occasionally to mutter quietly to each other.
It was absolutely surreal. Needless to say, the integration did not go especially smoothly.