Yes, you can get a software development job without knowing the relevant technologies

I’ve heard it said that you can’t get a job doing something you’ve never done. What a load of equine droppings.

What follows is mostly a personal story of how I switched careers from academia to software development without really knowing the relevant technologies. More specifically, it’s about how I got a job as a C#/VB.NET/Xamarin developer when I started toying with those technologies just before the interview.

I’m not doing this to brag. I just want to show that it’s possible to change careers without much formal experience, and talk about an important life event on what is, after all, a personal blog.

What am I running from in the first place?

I’m currently a PhD student in physics. My position has lasted for almost three years and ends in a few months. I took PhD position because after my Master’s degree, research seemed fun and I wanted to continue along the same track.

And sure, research is indeed fun. But if I’m considering a career in academia, I can’t just look at my current situation. The fact is that many late-​career researchers spend only a little of their time researching, and much of their time applying for grants, managing projects, supervising, lecturing, etc. Furthermore, if you want to have a sprawling career in academia, my impression is that you have to put your work before most other things in your life. At least for a good while. You have to work abroad for a few years, take positions where you can get them, and leverage the expertise of international research groups.

Well, I kinda like my life very well at the moment, and I’d rather not move, thank you very much. I like Bergen. I like our neighborhood. I like our apartment, which we bought not a year ago. Sure, a lot of the magic happens outside the comfort zone, but I’m way too comfortable to give up what I have now.

Besides, even though research is fun, is it fun enough? People who ostensibly know a lot about job and life satisfaction say that your job should be so rewarding that you’re skipping, running, or tap-​dancing to work. I’m not. It’s mostly rewarding work, and I started it out of genuine interest for research, but now I’m doing it because I need an income,1 and I haven’t switched sooner because I tend to finish what I start. (Also, I didn’t fully realize I was in the wrong place until I’d worked most of my allotted three years.)

Being a researcher entails highly varied tasks, from reading literature to performing experiments to summarizing your findings in a nice article. And of everything I do in my research, there’s one area that far outshines all the rest in terms of enjoyment: Programming.

I realized through my PhD that coding was what I was most passionate about. I thoroughly enjoyed it, whether it was the creative aspects of idea and design, or the more deterministic aspects of implementing the requirements in the most reliable, efficient and clean way. I have, on a few occasions, coded for six to eight hours straight, “woken up” because I’m hungry and have to eat lunch, and realized the day’s already over.

So in January, six months before the end of my PhD, I started looking for software development jobs I could apply for and start working at when I finished.

The hunt

Like most Norwegians in search of a job, I was browsing through the listings at Finn.no. I came across this rather short job ad from a small (12 employees) company in Bergen. In essence, all it said was that they delivered services to the construction sector and that relevant technologies for this position were .NET, cloud services, HTML5, and Xamarin (app development).

HTML5? Sure, I’ve got that. I’m no professional web developer, but my results aren’t too bad. I did make this after all, which I’m fairly happy with. The other technologies, though? Never used them. I knew .NET was some kind of Microsoft framework, and that Xamarin is used for cross-​platform app development. I’d never touched any of it; I didn’t even know what languages were involved.

All in all, I was pretty meh on whether to apply or not. There was too little information for the job to sound really interesting, and I lacked experience with the relevant technologies. But as I was about to close the browser tab, I saw the final sentence in the ad:

Both newly educated and experienced applicants will be considered.

I actually did a double-​take – it was the first time I had come across that since I started looking for jobs in January. Everyone else wanted people with years of experience in technologies I hadn’t heard of, much less worked with. So I figured, they probably don’t expect applicants to have intimate knowledge of the relevant technologies. Perhaps personality was an important factor (more than usual, I mean); after all, they’re not a large company, and a complete personality mismatch can quickly drag the whole business down. Perhaps they considered general programming skills more than specific experience, and would appreciate the ability to prove you can learn quickly and get things done.

In other words, perhaps this was something I should actually apply for.

Preparing for the first interview

I applied and was invited to an interview the following Monday. They told me I would get a programming task which they had arranged for to be solved in C# or VB.NET, but which I could solve in whatever language I wanted to as long as I brought the tools.

Python then, I thought. I have known Python for more than five years and actively used it in my job for three. My day-​to-​day programming tasks mostly consisted of data analysis and visualization, primarily done in a procedural manner. Not really software development (though I’d done some of that too), but I was very comfortable with the syntax and the idiosyncrasies of the language.

I shared the good news with a friend of mine who’s been a developer for some years now. He told me that Visual Studio 2015 Community Edition just became free, and proposed that I download it with Xamarin add-​ons and play around with it before the interview.

