I am a strong believer that being perfect at technical interviews and being able to write high-quality code are not the only ways to land your first job as a developer.

Instead of focusing solely on technical skills that I knew I couldn't acquire (and very likely still haven't developed 🙊) in just one year, I focused on business and soft skills to show what value I could bring to the company.

And that has paid off.

Hello, my name is Julia and I'm a self-taught front-end developer in my thirties who switched career into tech after studying Japanese and musicology while working part-time at a casino.

In this article, I want to share my experience of how I got my first job as a developer. I'll demonstrate the skills I just mentioned using a project I think we've all developed: A calculator.

What to gain from a single project

I often read that a calculator should not end up in your portfolio because it is simple and not unique enough, and maybe they are right. But a project itself can be so much more than just the code.

Applied skills you can show and demonstrate during the interview and convince the interviewer that you know so much more than how to write code - which, as we all know, can be googled at any time, while business and social skills cannot.

To show how important other skills are besides programming, I created a simple calculator using JavaScript.

Hint: If you want to add the calculator to your portfolio, you should definitely add more features, such as

• decimal numbers
• that the display of the current number stays on the screen when the user clicks on an operator
• a restart when you click on a number after the last result without having to use the delete key
• or all the already clicked numbers and operators in small format above the current value to know what has been calculated so far

Select 0.5x in the middle of the bottom row to display the calculator completely.

Here is the link to the GitHub Repository.

You will gain skills in industry knowledge as well as tools and technologies such as

Industry knowledge

• Project management
• Time management
• Agile methodologies (e.g. Scrum)

Tools and Technologies

• HTML/CSS/JavaScript
• Git Version Control
• GitHub
• Accessibility
• Testing
• Hosting (e.g. GitHub pages)

That's quite a lot, isn't it? Now that you know what you have achieved, you need to sell it in a professional way.

But first, I want to show you how to present your project on your CV.

Then I'll show you how I would use the above terms during an interview to make the project, how I work, and myself seem professional and valuable for the job.

How to write about this project in your CV

Project: Functional Calculator (View on GitHub)

• Built a functional calculator that not only does basic calculations, but ... (anything it can do beyond that if additional functionality is added).
• Used HTML, SCSS, JavaScript, hosted on GitHub pages to run the app.
• Used Git for version control, wrote tests with Jest and tested for keyboard and screen reader to be fully accessible
• Worked with agile methodologies to track progress of the project by using GitHub Projects: created a project, created and labeled issues, worked in sprints, held sprint reviews and retrospectives, wrote documentation (readme)

Skills: HTML · SCSS · JavaScript · Git · GitHub · Jest · a11y · Scrum

By presenting my simple projects in this way and talking about them in a professional manner, I was able to not only convince people with my CV to get an interview in the first place, but also land a job quite soon after I started looking for a job.

For more advice on how to create a promising CV check out my article 👇

Talking about the project

Let's say the interviewer asks you about this particular project during the interview, something like this:

Interviewer: Can you tell me how you created this project, what you started with, and walk me through the development process and your code, sharing your thoughts?.

I would answer something like this, share my screen and show the project and the parts I am currently talking about on GitHub (and I actually did so during my interviews):

I have tried to be as brief as possible, mentioning only the most important points, and writing in a conversational style. I've also highlighted all the words that make you look more professional because you use them.

