Switching from data science to software engineering at age 36
November 29, 2021 11:14 PM Subscribe
I've been a data scientist for 4 years and am looking at transitioning to software engineering in the next year. Looking for input on how feasible this is overall, and general guidance.
I've been a DS who's always preferred the coding part of the job over other aspects. I'm a decent Python programmer (creating my own libraries, using OO) but never formally studied CS (majored in aerospace engineering). I think it'd make sense for me to switch to SWE, for more money and more work that I actually like. I've got a rough plan to do this taking 6-8 months, involving studying data structures & algos and working with an online bootcamp. I plan to Leetcode and do mock interviews extensively. I've googled this a fair amount and spent time sifting through HN and Blind, but was curious to see what MeFi might have to say. So, questions...
1. Is 36 too old to get started in this, realistically? How much age discrimination might I encounter? I have a life and can't work long nights, weekends frequently, like some new grads. Once in a while is fine. I also don't want to go into management at 40.
2. How hard will it be to break into entry-level SWE positions, overall? I've heard it is really competitive right now. I've also heard of people transitioning in as mid-level SWEs (less competitive), but that it takes more work (system design studying it seems).
3. Should I time it so that I'm applying in the fall to get into the new grad hiring cycle?
I'm hoping to get into a stable tech company in the Seattle area, if that matters any. Doesn't need to a big name like MS, there are places like DocuSign, DomainTools, others that I'd be content with. Really just want a job that is programming-centric that pays more than data science.
I've been a DS who's always preferred the coding part of the job over other aspects. I'm a decent Python programmer (creating my own libraries, using OO) but never formally studied CS (majored in aerospace engineering). I think it'd make sense for me to switch to SWE, for more money and more work that I actually like. I've got a rough plan to do this taking 6-8 months, involving studying data structures & algos and working with an online bootcamp. I plan to Leetcode and do mock interviews extensively. I've googled this a fair amount and spent time sifting through HN and Blind, but was curious to see what MeFi might have to say. So, questions...
1. Is 36 too old to get started in this, realistically? How much age discrimination might I encounter? I have a life and can't work long nights, weekends frequently, like some new grads. Once in a while is fine. I also don't want to go into management at 40.
2. How hard will it be to break into entry-level SWE positions, overall? I've heard it is really competitive right now. I've also heard of people transitioning in as mid-level SWEs (less competitive), but that it takes more work (system design studying it seems).
3. Should I time it so that I'm applying in the fall to get into the new grad hiring cycle?
I'm hoping to get into a stable tech company in the Seattle area, if that matters any. Doesn't need to a big name like MS, there are places like DocuSign, DomainTools, others that I'd be content with. Really just want a job that is programming-centric that pays more than data science.
Best answer: I can't really speak to the expectations of the Python market, or Seattle, but my read as a developer is that you're in a reasonable place to transition with your Python experience. Your data familiarity will be, naturally, pretty useful.
While data structures and algorithms is mostly to succeed at the interview, the big question I'd want to know is whether you can build a semi-complicated piece of work that involves multiple classes and makes some intelligent choices when it comes to design. For that reason, I'd suggest focusing on Leetcode and similar, and I'd imagine your existing experience with the gaps filled might justify going for mid-level positions.
posted by Merus at 11:34 PM on November 29, 2021 [5 favorites]
While data structures and algorithms is mostly to succeed at the interview, the big question I'd want to know is whether you can build a semi-complicated piece of work that involves multiple classes and makes some intelligent choices when it comes to design. For that reason, I'd suggest focusing on Leetcode and similar, and I'd imagine your existing experience with the gaps filled might justify going for mid-level positions.
posted by Merus at 11:34 PM on November 29, 2021 [5 favorites]
>Really just want a job that is programming-centric that pays more than data science.
It's never too late to change if you want a different kind of challenge, but you're probably underpaid as an experienced data scientist in the Seattle area. Maybe a change of employer will also allow you to renegotiate salary levels. For the transition, are you really going to earn more as a junior software engineer than an experienced data scientist, or is this about eventual seniority and eventual earning levels?
I think your sales pitch is that you're gold dust: someone who knows what data scientists need and can work with software teams to build it, a great place to be in making relevant tools, as more organisations get to grips digitising their decision-making processes, they will need to gather data and to process it for operational insights.
Good luck. and I hope you have every success with this change!
posted by k3ninho at 12:45 AM on November 30, 2021 [5 favorites]
It's never too late to change if you want a different kind of challenge, but you're probably underpaid as an experienced data scientist in the Seattle area. Maybe a change of employer will also allow you to renegotiate salary levels. For the transition, are you really going to earn more as a junior software engineer than an experienced data scientist, or is this about eventual seniority and eventual earning levels?
I think your sales pitch is that you're gold dust: someone who knows what data scientists need and can work with software teams to build it, a great place to be in making relevant tools, as more organisations get to grips digitising their decision-making processes, they will need to gather data and to process it for operational insights.
Good luck. and I hope you have every success with this change!
posted by k3ninho at 12:45 AM on November 30, 2021 [5 favorites]
> your sales pitch is that you're gold dust: someone who knows what data scientists need and can work with software teams to build it
another angle could be if you picked up quite a bit of useful domain-specific expertise, and can find a new employer or new team where that domain knowledge could still plausibly be valuable while working in a software engineering role.
while some raw computer science grads might be able to do better on algorithms puzzles, you could try to frame any relevant prior domain experience as a major advantage in helping the team understand what the users or business needs, helping to rapidly resolve ambiguity in requirements in some situations, and having more accurate intuition about where corners can be cut and a quick and dirty approximation is good enough to ship vs where a feature needs to be absolutely rock solid and correct.
probably only plausible if narrowing the search to looking for a software engineering role in the exact same domain you've gained familiarity with.
posted by are-coral-made at 1:48 AM on November 30, 2021 [1 favorite]
another angle could be if you picked up quite a bit of useful domain-specific expertise, and can find a new employer or new team where that domain knowledge could still plausibly be valuable while working in a software engineering role.
while some raw computer science grads might be able to do better on algorithms puzzles, you could try to frame any relevant prior domain experience as a major advantage in helping the team understand what the users or business needs, helping to rapidly resolve ambiguity in requirements in some situations, and having more accurate intuition about where corners can be cut and a quick and dirty approximation is good enough to ship vs where a feature needs to be absolutely rock solid and correct.
probably only plausible if narrowing the search to looking for a software engineering role in the exact same domain you've gained familiarity with.
posted by are-coral-made at 1:48 AM on November 30, 2021 [1 favorite]
Context for my answers is hiring for US-based SaaS web development roles; software engineering is a broad field so this may not apply to every niche.
Is 36 too old to get started in this
Absolutely not.
How hard will it be to break into entry-level SWE positions, overall?
Entry level is extremely competitive now; bootcamps are churning out web developers at an astounding rate right now. (This is not a knock on the bootcamps, we've hired a number of new-to-the-industry people with nothing but a bootcamp to show for experience, and they've all turned out to be talented and productive. I've had much worse luck with CS masters degree holders (they know their algorithms but tend to lack essential practical skills. I need engineers, not theoreticians.)
But you're not entry level; you have four years of experience coding in python -- midlevel engineers are much more difficult to find right now. In your situation I'd be looking for companies that also have a data science team, and position yourself as a developer who can bridge between that and the engineering world.
Should I time it so that I'm applying in the fall to get into the new grad hiring cycle?
Nope, if anything that just puts you up against people with CS degrees for entry-level positions; at higher levels hiring isn't very seasonal (though some companies will have fewer hires toward EOY as they run out of budgeted headcount, then pick up again in January).
posted by ook at 6:40 AM on November 30, 2021 [1 favorite]
Is 36 too old to get started in this
Absolutely not.
How hard will it be to break into entry-level SWE positions, overall?
Entry level is extremely competitive now; bootcamps are churning out web developers at an astounding rate right now. (This is not a knock on the bootcamps, we've hired a number of new-to-the-industry people with nothing but a bootcamp to show for experience, and they've all turned out to be talented and productive. I've had much worse luck with CS masters degree holders (they know their algorithms but tend to lack essential practical skills. I need engineers, not theoreticians.)
But you're not entry level; you have four years of experience coding in python -- midlevel engineers are much more difficult to find right now. In your situation I'd be looking for companies that also have a data science team, and position yourself as a developer who can bridge between that and the engineering world.
Should I time it so that I'm applying in the fall to get into the new grad hiring cycle?
Nope, if anything that just puts you up against people with CS degrees for entry-level positions; at higher levels hiring isn't very seasonal (though some companies will have fewer hires toward EOY as they run out of budgeted headcount, then pick up again in January).
posted by ook at 6:40 AM on November 30, 2021 [1 favorite]
Response by poster: These are really good answers, thanks all. My domain knowledge is mostly aerospace and customer/marketing data. We have ~1m customers at my current company, which is an old school utility. The data I work with is stuff like demographics, usage of our services, surveys. I don't want to go back to aerospace for various reasons, and honestly I'm not sure I want to do stuff with customer data anymore. Ideally I'd like to work on backend...
I guess a potential strength I've had is that I've worked with less technical people my whole career. I've written a lot of code that I try hard to make "practical," where it works and is modular, but less experienced analysts who know python can still modify it. I've helped people put our stuff in production as automated jobs on linux systems, while my team has never used linux. Is there any value in this "bridging" experience in the SWE world, or does everyone already know this?
posted by mnemonic at 10:52 AM on November 30, 2021
I guess a potential strength I've had is that I've worked with less technical people my whole career. I've written a lot of code that I try hard to make "practical," where it works and is modular, but less experienced analysts who know python can still modify it. I've helped people put our stuff in production as automated jobs on linux systems, while my team has never used linux. Is there any value in this "bridging" experience in the SWE world, or does everyone already know this?
posted by mnemonic at 10:52 AM on November 30, 2021
> I've written a lot of code that I try hard to make "practical," where it works and is modular, but less experienced analysts who know python can still modify it
I'd describe this as one aspect of "application design" or "library design" -- how to structure the application code within a single application or library to organise it so it is possible for less experienced colleagues to use or extend it. I wouldn't expect a junior hire with no work experience to be good at this, this can be learned on the job over time with mentoring and peer review. I'd expect a mid level or senior software engineering hire to be pretty good at this. One way a hiring manager might be thinking about it is "if we leave this person alone to design and structure a codebase, are they going to produce an unmaintainable or inflexible mess that other people will then need to clean up".
> I've helped people put our stuff in production as automated jobs on linux systems
If you're working on backend systems, I reckon that this is part of the job. Sometimes orgs or teams end up specialised, where one team might focus on writing the application code and a second team focuses on deploying and operating the application in production. Again, I wouldn't expect a junior hire with no prior work experience to have much ability or intuition about what "production" means or practical experience deploying stuff, since that comes from actually working with production systems, and how you do that exactly is usually quite tech stack specific (if the team deploys to windows VMs or "serverless" in AWS or containers in GKE or ships a windows installer package for the clients to download or so on).
If you've mainly done development of application code and haven't worked that much with building and running production services, I can recommend having a read through Nygard's book "release it!" . It mainly focuses on how to improve reliability and availability of services, which is only going to matter for some roles -- e.g. if you join a team that still ships desktop software in this day and age and doesn't run any services then it may not be that relevant.
posted by are-coral-made at 1:44 PM on November 30, 2021 [1 favorite]
I'd describe this as one aspect of "application design" or "library design" -- how to structure the application code within a single application or library to organise it so it is possible for less experienced colleagues to use or extend it. I wouldn't expect a junior hire with no work experience to be good at this, this can be learned on the job over time with mentoring and peer review. I'd expect a mid level or senior software engineering hire to be pretty good at this. One way a hiring manager might be thinking about it is "if we leave this person alone to design and structure a codebase, are they going to produce an unmaintainable or inflexible mess that other people will then need to clean up".
> I've helped people put our stuff in production as automated jobs on linux systems
If you're working on backend systems, I reckon that this is part of the job. Sometimes orgs or teams end up specialised, where one team might focus on writing the application code and a second team focuses on deploying and operating the application in production. Again, I wouldn't expect a junior hire with no prior work experience to have much ability or intuition about what "production" means or practical experience deploying stuff, since that comes from actually working with production systems, and how you do that exactly is usually quite tech stack specific (if the team deploys to windows VMs or "serverless" in AWS or containers in GKE or ships a windows installer package for the clients to download or so on).
If you've mainly done development of application code and haven't worked that much with building and running production services, I can recommend having a read through Nygard's book "release it!" . It mainly focuses on how to improve reliability and availability of services, which is only going to matter for some roles -- e.g. if you join a team that still ships desktop software in this day and age and doesn't run any services then it may not be that relevant.
posted by are-coral-made at 1:44 PM on November 30, 2021 [1 favorite]
FWIW, I made a similar transition about three years ago from Data Analyst/Excel Monkey to SWE. I spent three months at Recurse Center and it was amazing - sort of the opposite of a boot camp experience and I worked on a whole bunch of fun and educational things. I now work as an engineer for a data product company, and my background as a data user is super helpful. We've hired at least one other person with a data science background, and plenty of others with totally unrelated backgrounds who could demonstrate that they had built things beforehand. Feel free to PM me if you'd like to chat.
posted by taltalim at 4:53 PM on November 30, 2021 [1 favorite]
posted by taltalim at 4:53 PM on November 30, 2021 [1 favorite]
This thread is closed to new comments.
If a company hires, they hire all the time. New grad hiring is more for big companies needing a new group of interns to take on some projects that their regular engineers don't consider a priority.
posted by kschang at 11:25 PM on November 29, 2021 [1 favorite]