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.
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.
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
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.
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?
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.
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.
I visited Atlassian's Sydney office.
There was a sign on the fridge in the kitchen attached to a function space that had 'guidelines you've had too much to drink'
Included on the list was 'if you're slurring your words, you've had too much to drink' as well as 'if you've started making unwanted advances towards colleagues, you've had too much to drink'.
The fact that
1) They had a sign telling you not to sexually harass your coworkers
2) It happened so often that they NEEDED TO PUT UP A SIGN telling people not to do it any more
made me decide I probably didn't want to work there.
(This was 2015, maybe things have gotten better?)
* (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.
The people I talk to, from Microsoft. Disagree. The politics are brutal and the infrastructure brittle and constantly changing (with all the overhead and oversight of a high-security industry like finance) until nothing really gets done.
That's true of the political battles at any large company. However, the question is asking about engineering 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.
"Microsoft" isn't really a valid answer to the question in my opinion. The company is huge and culture varies greatly from org to org and team to team.
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)
I've often thought, would it be useful to create a "Paul Graham Test" based mostly on the essays "Great Hackers" and "Maker's Schedule, Manager's Schedule" as an analogue to the Joel Test. It reinforces some parts of the Joel Test, particularly the unequivocal importance of private offices.
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 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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Basically, yes; that is, their strategy is not to avoid taking multiple simultaneous efforts at solving the same broad class of problem, even if it is one where in the long term there is unlikely to be a reason to keep multiple solutions, and they also aren't afraid to take stabs at solving problems where they need a solution to exist but don't strategically need to own the solution.
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.
I recommend reading the Cliff Notes for "The Origin of Wealth" (the full book is just too damn long). Sometimes product designs with a devout following still fail the product market fit test. Trying a bunch of things to see what sticks is a pretty valid strategy, it's what nature does. Steve Jobs would just convince you of your folly for wanting anything but a one button mouse, but Eric, Larry, and Sergey would offer you mice with 1-10 buttons, hover mice, eyeball tracking systems that act as mice, a laser pointer mouse, etc. Each is a small fixed cost and if there's product market fit, the winning variant pays for all the others...
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.
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.
I ask if a company uses a monorepo as one of the ways to decide to pass on them if they do. Definitely not an indicator of good engineering practices in my opinion.
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.
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.
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
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.
71 comments
[ 2.7 ms ] story [ 135 ms ] threadThere'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?
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
- 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
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.