1. Where I come from and where I am at right now

I am a translator turned web developer, i.e. I have a non-tech background. Elixir is my first programming language, or at least the first in which I pursue a career. That’s the short version. The extended version is available on my About me page.

As I am writing this post, I have completed the interviewing phase with one company and am waiting for them to send me my contract. I might also still hear back from a second company with which I interviewed last week. Exciting times.

Since there are already a lot of helpful blog posts and articles on specific application steps (e.g. resume writing, technical interview), I will keep this post more general and instead provide a few of my favorite pieces of advice for each step.

2. The moment you consider a programming career

If you are considering a developer career at all (even if you’re just playing with the idea), start building your portfolio right away. Be visible. Get familiar with your code editor and git and put your work on GitHub. That way, potential employers visiting your GitHub site will see all those green squares and know that you have been coding consistently. If you have built something cool, pin the repo and show it off.

You can always delete repos later or make them private, but you cannot build a commit history. I think we might be a bit ashamed of our code sometimes (I know, I cringe when I look at stuff I wrote just a few months ago). But even if our past projects are far from perfect, they still show that we a) built something and b) that we have developed since the code in more recent repos will (hopefully) be less cringe-worthy.

3. Before you apply

Let’s assume you have put the idea of becoming a developer into action, put in the work and are actively looking for a job. Once again, it is worth doing some upfront work.

Double-check your GitHub profile. Spruce it up. Pin your best repos, upload a good profile picture and add a profile README.

Create a LinkedIn profile, add relevant skills, education and employment history and link your GitHub page. You can also mark yourself as “Open to work”. To be honest, I am not a big fan of LinkedIn, and I can’t say that it has helped me much in my job hunt. However, I did notice that a lot of the online application forms I filled in asked for a LinkedIn page, so I guess it is still good to have one in place.

Put some effort into your resume, both with regard to content and design. Especially if you are an absolute newbie and maybe a candidate that companies might be more inclined to dismiss due to the lack of production experience, you want to make sure that your resume stands out (in a good way) from the rest. I used Canva to create mine, and I must say, I’m pretty pleased with the result. Make sure you list all your technical skills. Mention any programming languages, frameworks, libraries etc., with which you have worked. Once again, I think it is a good idea to provide a link to your GitHub page and if you have any projects deployed, link those as well. Another important factor to consider is that, while you might not have experience as a developer, you probably worked in a different job before. Identify the qualities from your previous career that will carry over to your new career and list those as well. To give you an example: as a result of my translator’s career, I am highly organized, reliable, good at communicating, able to work independently but also as part of a team etc. You get the idea. The message you want to send is “I will be a good employee/contractor”.

Another thing I recommend preparing is a cover letter. I used Canva to make a nice one, but I also had a simple Google doc where I just typed down a rough version. I’m not saying you should send the same letter to all companies. You’ll still have to make individual adjustments. But there are certain points that I included in all my cover letters. I start by saying where I read the job ad and what I liked about the job description and/or the company. I then highlight some of my experience in Elixir (projects, courses) as well as my professional experience gained from my previous career. And I conclude with a link to my GitHub page.

I also have a few lines saved in Google docs that I can use when I am contacting somebody on Slack. Once again, it’s just the basic text that I can use as a starting point.

4. When you apply

The first question is probably: where do you find job opportunities. My two go-to places for the most up-to-date offers are the Elixir Slack job channel and the Elixir Forum. If you are subscribed to newsletters of community members who are recruiting, reaching out is certainly a great idea.

As a junior developer, you’ll probably notice that the vast majority of job offers is for seniors. In addition, the few opportunities advertised as “Junior/Mid-level” often want somebody with little to no Elixir knowledge but 5+ years of production experience in another language. So what do you do if you are a newbie like me, with no prior programming experience? You apply anyway. You have nothing to lose and everything to gain. Just be honest about where you are at in your career. Don’t worry if you don’t meet all the requirements listed in the job descriptions. Somebody more experienced once told me they are more like a wish list and not set in stone. This being said, I still think it makes sense to take a minute to decide whether an application is worth it. I, for example, will not apply if a company is expressly looking for people in Europe, super senior roles or full-stack developers. I’m also more reluctant if the offer is by an early start-up or involves betting or NFTs/crypto stuff. But that’s just me. The factors that matter to you might be entirely different.

Once you have found an opportunity that you would like to apply for, take a minute and check out the company. Look at their website to get a better idea of what they are doing. Maybe take a few notes of things that you like about the company. Also, make sure to read through the job ad thoroughly. It’s good to refer to some of the points mentioned therein in your cover letter.

The next step depends on where you found the opportunity and how they want you to apply. If the job was advertised on Slack and you are supposed to contact the company on Slack as well, go to your google doc with your draft text, and adapt it to the company you are applying with. Add something you read on the website that you liked, or highlight why you would be a good fit based on the job ad, and then go ahead and message them. I usually attach my resume as well. That way, I save them the extra step of asking for it later and show that I have my stuff together (and my resume looks pretty good).