Brilliant! I love programming, and I’m always eager to try new stuff (which is why I’m making the career change in the first place). So that’s what I did during the weekend.

Xamarin is a C# framework for cross-​platform app development. Fortunately, C# is very similar to Java, at least superficially. Java is mentioned in lots of job ads, so I had started learning Java in January in order to become a bit more attractive in the market. I hadn’t focused that much on it and only had 20–30 hours of Java experience, but it’s sufficient to comfortably use it for simple tasks.

I created a C# project in Visual Studio, started writing Java and correcting where the IDE complained, and within an hour I had implemented a simple prime number generator.

Having wet my feet with C#, I decided to create an Android app using Xamarin. Lacking other ideas, I leveraged the prime number generator I’d already written and spent the next five hours making an app where you rated prime numbers. The app showed you a prime number, allowed you to give it 1–5 stars, and displayed the next number. You also had the option of seeing a list of all the ratings you had given. Nothing complicated at all, with a complete disregard for the Android activity lifecycle,2 and utterly useless. That didn’t matter at all, of course – considering I’d started using C# only hours before, I was satisfied, and had something to brag about on the interview. “I learn fast – here’s an app to prove it!”

The first interview

I got to the interview half an hour early (because, you know, bus schedules), was served coffee in a nice lounge while admiring the company’s own 3D printed Darth Vader figures, and talked with the manager until the “big boss” arrived.

The start of the interview went really well – we talked back and forth and had what I would consider a nice time.3 When it was time for the programming task, they showed me – and this is where I got a bit nervous – a program they had made to keep track of points in a tennis match. You clicked on two buttons depending on who scored, and the scoreboards showed the correct points in the current game, set, and match. My task was to create such a program.

I didn’t know the first thing about tennis, but that’s not why I got nervous – they provided a written explanation of tennis scoring, so no worries there. It was the GUI aspect that threw me off. I have developed nice user experiences on websites, but I have never used a GUI in Python. And Python was, as I mentioned, what I intended to solve this task with.

They had told me previously that it was arranged for to be solved in C# or VB.NET. I thought this meant that they had the relevant IDEs set up on their own machine, but what it really meant was that they already had the GUI set up, with proper event handlers for buttons and everything, and my task was to implement the “back-​end” of this scoring system. After an awkward moment where I asked if I could do a console version of this (they didn’t really think that was a great idea), I figured that since I had a whopping six hours of experience in C# (and I told them as much – always be transparent with what you know and don’t know), I could probably whip something together in the two hours they gave me.

It turned out to be a good choice. The syntax isn’t really a problem if you know the basics – good IDEs (like Visual Studio) are really good at telling you when you’re doing it wrong. The important part was to devise a clever class system, writing clean code, and actually implementing the multiple tiers of tennis scoring properly.

Idiomatic object-​oriented design is not currently my strong suit and is something I’m actively working on (and again, I told them as much), so I didn’t expect the class system to be really well devised. And it wasn’t. But the code was clean, variable names were clear, different abstraction layers were separated into their own functions instead of being mashed together in nested ifs and whats and buts, and when I presented the code, it mostly read like straightforward English. Thanks, Clean Code! It wasn’t my finest work, but it wasn’t bad either given the circumstances, and it ran correctly.

During the rest of the interview, I got to know a lot more of what the company was working on, and what they wanted from this position. Nothing too specific, really – some VB.NET, some C#, some Xamarin, some other stuff. They had a hardware section too, and the developers generally had the freedom to meddle in what they found interesting. The company as a whole seemed like a really great place to work – not merely a stepping stone for a career, but a place you can stay and grow. Exactly what I had been looking for!

Preparing for the second interview

Before the week was over they invited me to a second interview the following Monday. They sent me the code I had worked on during the interview and would like me to finish it in such a way that I in good conscience could deploy it to a customer.

Fantastic! I had a whole weekend I could spend on this. Finishing the program would be easy enough, but I wanted to show them that I really could learn stuff quickly, and deliver usable results even with minimal experience.

I rebuilt the program from scratch with a more clever class structure – not perfect, but better. I extended the functionality to make the scoring system more flexible and the program more user-​friendly. I wrote unit tests for all the public methods. All in all, the rewrite didn’t take me that long.

What I spent most of the weekend on was developing an Android implementation of the program in Xamarin, which I’m incredibly satisfied with given that it’s the second app I’ve ever created. I won’t bore you with details of the implementation and the design choices that went into it; I’ll just show you its three screens:

I even made a horizontal design, just to prove that I could:

