How to describe professional software development experience if I can't share my code as per company policy

Question

I'm seeking some career advice on getting into software engineering. My academic background is in EE and I'm currently in QA testing. I'm working with my employer's client, which is a major tech company.

After teaching myself to code and practicing problem-solving on Leetcode, I started developing automation scripts (in Python) for my current team (client company), which I've been with for about a year. The automation scripts are used daily by the team which has boosted the efficiency of the workflow in multiple aspects. Speaking to the scale and complexity, some of these scripts are hundreds of lines of non-comment code, which I have actively optimized (and added new functionalities) many times over the past year.

On my resume, I can mention that I have a year of development experience (in Python), but the automation scripts aren't customer-facing. As much as I wish to keep a copy to prove my development experience and abilities (e.g. GitHub), but as per company policy regarding confidentiality, they cannot be shared externally.

Is it sufficient to just mention it on my resume and discuss during an interview? Will potential employers take my word for it even if my automation projects can't be shared externally? Where do I draw the line for how much I can verbally describe? I'm pretty sure they have similar policies at their companies too.

On the other hand, I've also been practicing problem-solving skills with Leetcode-style problems. Am I on the right approach of this career change? What else can I do to get into software engineering?

Answer 1

Is it sufficient to just mention it on my resume and discuss during an interview?

Yes.

Will potential employers take my word for it even if my automation projects can't be shared externally?

Yes. They might ask technical questions about Python, to see whether you could have done as you claimed, but if you answer them satisfactory, there is no reason not to believe you.

Where do I draw the line for how much I can verbally describe?

Is any of that a trade secret? I would assume automation scripts are a thing everybody has in that industry. So describe as much as you want of the technical details. Chances are, they are not terribly interested, once they figured out you can potentially do it, through the questions mentioned above.

Generally speaking, this is the norm for huuuuge parts of the industry. All our code belongs to our employers and if your biggest achievement wasn't picking the color of the company website, none of your work will ever be "visible" to a degree that the next employer would need. It is the same in almost every job. If you want to be hired as an accountant, you don't get to keep your old company's books to show them to the next employer. All you have is references, credentials and making a good impression at the interview, for the core skills needed and interpersonal.

Answer 2

To add to Nvoigt's answer (which is a good answer) - what is common is that all technical companies know you can't share specific details about your existing work.

What often will happen is you can talk about the abstracted problems that you faced and the abstracted solutions.

For example: "On a system I helped implement, I took data from multiple data sources, that was backed by different Database engines. As part of an ETL flow, I first had to extract the relevant data into a single DB Engine. The main challenge I faced here was accounting for nuances in formats between the different DB engines and accounting for that in my code.

Once the data was in a single location, I had to run additional scripts to transform it into a unified set of Data, where the different equivalent metrics between the data sources were now in a single table or column and analysis could be run against them."

If I told you that in an interview - you've got no idea what DB engines I worked with or what the back-end systems where, but I've articulated a common problem that I had.

What I might do next is elaborate on one specific example:

"One such issue was Date-time formats. One system had NULL values for Date time set to 0000-00-00 00:00:00 - and this was an invalid format for the destination system, so as part of the Extraction process, my extract scripts had to cast this value into something that was acceptable for the destination system"

Now, someone uniquely familiar might get a little more info - but it's still vague enough that I've not divulged any company specific info - but I've described how I solved a particular problem.

This is often how you will 'convince' a potential employer about your skills when you can't show them your actual code, but talking about an abstracted version of a problem you faced and the steps you took to solve it.

Answer 3

Congratulations for pushing your own development. It says a lot about you that you're not happy to settle into a rut, and that you focus your efforts on making your team more efficient is something any company would be happy to hear.

Speaking as someone who has been on the hiring side of a tech interview, if we had a candidate show us code from their previous employer without permission, that would be an immediate red card. After all, it would be evidence that they don't respect their employer's intellectual property, which is always something a potential employer wants to avoid! I had a few younger candidates nervously admit to a predicament like the one you're describing of being unable to speak freely, and we've had to reassure them that we consider such discretion positively.

As to other ways you'll be able to evidence your case, here's a few ideas

1. You'll likely want a reference from your current employer. You can put down someone who is familiar with your work such as a direct manager (rather than HR) and you can brief them about the sort of career change you're taking and ask them to highlight things like the automation.
2. If you find the employers you're after do want to see some code, and you have the time, you can mock something up. You'd draw on the same skills, but apply them in a different scanario. I would add here: although there is such a thing as too short, I'd recommend trying to keep such a demo concise and focused on the key skills you want to show. 50 honed lines can tell a better story than 10,000 lines of fluff.
3. Some employers ask for leetcode style tests. Others ask for bespoke coding tasks. Both will give you a chance to show off your skills in a safe environment. (Do be aware that there are cons who use "coding tests" as a chance to get possibly weeks of free work. If something feels excessive, to the point that you'd resent doing them if you didn't get the job, the common advice is to look elsewhere.)
4. Try again. As with any job hunt, you will find jobs which require proof you just cannot provide. This goes beyond "I don't have the code I wrote before"; perhaps because they're a bureaucratic behemoth and flat out require a computer science degree. There is nothing you're going to do which would persuade such wall to become a door. But there are other companies which are more than happy to grab at someone with your background.