At the beginning of the project I was thinking about the whole web development process, architecture and setup and how to track progress to ensure a finished project in a certain time. Of course, that seems a bit of an overkill for this small project, but I wanted to get used to a real development process in a company in a scrum team, the way it actually works (or at least that's how I imagine it), even if I'm a one-man team now.

And I thought the best way to do this is to pretend that this calculator should become a production-ready application that has to go through the whole web development process.

I chose to build the project using HTML, CSS (for now), and JavaScript. To dive a little deeper into SCSS, I later updated the code and created some mixins to familiarize myself with it. Of course, SCSS is pretty much overkill for this particular project, but I did it for practice because I often see in job descriptions that SCSS knowledge is required.

I also thought of using TypeScript because that language also comes up a lot in job descriptions, and I may add it to learn the language since I've never used it before. Even though I'm not familiar with TypeScript yet, I know it's a safer way to program than vanilla JavaScript because of its types, etc. (to the reader: you should talk about everything you know about TS at this point). And it's also a good exercise to get me more comfortable with reading documentation.

Normally I would use CodePen for a small project like this. I think online code editors like CodePen or CodeSandbox are great tools to create a small project quickly and see the output immediately. But as I said at the beginning, I wanted to create the calculator in a real environment. That's why I chose GitHub to do it.

I know there is another great tool called Gitlab that is often used by companies, but I personally prefer GitHub, mainly because of its community, but also because there have been big changes recently.

So I use GitHub to manage git version control, which I know is used to track everything that happens with code. From what I've heard from other developers, it's common for there to be a master branch and for developers to create their own branch from it to work on their problem, and when everything is done, they create a pull request to merge their branch into the master branch.

Since I wanted to practice some common git commands, I did the same on this project. For each issue, I created a separate branch, wrote the code, and when I was happy with it, I created a pull request before merging it into the master branch.

The git commands I used were for example: git checkout -b my-branch, git commit -m "what did I do", git push, git pull, git merge. I know there are many more commands, but I guess I never had to use them due to the size of the project and the team. So since there was always only one branch merged into the master, most likely there were no conflicts. But I am sure I will use more advanced git commands properly.

For the folder structure of the project, I decided to create two folders (or three when tests were written), one for the assets, i.e. the images, and one for the source code. The bigger the project gets, the more folders and the deeper the structure will be, I think. I am very excited to learn how to think about architecture and design system in a real project. I find this way of thinking very interesting.

As far as I know, there are small teams in a company that work together on a project. And as I said earlier that there are topics that are created, and each developer takes a topic that they work on. And the teams work in an agile way, like scrum, which I find very interesting, the whole scrum framework. So I imagine a daily meeting of about 15 Minutes where everybody briefly talks about what they achieved yesterday and what they are going to do today.

I wanted to create that kind of situation for myself as well. I thought the best way to do this is to create a project and issues that GitHub provides. I know there is a tool called Jira often used by companies that allows you to create the whole project and issues and sign developers up for issues.

I think GitHub project is a very good tool for project management, and if I understand the process and function here, I can surely understand Jira quickly.

So I created several tasks, like project setup, writing HTML for the calculator, creating a design using a design tool called Figma (I guess in a bigger team there are designers to do that and I need to convert the design to code, but since I'm a one-man team I did it alone), converting the design to CSS code, adding functions to the calculator, tasks like that.

In my self-study I often see the topic of web accessibility and how important it is. So I wanted to make the app accessible by using only colors with enough contrast. I also made sure that the calculator can also be operated with the keyboard only and that the focus is displayed correctly.

I kept the default value for the outline, but I often see companies use their primary color to display the outline when it is in focus. This makes sense to me, depending on the colors of the app I guess.

There is an extension called Lighthouse that you can run on the project that shows how accessible the site is, or how good the performance and SEO is. I tried to get 100% in each area. But I've heard that even if you achieve 100% in accessibility, it doesn't necessarily mean that the website is really fully accessible. Right now I don't know that much about it, but I hope to do so in the future because I think it's an important topic.

I thought about how long it will take me to complete each task and the project as a whole, added milestones, labeled the items like improvement or new feature and assigned them to me. The GitHub project is a really good thing, providing an overview of all the issues. I guess in a larger project there are a lot more labels, like bugs, defects and more.

I've heard that in a project there is usually a sprint of about two weeks, where the team has to complete a certain number of issues. And that there are meetings like a sprint review or retrospective where the scrum team talks about how things went in the last two weeks, or where they present the completed issues to the stakeholders.

Even when I didn't have stakeholders or such a long development process, I thought about what went well or what I could improve on my next project. I found that I often underestimated the time. I thought this issue would take me about 20 minutes, but it actually took me 1 to 1.5 hours. That was surprising for me. But I will do a better job of estimating the time for an issue in the future after noticing that.

You can also set the project style, for example to Kanban. Like a typical to-do list: Which to-dos are open, what am I doing right now, which to-dos are done. This helped me keep a good overview of the progress of the project.

I also wrote some tests for the project (to the reader: no tests are written so far for the project. But that does not necessarily mean that you cannot talk about testing at this point). I know that there are many tests, such as unit tests, integration tests, end-to-end tests that are used in larger projects. And I've also heard about a lot of automated tools, like preventing someone from committing their code because the message doesn't start with what the company suggested, or preventing merge if no senior has reviewed the PR.

I'm really looking forward to working on a big project where I can see automated testing like this in real life. It's really good for code quality, I think.

I also hosted the project on GitHub so others can see my project and try it out. I also added a readme file where I describe the project in detail, add a screenshot and show how others can use my code too. I added information in the about section of the repository and added tags so others can find the project. And the link to the live preview here and in the readme file.

I think it's important to use a tool to its limits. There is so much you can do on GitHub to make your project stand out in a professional way.

Now let's take a look at the code. In the HTML file, I tried to use different meta tags for SEO reasons, which means that my website can be found more easily, and I set a viewport to ensure good use on mobile devices as well.

I've divided the code into sections for each row in the calculator, which makes it easier to use CSS grids later.

For SCSS, I saved the color, font, gradient, and border values in variables to make them easier to use. This is done so that if you want to change the base color, for example, you only have to do it once and not for every class you use the color in. In CSS you can also store colors in variables.

I've also used mixins that allow you to create a basic style that is then adjusted for certain uses. I put the values in alphabetical order so it's more readable. This prevents repetition of code. But of course, as I said at the beginning, CSS would have been perfectly fine for this size of project. But I learned a lot about SCSS, which is really helpful.

Now let's take a look at the JavaScript code. First, I created a function to differentiate whether the user clicks on an operator or a number to decide which function to call. In the case where the user clicks on an operator (or symbol), a switch statement takes over the function.

I chose the switch statement over the if else statement because I think the combined last switch (whose functionality is handled in a separate function called flushOperation starting at line 64) is more readable that way. At the end, I added the eventListener functionality to the buttons.

And that's it. If you have any more questions about the code or the web development process, please let me know.

That was a lot to talk about on this simple calculator, don't you think? And so many things can be added, e.g. talk more about testing, more about GitHub automation, meta, SEO, accessibility, or topics you are more familiar with than I am here.

For more information about development processes check out my article 👇

I hope you got a sense now of what all is involved in the development process. It's not just about code, there are so many other things you can talk about, and maybe like me you feel much more comfortable with those topics than talking about code.

Also, don't wait to be asked certain things to show off your skills and knowledge. Because the questions may never be asked, or asked the way you hope to be asked.

My advice to all aspiring developers out there

Don't focus on code alone, because most of the time in your job you will be googling for a solution to your problem anyway, or talking about concepts and possibilities with other developers. Focus on how to solve problems, on the mindset of how to develop a product (from the beginning of planning, to the development itself, to finishing the whole process), on business and social skills.

Also, find a niche, something you are good at, and focus on that as much as you can (like I did with accessibility and UX design as a front-end developer). There are so many programming languages, so much to learn. Finding a job in tech means going on a lifelong learning journey anyway.

Be aware of your skills and talk openly and honestly about your strengths and weaknesses, what you know and don't know, and how you would handle a situation if you were unfamiliar with a subject. This will help the interviewer get an idea of who you are and how you would fit into the team. There are a variety of positions on a development team, so there will definitely be a place for you.

---

Thanks for your reading and time. I really appreciate it!