Ask HN: How to switch software engineering domains

>Despite this, I'm having trouble applying for jobs. I usually don't meet any of the requirements, as I don't have actual work experience that the job description expects. And when I do apply, I get rejected before an interview.

That's just how it is. Keep applying. I doubt anyone is getting a job these days without making dozens of applications, or having serious connections. It's brutal and discouraging, but you just have to stick with it.

For some more actionable advice, focus on your framing. Interviewers don't care at all about what interests you, or what things you're most excited about getting to work on. They care about what you can do for their company right now, especially for a mid-level role. Think less in terms of "I'd love to join your company because I'm excited for the opportunity to learn more about XYZ" and more "I'd love to join your company because I have a good working knowledge of XYZ, and believe it would be a huge contribution to your development efforts in that area."

It seems like using one's network is how you can get into a job that you don't currently meet the requirements for. If your current company has any role in a different domain, they might be open to you requesting a transfer.

If you wanted to get into full stack dev or something, the answer would be obvious - do a project, apply, get job because you know the fundamentals.

If you are trying to get into something specific like graphics, I imagine the formula is the same, but probably with much lower likelihood of success.

I assume you are trying to break into the game industry?

I applied as a intern and a tool developer once at two pretty famous AAA studios (due to friends, both actually didnt work out) and trust me when I say the bar is MUCH higher than a average backend job.

I do not want to discourage you, but if you have zero credits on MobyGames expect that they DO want to see proof that you can develop something like a fully working game engine from scratch (which means you understand the base concepts of game system development). Also, any proof of handson experience optimizing code for modern consoles which nowadays amount to Playstation 4, Playstation 5, Xbox One and Xbox Series S/X will probably be a huge plus.

If you can't show any of those things I am afraid most, if not all, studios will not be interested.

With things like computer graphics you're competing with a very different pool of applicants than you likely were before. People with PhD's and Masters in related fields. I have found success with positioning myself as someone who works on the edges of multiple domains. So if you were a web developer before it would be at an intersection of web development and computer graphics which could be web gl or operationalizing graphics applications for web or cloud integration. This won't work very well at larger companies that have a lot of clear boundaries between positions, but it will work at startups where boundaries are less clearly defined and people wear multiple hats. In summary, try startups and position yourself at the intersection of multiple domains to get your foot in the door.

Keep in mind that the layoffs earlier this year have still had a huge impact on the job market for software engineers. Many companies moved their hiring bar higher and have gotten more selective over their canidates. 2 years ago, if you pretty much had a pulse you could have jumped fields (yes, some jobs did require specialized knowledge).

Many Canadian companies are not doing "interesting" things so I can understand the perspective of being at the long end of the funnel on sprint tasks for a product that might not be getting huge marketing wins. You've already taken the first step at figuring out what's interesting to you. As others have said, start learning about some topic areas find the meetups over those topics and start networking and getting to know people in the field.

Lastly, interviewing is a skill.

Does your current company have any lower level positions open? It may be easier to switch internally.

Right now, just changing a job is hard. While waiting out the downturn you can work on some personal project, just to have something to show. I hope in a year or two it will be easier to change domain as the market recovers.

Is your company's product a web application? While looking for jobs, maybe try looking into WebGL or WASM to see if you can apply your interests in a way that you cab still do graphics work at your company in the meantime.

I would recommend dabbling in different fields and writing open source stuff. If you like the work, you’ll probably build something cool that may get you hired. If you don’t like it, drip the project and try something else.

I got really into options trading and built a paper trading site that eventually got acquired (for actual money!), and that’s been the talking point of every interview since I sold it.

If you decide you like robotics and you build a library that does fast matrix multiplication leveraging webgl or something, I think a lot of people would be very interested in at least having a conversation with you at that point. People who can “get things done” are always valuable.

Find a company that does both, and that will hire you for your experience in one. Maybe that's a Python company that needs to do Rust stuff, or occasionally has performance constraints that mean they need to use C?

I've switched domains four or five times now. I started with gamedev, went to finance, then pentesting, then machine learning.

The key is to have a strong portfolio. Every successful switch was based on that. Even in areas where you can't really show a portfolio, like pentesting, I was good at it and was able to demonstrate it.

It's really that simple. Be good, and show that you're good. Don't wait for someone to show you what to do.

Oh, as for the mechanics of getting the job, it's the same as any other: Forget the resume process. Find someone in the industry you want to work at, flatter them (everyone likes to be flattered, and you should lean on this tool as much as possible) and show them you can be useful.

