Recently, I was in an interview with a medical tech company hiring a software engineer. We began with the normal questions, “Tell me about yourself”, “What type of projects are you working on now?’, “What languages do you use?” All things I have prepared for repeatedly so I sound “normal and conversational” lol. Things were going well. The conversation was flowing and at one point, she even told me “you are segueing right into the next thing I was going to ask.” I was telling myself: “You are killing this! Let’s go!!!” Then, it was time for the heavy hitter questions.
“Do you have medical experience?”, “What do you know about product life cycles?” “Do you have experience with compliance and federal regulations?” None of these questions were software-based, or even about code. They weren’t about data structures and algorithms, leetcode, hackerrank, or any of the other things developers study until their eyes bleed for interviews. These questions were designed to see if I really understood what they DO. They were asking if I understood the product. They wanted to see if I would need constant context when building software or dealing with the user and medical data.
Thankfully, I’d done my homework. I researched the Food and Drug Administration (FDA) regulations the company would have to follow. I read the government requirements and types of reports they would have to submit to receive approval. I even read white papers on the best practices and how to structure the documentation. How did I even know where to find this information, much less understand it? I am a software engineer with a law degree.
I have more than a decade of experience in international finance and tax law. I’ve read, studied, and submitted reports guided by federal laws and regulations. Additionally, I have automated and developed systems in government compliance. Before that, I worked in estate planning which also requires compliance with local laws and regulations. When I decided to become a software engineer I was concerned that my tax law and financial experience would only translate to fintech companies and banks. I could not have been more wrong.
Having a legal background is my superpower. When I am building projects, I don’t just think of writing good code and making sure it works. I think of the product itself. I ask myself lots of questions and try to view the problem from multiple perspectives. I use a similar process when constructing a legal argument. It often flows like this:
Does the product have to comply with any legal requirements or other guidelines?
Where am I on data compilation?
Will additional data change what I build?
Is the product too complex, will adding or deleting a feature make it easier to use?
Does the project serve its intended purpose?
Like software engineering, legal work is often heavily time constrained. There are deadlines to file orders with the court. Attorneys must consider statutes of limitations depending on the type of case. Tax law specifically, has what feels like an unending number of timeframes for filing certain forms. Similarly, when creating a software product timing is extremely important. I ask myself:
When does the project need to be completed?
Does it have certain features that can be added later without materially hampering the project?
Where are we in the product life cycle?
Do I need to simplify a feature to get us back on track and add to it later during a software update?
Can I eliminate a feature altogether?
I keep the client's desires in mind so I don’t duplicate work. Processing sensitive tax information, submitting legal filings to courts, and building programs all require the same mindset: I dot every I and cross every T.
Now back to the interview. I was honest with the interviewer and told her that while I didn’t have a medical background, I did have extensive knowledge of legal regulations and compliance. We discussed the FDA requirements and the type of user information that would need to be submitted throughout the approval process. I talked about the need for following instructions to the letter because FDA rejections can cause extreme delays. I asked about user feedback and how that information was used to make improvements to the product. I inquired about the Health Insurance Portability and Accountability Act (HIPAA) and how it influenced their data security systems. I suggested setting up profiles for medical record requests by limiting the scope to only the necessary information. Over time, it felt less like an interview and more like a conversation.
I didn’t know much about medical technology when I set up this interview. However, my legal background allowed me to show ALL the ways I could contribute as a software engineer. Your past experience is valuable, so let it shine through! Don’t shy away from it because it's not traditional “tech". Let it inform and guide you when building projects and/or interviewing. Collaboration and new ideas are often just as important as the coding itself. Bring all your skills to the table.
One of the best things about the tech community is its diverse backgrounds. Used to work in retail? You know how customers respond to a product. Educators can communicate with teammates and other departments like no one else. A salesman knows what makes a prospective buyer say yes or no to a pitch. An auto mechanic puts puzzles together and tests things methodically to diagnose the problem. No matter your background, your experience is your superpower, so get after it!!!