A side note for people in Canada: often, jobs are advertised as U.S. only, but it can be worth it to reach out anyway and ask if Canadian residents might be able to be considered after all. It can be easier for U.S. companies to hire somebody from Canada as a contractor based on a W-8BEN contract than hiring a U.S. citizen in another state.

If the job application is submitted via an online form, make sure you take the extra step in this case as well: if you have the opportunity to upload a cover letter, do so. If there is a field for a message, include one. Once again, make sure you reference something you read on the website and/or the job description.

The bottom line is that no matter through what channels you apply, you want to show your future employers that you put some effort into your application and that you want to work for them, not just anybody.

5. The first interview

You did it! You made it into the next round! A company got back to you and invited you for a first interview. This one is often called the “cultural interview.” You will talk to somebody from the company (it can be anyone: HR rep, co-founder, VP of engineering) and learn more about the company and the role you have applied for, and they, too, will get to know you a little better. I might be weird, but I have to admit that I actually enjoy these cultural interviews. They have all been rather pleasant!

The one thing that I read in another blog and that took a lot of the nervousness away from me was that, in the first interview, it is not just you who wants to convince the company to hire you, but it is also the other way around: the company wants to convince you to work for them!

In terms of preparation: have a rough idea of what you will tell them about you and your coding journey. And prepare a few questions for them. I usually have a piece of paper with some questions on my desk when I am doing these calls. What you will ask them depends on who you are talking to. If you are not talking to someone from the Elixir team, you will likely skip the more technical questions. I use the first interview to find out how the company works, whether they work asynchronously or if there are a lot of meetings. You can try to find out what the workflow and onboarding would look like. How flexible you are in terms of working hours etc.

I also recommend figuring out a ballpark for the salary you would like to get for the job. Especially if the job ad did not include salary information, they might ask you during that first interview how much you expect to get paid.

All in all, I think the best advice I can give for this first interview is: be yourself! Be confident in what you know and honest about what you don’t know. If you are a junior developer, embrace it. Signal that you are willing to learn and to work hard.

6. The take-home assignment

Some companies give you a take-home assignment that you have to submit before they proceed to the technical interview. This is your opportunity to shine. Give it your all, but at the same time, don’t overthink it! What worked for me was my usual approach of planning the big picture and then breaking it down into smaller steps. Make sure your code works. If at all possible, write tests for your assignment, add typespecs and if there are optional steps mentioned in the assignment that you are able to do, do them. Once again, demonstrate that you are making an effort and are taking the assignment and the job opportunity seriously.

What I like about take-home assignments, other than the fact that I don’t have to code that stuff live, is that, ideally, they also give you an idea of what kind of work you will be doing once you get the job. This can be reassuring when you find the assignment doable, but it can also be a point at which you have to be honest to yourself and admit that maybe you are not a good fit for that particular role. I’m not suggesting that you give in to self-doubt as soon as it arises (for me, that would be all the time). But if you are not making good progress on the assignment and you find that it would take you an unreasonable amount of time to complete it, it might be that the company’s expectations and your current skill level do not match. If this happens, don’t feel discouraged. The fact that you are not ready for that particular job does not mean you’re not ready for the next one. In addition, the assignment might have given you some idea of what your weak points are and what you need to work on.

7. The technical interview

This is the step that freaks me out the most. I’ve done two so far and they were complete opposites. The first one was a two-hour torture session (at least that’s how I felt) that included a presentation of my take-home assignment, follow-up questions and then pretty much just one big architectural, problem-solving question based on the company’s specific app and requirements. I passed, but I didn’t feel good afterwards.

The other one was just 30 minutes of general knowledge questions. I think I did okay, but I haven’t heard back yet.

I’m not sure if I am qualified to give advice on this step, but here are my takeaways:

If you receive advance information about the interview, read it thoroughly and prepare accordingly. In the case of my second technical interview, I was told during the culture interview that they would set up the technical, so I just asked at that time what to expect. Stay calm. I think it’s okay to think through your answers before you say something. If it’s a problem-solving question, you could try to think aloud, so the interviewers can see how you are working through the problem. And once again, be yourself, be honest about what you know and what you don’t know (yet).

Bonus tip: the waiting game

No matter what stage of the application process you are at: be prepared to wait. A lot! It might take weeks before a company contacts you after you submit your application. You might not hear back after the technical interview for quite a while. And you might wait for the contract for what seems - at least to you - like ages.

I am not good at this patience thing. And to me, all this waiting is quite a challenge. Especially since it is such a stark contrast to the excitement of the application and interviewing phase. It leaves me far too much time to doubt myself and lose confidence in my coding skills. The remedy I found for me is to write code and to be productive in other ways (like this blog). So if you are the impatient type, like me, I highly recommend brainstorming for ideas of how to keep yourself occupied during the waiting periods.