With the app working, I still had some time left. I knew they had a large VB.NET codebase, so I decided to translate my C# program to VB.NET – surely they would appreciate that initiative. I had never used VB.NET before and had no idea how well this would go, but I hoped it would be feasible in the couple of hours I had left of the day. The problem? Learning the syntax of a new language isn’t necessarily something done in the blink of an eye.

I was in luck. Both C# and VB.NET are “.NET languages”. While VB.NET syntax feels very different, the functionality isn’t that different,4 at least for the simple purposes of my program. For example, here’s one of the methods I wrote in C#:

public bool IsWon()
{
  int setsFinished = sets.Count;
  int setsRemaining = numberOfSetsInMatch - setsFinished;
  int lead = Math.Abs(NumberOfSetsWon(Player.A) - NumberOfSetsWon(Player.B));

  bool losingPlayerCannotCatchUp = lead > setsRemaining;

  return losingPlayerCannotCatchUp;
}

Here’s the same in VB.NET:

Public Function IsWon() As Boolean
  Dim setsFinished As Integer = sets.Count
  Dim setsRemaining As Integer = numberOfSetsInMatch - setsFinished
  Dim lead As Integer = Math.Abs(NumberOfSetsWon(Player.A) - NumberOfSetsWon(Player.B))

  Dim losingPlayerCannotCatchUp As Boolean = lead > setsRemaining

  Return losingPlayerCannotCatchUp
End Function

It even works for more “advanced” stuff like adding and removing event handlers. Here’s a C# function to invert the checked state of a checkbox without triggering the handler (one of several ways to solve this):

private void RevertCheckbox()
{
  myCheckBox.CheckedChanged -= checkboxHandler;
  myCheckBox.Checked = !myCheckBox.Checked;
  myCheckBox.CheckedChanged += checkboxHandler;
}

Here’s the same in VB.NET:

Private Sub RevertCheckbox()
  RemoveHandler myCheckBox.CheckedChanged, AddressOf checkboxHandler
  myCheckBox.Checked = Not myCheckBox.Checked
  AddHandler myCheckBox.CheckedChanged, AddressOf checkboxHandler
End Sub

So it’s a very different feel, but definitely similar functionality.

Anyhow, I successfully translated my program to VB.NET, including all the unit tests, which passed. Lovely! Now I was really looking forward to showing everything off at the interview.

The second interview

We started by going through the C# code as before, which I gathered they were satisfied with – especially considering the UX improvements I made. Then I pulled the rabbits out of the hat in quick succession: The unit tests, the VB.NET implementation, and finally, the Android app, which got a tour of its own (of the UI and design choices – not the horrible code behind it, which I didn’t have time to clean up).

In doing this, I had made it perfectly clear that I really wanted the job, that I was capable of adapting and learning quickly, and that programming certainly was a passion of mine.

They seemed very happy with my efforts, and a couple of hours after the interview, they called and offered me the job.

The takeaway: Results, passion, dedication, and luck

These are the factors I see as crucial to my getting the job. I could be wrong, of course; I have never employed anyone myself. But I don’t think I’m terribly far off with the following key points:

• Results. Employers want employees who can get the job done. Do, or do not – unlike in school, you won’t get points for trying. You can know yourself that you can get the job done, but words are wind – you’ll have to provide some kind of proof. If, like me, you lack experience, then you can’t point at your resume – you’ll have to get your hands dirty. My progress between the two interviews was evident, and they could be reassured that I actually could – and would – learn what I needed for the job.
• Passion. Employers want people who are passionate about what they do. So if you’re passionate about a potential job, make sure it shows. If you’re not, well… Far be it from me to suggest you find something else, but I think life will generally be better if you work with something you’re passionate about. As I mentioned earlier, you should be skipping to work.
• Dedication. After the first interview I knew I wanted this job, and I felt there was a chance I could get it. I spent the entire weekend preparing for the second interview. Not only doing my assigned “homework”, but, well, over-​achieving, to show them I really wanted this. I’ve likely set the bar awfully high for myself now, but eh, such is life.
• Luck. Yes, there certainly was some luck involved. I was lucky to stumble across an employer who was willing to bet on a horse without a significant track record, I was lucky to have read Clean Code, and not least, I was lucky to have a friend tip me off on playing around with C#/Xamarin the weekend before the interview.

So I guess the bottom line is this: Making career changes is possible, even if you lack “key” experience. Sell yourself honestly and enthusiastically. Employing someone is risky business, and your job as a candidate is to convince them that you’re the right choice. Show, don’t tell, and sooner or later you’ll make it.