From Structural to Software

I've nearly finished up my search for a full-time purely software role, targeting full-stack positions at small to mid-sized companies. In the past two years, I've had over twenty people ask me about changing careers from structural engineering (through word of mouth, LinkedIn, and Twitter), so I thought it would be helpful to outline what the process has been like.

Background

I have been writing code alongside my job (and also for fun) since 2015. Some of that experience was in an academic setting (admittedly that was probably the worst stage), but the majority of it has been experimenting and building tools for my job and on my own time. I also did two focused retreats in programming at the Recurse Center in Fall 2019 (in person) and Summer 2021 (virtual).

It is really hard to be dedicated to and consistently study a completely different field while working a full-time job. When I re-entered structural engineering practice in 2018, I was working 60+ hours a week, which made it nearly impossible to have any downtime and hobbies. I prioritized attending a monthly meetup with Pyladies NYC, which made a world of difference, since it made me accountable to working on projects to show. It was also extremely motivating to spend at least an evening a month with likeminded individuals who wanted to get better at software craft. While some aspects of programming might lend themselves to structural engineering (i.e. optioneering in project early stages or conducting sensitivity studies), I had a lot of projects that were in construction documentation (CDs) or contract administration (CA), where administrative stuff just needed to get done, and there wasn't any room for experimentation or research.

When I moved from NYC to LA, I did my first batch at the Recurse Center and then started a new job in a new city just four months before the pandemic. I didn't do much coding during the first four months as I was settling into my new role and new company (and my projects were largely in coding-won't-help-you phases). However, during the first year of the pandemic, a number of my projects at work went on hold, so I was able to learn more C# and work on the company's open source code base. I also continued to tinker in my spare time (it was a mixed blessing that part of the pandemic survival strategy was to have Fridays off due to lack of work).

Preparation

After I quit my full-time job as a structural engineer/software developer in summer 2021, I first started off with another batch at the Recurse Center with some flexibility on my learning goals (other than wanting to do more in web and data visualization). I've talked more about my batch in this blog post

Books I Read

I read a number of these books while in batch at RC, as there were a few reading groups that met throughout my time there.

Projects I Built or Worked On

The best advice I can give for interviewing is to have a personal project of some complexity that you know inside out and can talk at length about what you achieved with it as well as potential pitfalls of the design decisions you made.

My two projects for interviewing were Pymaxion and Bridge.watch, but I also talked about some of the collaborative work I'd done on Irydium with Will Lachance, since he's the creator of the project.

Other Learning Materials / Resources I Found Helpful

Applying

I really kicked off interviewing in the last week of April (aside from a contract opportunity in late March), but had to schedule all my followups for two weeks later due to attending Pycon the first week of May.

Resume

It pained me to do this, but I dropped most of my previous experience from my resume, leaving only single lines from my various engineering roles, and instead expanding a lot on the freelance work and pro bono work I've done in the past year. I also have a section for skills (programming languages and other tools) as well as conference talks.

You never know what will make your resume stand out. I'm pretty sure I got at least one interview off of the fact that I used the LaTeX coffee stain package on my resume.

Cold Applying

In general, the road from the built environment to software seems to be a bit better paved for architects. There's the Architechie forum, and the more vocal career switchers I've seen are usually from the architecture side. (There should be a longer conversation around how it seems that structural engineering grinds its practitioners down into believing they don't have transferrable skills...) So, despite having an interest in the field, I didn't have a lot of personal connections to AEC Tech (except for snarking on Twitter). As a result, I did a lot of cold emailing and applying. This mainly meant sending in a resume and cover letter, which I did significantly personalize for each position.

I used AEC.works and listened to a lot of podcasts, including TRXL and Practice Disrupted, to look at AEC adjacent tech companies (I filtered by programming languages a bit, because I want to get away from C#). I also had a few more general Python and software companies that I wa interested in based on their products / platforms / culture.

Recurse Referrals

Helping place Recursers at partner companies is the main way that the Recurse Center makes money. I initially talked to one of their career facilitators for half an hour to get an idea of what I was targeting (software engineer, full-stack, no fintech/blockchain/crypto, sub 100 person companies). She then sent me a bunch of companies and job postings that were in the stack I was familiar with (and some I wasn't, but could potentially learn quickly at). Throughout my interview process, I frequently checked in with the facilitation team to see where I was at and if I needed to speed other interviews along.

Interviewing

Phone Screens

In almost all of my interviews, the phone screen was just conversational, talking about my background and motivation to pursue software. However, I did have one instance of being told to fire up an IDE 15 minutes into a 30 minute call for a code screen! (Surprise, surprise, I did NOT get through to the next round on that one...) In terms of who I talked to in the first conversation, that ranged widely from CEOs/CTOs at small companies to engineering managers or hiring managers at larger ones.

Technical Interviews

Usually the second touch during the interview process was a technical round, either live coding or a system architecture problem.

For live coding, I only had one leet code type problem (the aforementioned fire up an IDE for 15 min); the rest were largely practical. Some had prompts that were directly relevant to the company's work (which was nice to get an idea of what types of problems they're dealing with). Others were completely unrelated (like coding up a small game), so it was more about reasoning out all the components needed and talking through it with my interviewer. In general, it's better to say more during an interview since it gives the interviewer a better idea of your thought process. One good way to get better at live coding is through pair programming, which is something I've done a lot of thanks to the Recurse Center.

The other type of technical interview was usually a systems design problem, either troubleshooting bad behavior for a system or explaining a personal project. If I was doing a personal project walkthrough, I needed to explain all the microservices used and respond to questions on potential improvements to the project.

On Sites

I had five on sites during my interview process (biggest lesson learned was not to do two in a day if you can help it 😬) There was more live coding in the on sites than I originally expected, as a number of them were past the initial technical screen. Virtual on sites are a real marathon, so make sure you're well hydrated (and eat ahead of time or have snacks for off camera). My on sites were a mix of more technical portions (additional live coding and system architecture) and more behavioral portions (can you tell me a time when?, etc.)

Negotiation

Negotiation is not my strong suit or something I consider fun, and there are many people that can give better advice on how to do it. The offers I've received are largely in the range of what I was looking for, plus generous benefits and time off compared to structural engineering. In addition, every company I interviewed with was "remote-first". On average, the compensation packages were anywhere from a 30-50% improvement on my structural engineering salary (which had miniscule bonuses and no profit sharing) with an equivalent software full-time experience level of 2-4 years. Once I had an offer, usually the company would offer a one on one with an engineer (or I'd ask for one). For those meetings, I've beeng using Julia's Evans Questions I'm Asking In Interviews as a jumping off point to get a better idea of the day to day and what I'd be doing.

While the interview process has been significantly more in depth than my interviews for structural engineering positions (usually that's limited to a single on site interview), it hasn't been as painful as I thought it would be. The live coding portions were mercifully void of gotchas or super tricky algorithms, and the people I interviewed with were great. I've gotten a much better feel for these companies than I ever did after a structural engineering interview, and it's been good to get a chance to interview the company as much as they've been interviewing me.