Transitioning to Software from Data
Hi there!
I've been working in the data space for the past 3-4 years, in a role/function that's highly adjacent towards software. I essentially own all of the clickstream level tooling at my company.
I know JavaScript fairly well in that context + SQL to query and wrangle the data that I collect from the applications.
Since I had become obsessed with JavaScript working with it in that context, I went very hard in the self-study route and have been consuming essentially all the content that I could find to become a hireable SWE.
I'm starting to take on tasks like setting up the JS on Optimizely tests for Experimentation (in addition to the other work I do related to JS in data), and slowly have been building side projects, that intersect my love for software with data.
From Alex Chiou's post here, I've been focusing on just putting in the work and am about to complete my first (for me) large application ~500 lines of TypeScript/JavaScript with Playwright that solves a real problem in the data space that I am passionate about.
My question is... how do I know I'm ready to make the leap to SWE, and how can I tailor my path properly towards my long term goals? (below)
I believe that I have some technical gaps for SWE, for example:
- Since all my work has been in data, I don't have strong front-end & design skills yet(React, Tailwind, etc are gaps).
- Next.js
- DSA (which I know I can address with some of the courses here)
- OOP/System Design (because I just haven't been a SWE and had to really do this yet, although I'm starting to implement these practices in my application)
- TDD (writing/implementing tests although I've been experimenting with this lately).
Some folks have advised me to really lean into the data space, and try to expand deeper, like focusing on building apps with real-time data streaming (with Apache Kafka) and more backend, DB type stuff.
My dream job is to work at Netflix (in a Software Engineer - Data) type of function maintaining and building API layers that support great user experiences. In the long term, I want to build up the capability to build and ship data-centric software.
What would you all advise that I do here to set myself up for success?
Discussion
(6 comments)- 2
18 days agoTech Lead @ Robinhood, Meta, Course HeroDocuSign is a large, great company (look at that stock price over the last year!), so you likely have an opportunity that many engineers don't have: Internal mobility
You have seniority and ownership alongside what looks like a solid amount of practical experience with JavaScript. My advice is to parlay that into getting the experience you want at your current job.
Talk to your manager and partners you have on the SWE side to see if there's SWE work that you can pick up, particularly projects that lie at the intersection of software and data. The ideal scenario is that you hybridize in this way and eventually pick up so much SWE work on the side that DocuSign just lets you switch over internally. This will make it 10x easier to convince Netflix to hire you in your dream role as another big company has already given you their blessing to do it.
These are for different transitions, but the concepts are similar:
- "How do I transition from QA into SWE?"
- "How to transition from back-end development to distributed systems?"
I also have some comments on your perceived technical gaps:
- Front-end/design - Based on what I've read (and what I've seen from data folks transitioning over to SWE), being a back-end engineer seems like a better fit for you? I know that visualization tools can come into play for data, but those are often internal and the design bar isn't super high.
- TDD - I don't think TDD (at least as how it's traditionally defined) is worth it. FAANG largely doesn't really do it. More thoughts here: "What are your thoughts about Test Driven Development? Do you think it adds value in your career?"
- 018 days agoSenior Analytics Engineer [P3] [OP]DocuSign
Thank you, this is very helpful.
Is it advisable to align with this to focus my self-study on all back-end stuff?
I'm pretty comfortable with Node (as JS is my main language). At DocuSign, I THINK Node is used fairly significantly on the backend, with one of the C's also being common (I don't remember which one but I can find out). I'm trying to go super deep on JS (and if backend is the easiest for me to transition to in SWE with my data background, I'm all for it!).
That being said, I did a bit of research and it looks like a lot of other languages are super common in backend, like Python/Java/C, C++, etc at other companies.
At what point would you recommend jumping into one of those other common backend languages (or should it not even be a thought right now)? - 117 days agoTech Lead @ Robinhood, Meta, Course Hero
Node.js is a very popular framework. Python/Java/C++/C are all top-tier languages in terms of usage as well, but C++/C are tricky for passing DSA interviews due to their verbosity.
All that being said, I would first figure out what SWE work you can pick up around DocuSign by talking to your manager and SWE peers (ideally tech leads). It's generally better to have self-study reinforce what you're already doing at work.
- 218 days agoAI/ML Eng @ Series C startup
Awesome that you're switching to SWE! Piggybacking off of Alex:
- For non-frontend roles, I don't think they'll ask you too much framework-specific questions
- Leaning into your strengths as someone who works with data-intensive applications will help a ton
- As Alex said, in practice TDD can get in the way of innovation. You can just follow your new team's testing culture when you join
Finally, on knocking down those doors to get those interviews:
- If your project is somewhat similar to what the team is looking for, you can ping the hiring manager, or on the application submit your project code as a work sample. I've gotten several interviews this way, and also gotten people who were on the fence about me to at least move me to the next round of interviews
- 018 days agoSenior Analytics Engineer [P3] [OP]DocuSign
Thank you for the comment, Elliot.
I'm all for pinging the hiring managers and sharing value. To be very transparent, with the app I've been building, I found what I strongly believe to be a production bug at my dream company (Netflix) using my project (with its purely backend state at the moment) on the data side of one of their applications.
I hand-crafted a handful of nice comments and reached out to ~5 different folks at that company who may have been able to get value out of it (and to fix it!).
That said, it essentially went nowhere and I didn't get replies. Maybe volume is just the name of the game, but would love to hear (and maybe this is a course that the guys at Taro should create!) what does it actually look like when you're reaching out with a project to a prospective employer when you're interested in working there? - 118 days agoAI/ML Eng @ Series C startup
Hm. While your intentions are good, I think you're leading too much with "look at me I found a problem in your system". Could you try just reaching out with the premise of wanting to learn more about the company/team? Then you can lean more into "I built something and found out some cool stuff about Netflix' production app this way" as the conversation warms up.
Open-source really is king when it comes to this kind of "attention grabbing". Side projects can be hit-or-miss unless you're cracked.
