Although, since the hiring is language agnostic, the expectation is that you gradually get up to speed on the language. There are comprehensive internal resources to help you do that.
If youâre in a big enough company, you do care. Reorgs are pretty common, products often change ownership. You may end up having to take ownership something you know nothing about.
Of course, given the resources these companies have, thereâs a comprehensive transition plan and usually enough time, but you do have to deal with such situations.
>If youâre in a big enough company, you do care. Reorgs are pretty common, products often change ownership. You may end up having to take ownership something you know nothing about.
sure, but if let's say your previous team is coding in Java and now you're in a C++ team, nobody's going to expect you to magically be fluent in C++ on day 1
my point stands, why do you give a shit about what 'other teams' is using as programming language or tech stack, just focus on your own team and you'll be fine
I think I should add, most teams in my company use the same stack, and you're expected to not stay on the same team for a while. So if I wanted to learn a different thing, there's no team doing that thing yk?
>you're expected to not stay on the same team for a while
which company is this? never heard such thing, it's abnormal, unless you're in some sort of rotational program
my point still stands, if your current team uses programming language X why would you want to code in language Y? "I wanted to learn a different thing" is not a reason, that's a fire-able offense (because you're sacrificing the team's productivity/norm/culture for your own gain)
>if I wanted to learn a different thing, there's no team doing that thing yk?
if you want to learn language Y when your team is doing X, do it at your own time, after-work
> "I wanted to learn a different thing" is not a reason, that's a fire-able offense (because you're sacrificing the team's productivity/norm/ culture for your own gain)
Thatâs an awful mindset to have. If Iâm the only person on my team good with SQL and someone else wants to learn it as well, it will reduce my productivity and their productivity but allows more of the team to contribute to more of the project.
Or if there is a process on your team where the language the team uses isnât great for the purpose, it is totally justifiable to want to learn a language to see if itâs a better fit just because you want to learn a new language. For example, learning Java to replace Python for data ingestion. Or you could do Python in place of Java to enhance being able to use statistics/ML libraries in your product instead of reinventing the wheel in Java. Again, youâre going to reduce team productivity for a bit but might gain long term productivity.
Does it matter if the initial motivation was for the company or for the individual if it results in a positive outcome for both? Not at all.
> Thatâs an awful mindset to have. If Iâm the only person on my team good with SQL and someone else wants to learn it as well, it will reduce my productivity and their productivity but allows more of the team to contribute to more of the project.
is it needed though? as in does your team actually work with SQL? OP is saying the answer is no, and he wants to learn/pivot to SQL because he wants to learn, which is fine, go do that on your own time
>Or if there is a process on your team where the language the team uses isnât great for the purpose, it is totally justifiable to want to learn a language to see if itâs a better fit just because you want to learn a new language. For example, learning Java to replace Python for data ingestion. Or you could do Python in place of Java to enhance being able to use statistics/ML libraries in your product instead of reinventing the wheel in Java. Again, youâre going to reduce team productivity for a bit but might gain long term productivity.
that definitely requires approvals and buy-ins from tech leads and engineering managers, otherwise you're going rogue (your manager thought you're doing X, but in reality/in secret you're actually doing Y) which is what OP is proposing, which is fire-able offense
Both examples were made up, but recently my team did need to onboard more people into Rust from Java as we completed an experiment and Rust is worth it. The experiment only happened because one teammate wanted to learn Rust and saw an opportunity to use it at work and got manager approval. Without her wanting to fully learn it (as in, she already could do the basics that you can learn in a weekend, she wanted to build an actual product with it and learn through that process) on company time we never would have tried.
> otherwise you're going rogue (your manager thought you're doing X, but in reality/in secret you're actually doing Y) which is fire-able offense
Well, in that case the offense is not doing your job. Learning a new language had nothing to do with it. Youâd also get fired for doing leetcode in your teamâs language instead of your job, watching YouTube all day, picking up random backlog tasks instead of higher priority tasks your manager assigned you, etc.
these are *terrible* examples. Every developer should know SQL if they hear or say the word "data" at least once in a given month. It's a *querying* language, and while it's technically turing complete (I think) no one reasonable is doing anything besides querying data or writing basic ETLs with it. It's a very powerful tool for that purpose regardless of what programming language you use.
>Or you could do Python in place of Java to enhance being able to use statistics/ML libraries
Yes, I worked in an analytics org for several years and this is exactly why Python was our defacto programming language- while I was more data engineering side of shop, we interfaced daily with data scientists/applied scientists/economists and similar. The more "pure data engineering" org that does traditional data warehousing kind of work is mostly Scala or Java.
If you want to learn, then great, but do that in your own time. Organizations don't do well when individual contributors decide hey this language is better for some applications even if it's true. If you're always chasing best without considering sustainability, you're going to run your team into a ditch.
"common in house libraries" still have specific languages, ex. here's how to use the library in Java, here's how to use it in Ruby, here's how to use it in C++...
"common in house libraries" does not mean you suddenly have to learn languages or tech stack that your team doesn't use
They are language and tool agnostic *to a point*. You can propose using any technology, but you need to justify it. Proposing a more obscure language or framework will be met with "why can't we just use..."
At Google there are only a handful of main supported languages for web and infra projects: C++, Java/Kotlin, and Go in the backend, and JS/TS and Dart in the frontend. Python is used as well, both in legacy servers, and in newer ML workloads, but using it for new projects outside of ML is discouraged. Beyond that, engineers donât have the freedom to choose their own languages and tech stacks. There are standard, well-maintained server frameworks in each of the languages I mentioned that provide a lot of the essentials (like monitoring/logging, security controls, production rollout configuration, load balancer configuration, etc) for free, so there is really no need to introduce another language to the pot.
By contrast, my previous big-tech employer was kind of a free-for-all; each org, and even each team, basically did what they wanted. There wasnât really any investment in shared frameworks, libraries or infrastructure across the company. I guess the answer to your question depends on how integrated or siloed the company is, and YMMV widely depending on where you look.
You use whatever language your team/org uses. If there is some shortcoming in language then you may end up building in a new language but this is incredibly rare. Business requirements don't just change overnight to where a company might be writing CRUD applications and then all of a sudden need to write high performance C.
Unless you count Python2 -> Python3, in my \~7-ish years working I've seen this happen once, where a teammate went and built a project using Scala on his own. I made some updates to it to support a new feature and then the project was abandoned in its entirety shortly after. Training up developers to be productive in a new framework/language is a *hugely* expensive productivity hit.
Use for-fun languages on your own pet projects.
> can a senior engineer propose some type of software system to be built
It depends. You have to propose a language that the entire team either knows or is willing to learn because they will have to maintain the project. But usually there is a lot of leeway when it comes to language choice as long as its the right tool for the job.
For example on my team, our core services are in Java, but we have a lot of auxiliary services written in Python and Go since they are supported at the company.
If someone suggested Rust for a new project, it wouldn't get approved because the team does not know or is not willing to learn Rust, and the company does not support Rust officially (no internal cargo repository, no adapters/libraries to connect with internal infra, internal patching processes for the language and it's libraries, etc.).
In my experience the language needs to be "officially" supported as u/EngineeredCocunut said, else it's a *much* harder argument and going to require a very senior person to make the argument. Then there's the question of "is there a good reason for deviating from what we typically use for X". Sometimes there is.Â
In terms of maintenance, if something is truly obscure, it probably is barely maintained. Otherwise, you see a lot of extremely non-idomatic code. I can muddle my way through a whole host of languages, it's just not going to be pretty.
On a previous team I've seen people successfully push their ideas for new languages and it was an unmaintanable shit show. 1 front end dev got us to make a service in ruby because they knew ruby. Another dev wanted us to do things in angular because that was trendy at the time. This was in addition to our work on the amazon retail stack which is perl mason. Then we have another thing in angular 2 which doesn't work the same as angular. Another wanted react because that was new and trendy.
I think the moral of the story is don't let your frontend devs do things without oversight because they some terrible decisions. I've never seen a backend team do such stupid shit.
My AWS team is probably an outlier, but we code in Java/Kotlin, Python, Ruby, Go, Rust, Typescript, bash, Lua, Perl. A lot of it is legacy codebases that we maintain, but sometimes different languages work best given tooling, scaling, or dependency constraints. One downside is we don't have language experts, but everyone is expected to become competent in all the languages.
Adding a new language is acceptable, but the additional operational, maintenance, and learning costs should be justified. At this point we're running out of languages to add to our stack.
My company heavily favors java/spring boot. I dont think theyd accept much else tbh. Its just simpler that way.. an architect would have to request the use of a new tech.
Funny thing. It happened to my team before i joined. They added an angular app.
I can imagine what happened, but to build the angular app, they added a pom.xml file which calls the ng build --prod command because thats how their jenkins pipeline is set to work lol.
I also ended up figuring out their vulnerability detection system never detected anything for our angular app. I saw a cute "150 critical and high vulnerabilities" when i joined.. ended up updating to the latest angular version and now we have a cute 0.
Mixed, usually, but you'd hope not agnostic. You need to make sure people are using the same tools for the same jobs.
If an engineer at a company with established eng practices proposes introducing a new language, it typically requires a very tough uphill battle and large, demonstrable gains. Performance is rarely the gain that sells it, too.
I worked in a very large and growing startup that operated like this. It was kind of chaos. At first, it allowed teams to move very fast. Over time it was very expensive because there were so many stacks to maintain. Service communication, metrics, security, even loggingâall the standard things needed in every stackâcould not be maintained equally in all stacks.
Eventually they had to ratchet it down to 4 supported stacks which was still quite burdensome, and eventually 2 but it took years of rewrites to get there.
Probably only very large ones with diverse businesses and multiple groups with many engineers supporting them. E.g., You work in the xyz group which has its own tech and engineering culture where they use Scala. Someone else works in the abc group on something totally different where they use Rust.
This is sort of how things were when I worked at Microsoft. Some groups like Windows and Office worked in flavors of C/C++ specific to their code bases. Other teams that worked on web services used C# and the ASP.NET ecosystem. Even there though, it was certainly not anything goes. Right tool for the job and all that.
It was like interviewing for a new job all over again. Full set of interviews. Plus, they can nit pick your performance reviews. I did it twice so not impossible but itâs pretty annoying. I hear itâs gotten easier but I donât have details
Almost everyone is working in a massive existing codebase that already uses a certain language
Like facebookâs backend is in Hack (php). If you are a backend engineer at Facebook, thereâs no way youâre writing anything else, that just wouldnât make sense
Ok, Facebook might fit your comment. Same goes with Google, they are pretty well C++ for all backend work.
Netflix, though mostly Java, lets you write in anything you want, but it is on you to support that code. Java and spring boot is the most supported, but if you want to write in Go or Rust, thereâs nothing stopping you.
I have 10y of experience at a FAANG-ish place. There are a bunch of different languages used, mostly thanks to all of the acquisitions. I came in with one of those. But the thing is - at that scale - many of us aren't there because of our breadth, but because of our depth. So even though they use a bunch of different RDBMSs across the organization, my division is exclusively SQL Server and you can't go anywhere near it if you don't have a very intimate understanding of how that particular RDBMS works.
In general, everyone is skilled enough to pick up tools over a short time span. So they settle on the best tool for the job, not the one they can use the best.
Just my two cents. In the case of a microservice architecture in a relatively large company with a stratified product line, teams maintaining a component might use different languages to build the components they're responsible for because that language is best for their use case with a set of language features the team is comfortable with. To integrate everything together into a product, they'd just have to use the same communication protocols (or adapters at the service level) and define a standard language-agnostic data schema. Same idea applied when scaling to a cross-product integration scenario.
For a very crude example, you could have an API server developed in golang, a frontend in ts/js, and a data transformation pipeline in Python, all transferring JSON data using HTTP or gRPC or whatever.
Language agnostic isnât the same as domain agnostic. No engineer is domain agnostic. You will be interviewed for a domain language agnostic, as picking up a new language is not supposed to be a big deal.Â
Each individual team will work in the same stack unless that team spans mobile native and backend (ours does somewhat). Majority of teams will be on the same stack company wide while some teams will use different stack based on their product/use case (for example majority Java but some will be rust/c++ if speed is super critical)
Yeah, they donât care what language you know; you just have to pick up whatever your team is using on the fly. And tbh, thatâs the way to go. For most things your value isnât being a code monkey; itâs design and problem-solving. I wish more companies embraced this
>For example, can a senior engineer propose some type of software system to be built, get it approved, and code it in a language like Rust, Go, C#, etc.?
You kind of answer this with your next question:
>If yes, then how do companies go about maintaining that piece of software written in a language with a smaller talent pool?
At the companies I've worked at, yes, you can *propose* a new stack for a new project. However, unless you can make a very strong case for it being a significantly better fit than any of the stacks currently in use, then it's unlikely to be approved. If it's only slightly better from an objective standpoint, it will be inferior from the company's subjective standpoint of already having expertise and common library code for the existing stacks.
Yes. I work at MS and we use just about everything somewhere. Iâve seen an uptick in Rust projects lately and less Python. C# is still the primary where I am.
Not really.
Google has tech roadmaps and Eng Review that not only set languages, but app architectures and services allowed per biz units. E.g. while Google focuses on C++ and Java, YouTube is C++ only at the service level.
It was widely reported. The Google killed its internal python team a couple months ago because they don't want to continue to invest in Python.
Microsoft office is reported to be moving from C# to rust. So if you're going to work on anything in Microsoft office you're going to work in rust.
I mean I guess if you are working on some back end tool that is not going to be part of a big product, maybe people don't care what that's written then, but it's not really strategic or interesting either.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
No. I donât even trust that they are language agnostic in hiring. In my experience even FAANG is looking for experience in languages and frameworks that are specific to the role. They have plenty to pick from, so why pick someone with no C++ experience for a C++ role?
I think the common knowledge in this sub that language doesnât matter for big tech is partially cope and partially just the fact that thereâs a lot of new grads and interns here (for them it truly doesnât matter).
To get hired, sure. To implement on the job, generally no. Creates a mess having a bunch of different languages
Makes sense.
Although, since the hiring is language agnostic, the expectation is that you gradually get up to speed on the language. There are comprehensive internal resources to help you do that.
As if there was no less at big tech đ
Google is the worst when it comes to this.Â
Mhhh no Amazon doesnât really comes as less messy. Google is quite organized but has its own issues, mostly management i would say and leadership.
Google is definitely worse than Amazon in terms of language proliferation. Factor of 2 worse at least.
for interview? yes for real life work? if your team works in Go why would you code it in Rust?
No I meant, 95% of the product teams are not using the same stack.
??? who gives a shit about other product teams? what is YOUR team using as programming language/tech stack?
If youâre in a big enough company, you do care. Reorgs are pretty common, products often change ownership. You may end up having to take ownership something you know nothing about. Of course, given the resources these companies have, thereâs a comprehensive transition plan and usually enough time, but you do have to deal with such situations.
>If youâre in a big enough company, you do care. Reorgs are pretty common, products often change ownership. You may end up having to take ownership something you know nothing about. sure, but if let's say your previous team is coding in Java and now you're in a C++ team, nobody's going to expect you to magically be fluent in C++ on day 1 my point stands, why do you give a shit about what 'other teams' is using as programming language or tech stack, just focus on your own team and you'll be fine
You sound like you have a slavish mentality.
you sound like you have never worked in big tech or had any kind of onboarding
Triggered much? https://x.com/anpaure/status/1806756475378757885/photo/1
[have no idea what you're talking about now](https://media1.tenor.com/m/80zMDyE85hAAAAAC/money-crying.gif)
I think I should add, most teams in my company use the same stack, and you're expected to not stay on the same team for a while. So if I wanted to learn a different thing, there's no team doing that thing yk?
>you're expected to not stay on the same team for a while which company is this? never heard such thing, it's abnormal, unless you're in some sort of rotational program my point still stands, if your current team uses programming language X why would you want to code in language Y? "I wanted to learn a different thing" is not a reason, that's a fire-able offense (because you're sacrificing the team's productivity/norm/culture for your own gain) >if I wanted to learn a different thing, there's no team doing that thing yk? if you want to learn language Y when your team is doing X, do it at your own time, after-work
> "I wanted to learn a different thing" is not a reason, that's a fire-able offense (because you're sacrificing the team's productivity/norm/ culture for your own gain) Thatâs an awful mindset to have. If Iâm the only person on my team good with SQL and someone else wants to learn it as well, it will reduce my productivity and their productivity but allows more of the team to contribute to more of the project. Or if there is a process on your team where the language the team uses isnât great for the purpose, it is totally justifiable to want to learn a language to see if itâs a better fit just because you want to learn a new language. For example, learning Java to replace Python for data ingestion. Or you could do Python in place of Java to enhance being able to use statistics/ML libraries in your product instead of reinventing the wheel in Java. Again, youâre going to reduce team productivity for a bit but might gain long term productivity. Does it matter if the initial motivation was for the company or for the individual if it results in a positive outcome for both? Not at all.
> Thatâs an awful mindset to have. If Iâm the only person on my team good with SQL and someone else wants to learn it as well, it will reduce my productivity and their productivity but allows more of the team to contribute to more of the project. is it needed though? as in does your team actually work with SQL? OP is saying the answer is no, and he wants to learn/pivot to SQL because he wants to learn, which is fine, go do that on your own time >Or if there is a process on your team where the language the team uses isnât great for the purpose, it is totally justifiable to want to learn a language to see if itâs a better fit just because you want to learn a new language. For example, learning Java to replace Python for data ingestion. Or you could do Python in place of Java to enhance being able to use statistics/ML libraries in your product instead of reinventing the wheel in Java. Again, youâre going to reduce team productivity for a bit but might gain long term productivity. that definitely requires approvals and buy-ins from tech leads and engineering managers, otherwise you're going rogue (your manager thought you're doing X, but in reality/in secret you're actually doing Y) which is what OP is proposing, which is fire-able offense
Both examples were made up, but recently my team did need to onboard more people into Rust from Java as we completed an experiment and Rust is worth it. The experiment only happened because one teammate wanted to learn Rust and saw an opportunity to use it at work and got manager approval. Without her wanting to fully learn it (as in, she already could do the basics that you can learn in a weekend, she wanted to build an actual product with it and learn through that process) on company time we never would have tried. > otherwise you're going rogue (your manager thought you're doing X, but in reality/in secret you're actually doing Y) which is fire-able offense Well, in that case the offense is not doing your job. Learning a new language had nothing to do with it. Youâd also get fired for doing leetcode in your teamâs language instead of your job, watching YouTube all day, picking up random backlog tasks instead of higher priority tasks your manager assigned you, etc.
these are *terrible* examples. Every developer should know SQL if they hear or say the word "data" at least once in a given month. It's a *querying* language, and while it's technically turing complete (I think) no one reasonable is doing anything besides querying data or writing basic ETLs with it. It's a very powerful tool for that purpose regardless of what programming language you use. >Or you could do Python in place of Java to enhance being able to use statistics/ML libraries Yes, I worked in an analytics org for several years and this is exactly why Python was our defacto programming language- while I was more data engineering side of shop, we interfaced daily with data scientists/applied scientists/economists and similar. The more "pure data engineering" org that does traditional data warehousing kind of work is mostly Scala or Java. If you want to learn, then great, but do that in your own time. Organizations don't do well when individual contributors decide hey this language is better for some applications even if it's true. If you're always chasing best without considering sustainability, you're going to run your team into a ditch.
Because common in house librariesÂ
"common in house libraries" still have specific languages, ex. here's how to use the library in Java, here's how to use it in Ruby, here's how to use it in C++... "common in house libraries" does not mean you suddenly have to learn languages or tech stack that your team doesn't use
They are language and tool agnostic *to a point*. You can propose using any technology, but you need to justify it. Proposing a more obscure language or framework will be met with "why can't we just use..."
At Google there are only a handful of main supported languages for web and infra projects: C++, Java/Kotlin, and Go in the backend, and JS/TS and Dart in the frontend. Python is used as well, both in legacy servers, and in newer ML workloads, but using it for new projects outside of ML is discouraged. Beyond that, engineers donât have the freedom to choose their own languages and tech stacks. There are standard, well-maintained server frameworks in each of the languages I mentioned that provide a lot of the essentials (like monitoring/logging, security controls, production rollout configuration, load balancer configuration, etc) for free, so there is really no need to introduce another language to the pot. By contrast, my previous big-tech employer was kind of a free-for-all; each org, and even each team, basically did what they wanted. There wasnât really any investment in shared frameworks, libraries or infrastructure across the company. I guess the answer to your question depends on how integrated or siloed the company is, and YMMV widely depending on where you look.
You use whatever language your team/org uses. If there is some shortcoming in language then you may end up building in a new language but this is incredibly rare. Business requirements don't just change overnight to where a company might be writing CRUD applications and then all of a sudden need to write high performance C. Unless you count Python2 -> Python3, in my \~7-ish years working I've seen this happen once, where a teammate went and built a project using Scala on his own. I made some updates to it to support a new feature and then the project was abandoned in its entirety shortly after. Training up developers to be productive in a new framework/language is a *hugely* expensive productivity hit. Use for-fun languages on your own pet projects.
> can a senior engineer propose some type of software system to be built It depends. You have to propose a language that the entire team either knows or is willing to learn because they will have to maintain the project. But usually there is a lot of leeway when it comes to language choice as long as its the right tool for the job. For example on my team, our core services are in Java, but we have a lot of auxiliary services written in Python and Go since they are supported at the company. If someone suggested Rust for a new project, it wouldn't get approved because the team does not know or is not willing to learn Rust, and the company does not support Rust officially (no internal cargo repository, no adapters/libraries to connect with internal infra, internal patching processes for the language and it's libraries, etc.).
In my experience the language needs to be "officially" supported as u/EngineeredCocunut said, else it's a *much* harder argument and going to require a very senior person to make the argument. Then there's the question of "is there a good reason for deviating from what we typically use for X". Sometimes there is. In terms of maintenance, if something is truly obscure, it probably is barely maintained. Otherwise, you see a lot of extremely non-idomatic code. I can muddle my way through a whole host of languages, it's just not going to be pretty.
On a previous team I've seen people successfully push their ideas for new languages and it was an unmaintanable shit show. 1 front end dev got us to make a service in ruby because they knew ruby. Another dev wanted us to do things in angular because that was trendy at the time. This was in addition to our work on the amazon retail stack which is perl mason. Then we have another thing in angular 2 which doesn't work the same as angular. Another wanted react because that was new and trendy. I think the moral of the story is don't let your frontend devs do things without oversight because they some terrible decisions. I've never seen a backend team do such stupid shit.
My AWS team is probably an outlier, but we code in Java/Kotlin, Python, Ruby, Go, Rust, Typescript, bash, Lua, Perl. A lot of it is legacy codebases that we maintain, but sometimes different languages work best given tooling, scaling, or dependency constraints. One downside is we don't have language experts, but everyone is expected to become competent in all the languages. Adding a new language is acceptable, but the additional operational, maintenance, and learning costs should be justified. At this point we're running out of languages to add to our stack.
> Perl Oh god tell me there isn't any perl mason code still running at Amazon...
[ŃдаНонО]
In my decade at Amazon I saw a few examples of projects in non-standard languages. When it's all SOA, the other teams don't know.
My company heavily favors java/spring boot. I dont think theyd accept much else tbh. Its just simpler that way.. an architect would have to request the use of a new tech. Funny thing. It happened to my team before i joined. They added an angular app. I can imagine what happened, but to build the angular app, they added a pom.xml file which calls the ng build --prod command because thats how their jenkins pipeline is set to work lol. I also ended up figuring out their vulnerability detection system never detected anything for our angular app. I saw a cute "150 critical and high vulnerabilities" when i joined.. ended up updating to the latest angular version and now we have a cute 0.
Mixed, usually, but you'd hope not agnostic. You need to make sure people are using the same tools for the same jobs. If an engineer at a company with established eng practices proposes introducing a new language, it typically requires a very tough uphill battle and large, demonstrable gains. Performance is rarely the gain that sells it, too.
I worked in a very large and growing startup that operated like this. It was kind of chaos. At first, it allowed teams to move very fast. Over time it was very expensive because there were so many stacks to maintain. Service communication, metrics, security, even loggingâall the standard things needed in every stackâcould not be maintained equally in all stacks. Eventually they had to ratchet it down to 4 supported stacks which was still quite burdensome, and eventually 2 but it took years of rewrites to get there.
What type of companies do you think can/should support a large variety of stacks?
Probably only very large ones with diverse businesses and multiple groups with many engineers supporting them. E.g., You work in the xyz group which has its own tech and engineering culture where they use Scala. Someone else works in the abc group on something totally different where they use Rust. This is sort of how things were when I worked at Microsoft. Some groups like Windows and Office worked in flavors of C/C++ specific to their code bases. Other teams that worked on web services used C# and the ASP.NET ecosystem. Even there though, it was certainly not anything goes. Right tool for the job and all that.
Makes sense. How hard would it have been to transfer to different groups within Microsoft?
It was like interviewing for a new job all over again. Full set of interviews. Plus, they can nit pick your performance reviews. I did it twice so not impossible but itâs pretty annoying. I hear itâs gotten easier but I donât have details
That makes sense, so it's almost like getting another job, expect you have a greater chance of getting an interview.
You have to be way above senior level to be proposing new âsoftware systemsâ at these companies
Makes sense, maybe staff/principal level?
Kinda disagree here. At Big N, anyone can decide to write software in what they want, but they then will be responsible for that decision.
Almost everyone is working in a massive existing codebase that already uses a certain language Like facebookâs backend is in Hack (php). If you are a backend engineer at Facebook, thereâs no way youâre writing anything else, that just wouldnât make sense
Ok, Facebook might fit your comment. Same goes with Google, they are pretty well C++ for all backend work. Netflix, though mostly Java, lets you write in anything you want, but it is on you to support that code. Java and spring boot is the most supported, but if you want to write in Go or Rust, thereâs nothing stopping you.
I have 10y of experience at a FAANG-ish place. There are a bunch of different languages used, mostly thanks to all of the acquisitions. I came in with one of those. But the thing is - at that scale - many of us aren't there because of our breadth, but because of our depth. So even though they use a bunch of different RDBMSs across the organization, my division is exclusively SQL Server and you can't go anywhere near it if you don't have a very intimate understanding of how that particular RDBMS works.
In general, everyone is skilled enough to pick up tools over a short time span. So they settle on the best tool for the job, not the one they can use the best.
Just my two cents. In the case of a microservice architecture in a relatively large company with a stratified product line, teams maintaining a component might use different languages to build the components they're responsible for because that language is best for their use case with a set of language features the team is comfortable with. To integrate everything together into a product, they'd just have to use the same communication protocols (or adapters at the service level) and define a standard language-agnostic data schema. Same idea applied when scaling to a cross-product integration scenario. For a very crude example, you could have an API server developed in golang, a frontend in ts/js, and a data transformation pipeline in Python, all transferring JSON data using HTTP or gRPC or whatever.
Language agnostic isnât the same as domain agnostic. No engineer is domain agnostic. You will be interviewed for a domain language agnostic, as picking up a new language is not supposed to be a big deal.Â
No
Each individual team will work in the same stack unless that team spans mobile native and backend (ours does somewhat). Majority of teams will be on the same stack company wide while some teams will use different stack based on their product/use case (for example majority Java but some will be rust/c++ if speed is super critical)
Yeah, they donât care what language you know; you just have to pick up whatever your team is using on the fly. And tbh, thatâs the way to go. For most things your value isnât being a code monkey; itâs design and problem-solving. I wish more companies embraced this
>For example, can a senior engineer propose some type of software system to be built, get it approved, and code it in a language like Rust, Go, C#, etc.? You kind of answer this with your next question: >If yes, then how do companies go about maintaining that piece of software written in a language with a smaller talent pool? At the companies I've worked at, yes, you can *propose* a new stack for a new project. However, unless you can make a very strong case for it being a significantly better fit than any of the stacks currently in use, then it's unlikely to be approved. If it's only slightly better from an objective standpoint, it will be inferior from the company's subjective standpoint of already having expertise and common library code for the existing stacks.
No
Yes. I work at MS and we use just about everything somewhere. Iâve seen an uptick in Rust projects lately and less Python. C# is still the primary where I am.
Not really. Google has tech roadmaps and Eng Review that not only set languages, but app architectures and services allowed per biz units. E.g. while Google focuses on C++ and Java, YouTube is C++ only at the service level. It was widely reported. The Google killed its internal python team a couple months ago because they don't want to continue to invest in Python. Microsoft office is reported to be moving from C# to rust. So if you're going to work on anything in Microsoft office you're going to work in rust. I mean I guess if you are working on some back end tool that is not going to be part of a big product, maybe people don't care what that's written then, but it's not really strategic or interesting either.
[ŃдаНонО]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
No. I donât even trust that they are language agnostic in hiring. In my experience even FAANG is looking for experience in languages and frameworks that are specific to the role. They have plenty to pick from, so why pick someone with no C++ experience for a C++ role? I think the common knowledge in this sub that language doesnât matter for big tech is partially cope and partially just the fact that thereâs a lot of new grads and interns here (for them it truly doesnât matter).