It may be easier if you wait till you have exactly five years experience. I suddenly got a bunch of recruiting emails when I crossed that threshold.

It tends to be much easier changing around what you work on within a company. I started doing embedded and server software in my first job by just helping out on bug fixes without asking.

I made this exact career transition, the first ~10 years of my career were doing backend development at web companies (mostly Python, but later Go) and I switched to working in C++ in the autonomous vehicles industry.

The key is really just to apply to these jobs, even if you don't have direct work experience. I had a blog on my website that had a lot of C/C++ stuff which I think helped a bit, but in the end I just applied to a bunch of jobs and eventually got a technical phone screen. I described some of the C/C++ projects I had worked on in the past (mostly personal projects). I got grilled fairly hard on C++ stuff in that interview because the company knew that I wasn't coming from a professional C++ background, but I knew my stuff so it ended up not being a problem.

The other way to do this would be to try to get a job at a company like Google or Facebook. Typically you're just another person in their recruiting funnel and whether or not you know C++ doesn't actually affect how their hiring pipeline works. At both companies you're typically not applying for a spot on a specific team at the time of your interview, so you don't even necessarily have to write C++ in your interview to end up getting matched to a C++ team.

Apply ”lower level” approaches to your current job and get experiences you can talk about in application processes. For example, if you code backend C#:

- Apply “lower level algorithms” to tasks where it fits (if you find good use cases you will be seen as a genius by the other “high-level” programmers)

- Implement “lower level programming approaches” to solve problems. For example, there may be good use cases for emitting MSIL-code in parts of projects (for example where interfaces are injected, you could inject emitted classes on the fly for example in some instances). Again, you will be seen as a genius if you find the right use cases.

- Implement “lower level” communication protocols where suited, for example a home made UDP protocol where you benefit from not having a stream and some packets are not needed.

As a hiring manager, I'm not averse to hiring someone with non-domain experience for a domain-specific role with but I usually have a few apprehensions. You can make yourself a better candidate by pre-empting these questions:

* Were you actually good at your previous domain? (Be Good)

* Does this person know they actually like working in this new domain? Or do they just think it might be "interesting"? (Show some proof that you are already investing yourself in this new domain)

* Do they have a track record of successfully learning new things in the past? (Any other non-domain skills you've picked up that show me you can be successful doing that?)

* Are they at a natural career inflection point and a good time for a transition? (You just got a Masters, so this is covered)

Trying for a totally cold start is tough though. I would try to get a foot in the door via career fair or university contacts. Use whatever coursework you have completed in the area to show aptitude/interest. Good luck.

Find a team that does what you want, and get a position doing what you are currently qualified to do. Learn to do the other, new thing, then get your manager's help to make the transition official.

Start contributing to open source projects you’re interested in.

Alternatively, what I did last time was start my own company and then use the most appropriate technology (Elixir in my case) despite not having it on my resume.

The downside though, was financial turbulence and ultimately a bit slower learning on the tech side than if I’d been a FT employee using it instead of also being busy talking to customers, doing support, marketing, etc.

>Despite this, I'm having trouble applying for jobs. I usually don't meet any of the requirements, as I don't have actual work experience that the job description expects. And when I do apply, I get rejected before an interview.

This is normal, keep going you're on the right track. Apply everywhere, don't stop if you don't meet the requirements. But, do some research into the role and company. Show in your cover letter that you've put in lots of effort and try to convince them you're a good fit for the role.

At my workplace, I started in software and then was able to transition into embedded software about 6 years in. I credit a lot of that to a) working at a place that had both the field I was already in and the field I was getting into and b) the company culture/supportive managers/current development needs. Some fields I think this could work, others not so much...

You might get some more targeted responses here if you could give us an example of the types of roles you're applying for. As noted some fields are tougher too so I think general advice is only going to get you so far and specifics may help in so far as you are able to share.

Project experience matters. Just focus on that. That's how I got into compilers.

At the same time, reflecting on the 5-10% pockets of what you do now that you really enjoy that makes the rest worth it (or used to) might be an interesting exercise to let it shine a light on your path.

See if there's other projects you can hop on or sit in on in your current job.

Failing that, software development is something that you can sometimes create your own experience instead of getting it from a job. Join meetups, demonstrate what you are learning and present it, and let your network organically grow and you will by pass much of the application process or have it be a bit smoother.

Domain switching can be greatly helped by cultivating relationships that don't just help you, but you also add value.

This cycle may repeat it self for a while. Work is called work for a reason.