How I Learned to Code and Got My First Job

My coding journey began about two and a half years ago, and I started working my first full-time developer job recently (wooo!). This might seem like a long time for some of you, but I didn't rush it and wasn't trying to find work until two months ago. Many people have done it more quickly and I was probably ready for a while. So I've decided to share my story, my resources, and what worked for me when learning web development.

How I got interested in coding

I was living in Thailand, training and fighting Muay Thai while working about 10 hours a week as a social media manager. I wasn't really enjoying marketing as a career and it wasn't as flexible as I wished, since I needed to be active at certain hours of the day.

Luckily I had the time to learn something new. I'd looked at a few things online which sounded like good skills to have that were flexible and that could be done remotely. But it wasn't until I met a guy traveling through Vietnam, who was working as a web developer, that I was intrigued and started to play around a little bit with coding.

Where To Learn?

At first, I was jumping around trying out different sites such as Codecademy, freeCodeCamp, and others I can't recall. I never really got anywhere with these to start with but they got me interested.

After researching, I decided to take CS50 - Introduction To Computer Science, a famous Harvard course run by David Malan. It teaches the real basics of computer science such as data structures, algorithms, and the relevant workings of a computer. This is all done in C but the basics you learn and the confidence you build apply to every language.

Once I completed CS50 I started on freeCodeCamp. What I loved about freeCodeCamp most was the projects. They give you great ideas to practice and test your skills as you are learning. Once I got through the first couple of sections on HTML/CSS/JavaScript and onto more advanced topics, I didn't find the lessons thorough enough. So I ditched them for Udemy courses which went more in depth on a topic. Then I could go back and build the freeCodeCamp projects for practice.

I used this combination of Udemy and freeCodeCamp until I had a solid grasp of HTML, CSS, JavaScript, Node, React, and Redux. I also completed all of the projects on freeCodeCamp except for the data visualisation section using D3.js, as I didn't find this skill in demand when looking at jobs.

What Next?

Although I was confident in these skills, I still hadn't gotten involved in open source except for a couple of tiny pull requests. I simply didn't know where to get started. Every time I looked at issues I couldn't see anything interesting. Or those that were interesting had already been claimed by someone else.

Eventually, I got involved with freeCodeCamp as a contributor. I would recommend just making a habit of checking the issues once a week or so to see if there's something that you want to help with.

Along with my work with open source, I also got an internship as a front-end developer focused on React. It wasn't the ideal internship but it was remote and I learned a lot by working on a codebase someone else had built. I was the only dev on the front-end. This presented it's own challenges, like being given a problem and being responsible for researching and solving it. In this time, I learned about and implemented internationalisation as well as React Native.

Getting the Job

I had a strong mix of skills, projects and experience to show off, my résumé in hand, and a portfolio site promoting my work. I was ready!

Getting the job was mostly a game of patience. All together it took me 2 months of searching and applying every day to jobs. Most of the time I didn't hear back. I applied for a lot of jobs which were looking for mid level developers or more experience than I had, which didn't work out. Most of the jobs I found on job boards were advertised by recruiters and I found these the most fruitful. I often received a call and meeting with recruiters who were impressed by my résumé and skills and were looking for junior roles for me.

I was also attending meetups to network and look for jobs. I didn't find any roles directly, as the companies weren't looking for juniors. However, I did meet a recruiter at a React meetup whom I grabbed coffee with the next week. He had a role from a company that was open to juniors and this is where I ended up accepting a position.

The hiring process for this position consisted of a tech test (https://github.com/GlynL/tech-test-prendi), and then an interview where I was actually offered the job at the end. It's a great small company where I'm working with the senior developer and can bounce ideas and get help when I need it. It's a full-stack job, I get to use React daily, and I will get the chance to work with a lot of technologies as projects require them.

When I was interviewing, the thing that people appreciated most was that I had worked on a real application in an internship. Even if I could have done everything in a personal project it proved that I could work on a real world application with other people. I would certainly recommend seeking out internships as this will look great on your résumé and will be a talking point during interviews.

What would I do differently?

If I were to do it all over again, there's a couple of things I would do differently.

For starters, I would get more involved with open source projects much earlier on. There's always something you can contribute to a project even if you are still learning HTML and CSS. You may have to be more particular about the issues you pick up but you can definitely help! The skills you gain in navigating a large codebase and working with others are invaluable. And as you learn more you can pick more complex issues to match your skills.

Secondly, I would also start networking earlier as this might've led to securing internships and/or junior positions. If people know you are searching for an opportunity then they will think of you when they have something. Or it'll at least give you an advantage in the application process as they will know who you are and that you have a genuine interest in the field.

Please feel free to let me know if you have any questions or would like me to elaborate on any of the points. I'd be happy to help!

You can contact and connect with me on Twitter @glynwebdev.

As many of you know, I have been applying for a job in web development for a few weeks and I thought it would be a good idea to share some of the coding challenges I've encountered.

Not only that but I'll share the ways I went about solving these challenges. Granted, there are many ways to solve these challenges but these are the ways I went about it. If you have different ways that's awesome and I'd love for you to share them with me!

I will not share any identifiable information about the companies or specifics on the interview process of said company to preserve process integrity.

Alright, let's get to it then.

The Challenge

This is a challenge I was given recently that I felt good about solving:

Task: Return a basic styled list of posts from an endpoint in reverse chronological order

To protect the company and their information, I will not share the URL from which I returned the information but instead will have a generic link from JSONPlaceholder (a great, free, open source API for developers when you need to get some generic outside data) in the code below.

Here's the HTML I started with so we have something to display our results in:

Basic HTML boilerplate

The

Fetching Data From the Endpoint

Alright, let's dig into the JavaScript portion of this challenge. First, I like to set my output and display variables:

Our variables used when displaying the returned code

I use let for the output variable and set it to null because we will change it's value later in the code. The list variable is declared with const because it's value will not be changing.

Fetching data from the endpoint

In the above example, we’re declaring an arrow function named getData wrapped in a try…catch block (This is a cleaner/easier to use/read syntax that uses tries some code and catches errors if they happen — you’ll also see the catch portion below). Because we're getting data asynchronously we also need to make use of async/await to fetch data. This is the method I'm most comfortable with but I know there are many other ways to get data from an endpoint so feel free to share yours :D

Once we've declared our data variable, the next thing is to set a variable to turn the returned data to a JSON object so we can get it in a usable form. We do that with the .json() method. We're awaiting the data as well because if we were to omit the await keyword, JavaScript would try to turn the data variable into JSON but the data would not be there yet because it's coming from an asynchronous API.

Our glorious data!

As the very last line in the section, we console.log our data that we get back from the API endpoint just to make sure we're getting everything we wanted. We have an array full of objects. You'll also notice that the key _publishedat holds our dates and they are not in any type of order. Their format is also not a simple four digit number representing the year which would make it easy to filter them into reverse chronological order. We'll need to take care of that.

Manipulating Our Data

Making a copy of our data variable

Here we declare the variable dataCopy which points to the dataJSON variable mutated into an array via the _spread operator(...)_. Essentially, we are copying our returned JSON data so we aren't manipulating the original (bad practice) while making it into an array so that we can iterate over it.

After, we _sort_ the array. Sort is an extremely useful array method that will put our array indices into the order of our choosing based on the function we pass into sort.

Typically, we might want to sort the data based on value (largest to smallest) so we subtract the parameter a from parameter b. But because we need to display our results in reverse chronological order I decided to produce a new date (accomplished with the new operator and the JavaScript built in method _Date that creates a new platform independent formatted instance of a date. Now, because a and b_ represent our objects sitting inside our array indices, we can access the key/value pairs held within said objects. So, we subtract _b.publishedat from _a.publishedat and this should give us our dates in reverse chronological order.

Displaying the Fruits of Our Labor

Remember that output variable we set to null at the very top of our program? Well now is it's time to shine!

That output variable is earning it's keep now!

So, there's a few things going on here. First, we're setting our output variable to a new value by mapping over our dataCopy variable using the _map_ method. This method returns a new array with the results of calling the provided function once for each index. The item parameter represents our objects inside of our array that was returned from the endpoint and thus has access to all of their properties such as title and _publishedat.

We return two list elements with a inside each one (for styling purposes), as well as a string for the Title and Date Published headings. Inside of those, we have our variables that use template literals to set the title and the date for each post.

Then, we set our list variable's innerHTML equal to that of our output variable.

Finally, we have the closing bracket and error handling of our try...catch block as well as our function call:

This code will handle any errors and display them in the console

Final Code

Here is what our full code body looks like now:

The entirety of our code base

And here is our basic CSS styling:

Did I say basic styling? I meant basic :D

And here is the result of our work with it's very basic styling:

Isn't it beautiful?

As you can see, we accomplished what we set out to do and in fact the list is in reverse chronological order. Yay!

I hope you've enjoyed this walk through of my thought process and of how I solved this challenge. Granted, there are many ways of completing this so feel free to share yours with me! I'm excited to keep this series going and will post another after I've gone through another challenge!

Also, I cross post most of my articles on great platforms like Dev.to and Medium so you can find my work there as well. This article was originally posted on my blog on May 27, 2019.

While you’re here why not sign up for my Newsletter. I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

Have an awesome day filled with love, joy, and coding!

I'm a Dutch developer, and I recently graduated with a bachelor's degree in IT. I'm fully blind and use a screen reader to do my job.

I walk the treacherous path of the blind developer - a path I will describe, as well as the various traps it contains.

I've worked for various companies as a back-end web developer who is slowly but surely also migrating to more and more front-end work, the technological landscape being what it is.

I have worked with a variety of technologies, from c# to Python and from Rails to JavaScript.

I am also an accessibility expert, familiar with the usual suspects such as WCAG, ATAG and friends. What I mean by proficient in this case is that I have used these skills in a professional setting by performing accessibility audits on websites, web applications and desktop applications.

I have also amassed theoretical knowledge by going through the Deque University training program, which I can highly recommend if you want a firm grounding in accessibility fundamentals.

This proficiency with accessibility regulations is mainly a consequence of the fact that I myself require content to be accessible in order to be able to use it.

This description will at times be factual, at times opinion-based. Most of the time, it will be the experiences of a single individual who writes code for a living without using his eyes to help him see what he's doing.

I am hoping this tale will shed some light on my workflow and the things I have to deal with to keep that workflow going on a regular basis. Finally, it will be a snapshot of sorts of all the things I've learned and am still learning about this process.

Starting your journey: getting a foot in the door

In order to work for a dev team with sighted colleagues, you obviously will need to get hired first. Making that happen means you need to hop over some interesting gotchas that may not be immediately apparent, which is why I dedicate a section of the article to it here.

Job hunting as a blind developer is an interesting activity. Just like anyone else applying to any job ever, it starts with a resume and in most cases a cover letter.

A question I initially faced was whether I should immediately notify the company of my blindness or not. I've found that generally, it's better to not do that because of the simple reason you put unnecessary emphasis on the blindness if you do.

I am a developer with qualifications, experience and skills I have earned and worked hard for, and those are the merits I want to be hired for.

Being blind, to me, is an inconsequential thing next to those skills, unless it can somehow be an asset to the position. This would for example be true for an accessibility-related position.

This has led to some rather interesting situations, from bewildered looks at my white cane or, later, guide dog, to hastily devised excuses to end the job interview prematurely.

Although discriminating against someone with a disability is illegal, it is at times rather easy to disguise as something else. This is something to look out for. Fortunately, this doesn't happen all that often, but to not mention it here would be playing fast and loose with the truth.

It is a careful balancing act in the best of cases. These days, I tend to mention my blindness at the very last moment when I negotiate a job interview over the phone, by stating I will be bringing a dog to the office and asking if anyone is allergic to dogs. Usually, the next question is a very understandable "Why?" and only then will I mention it, minimizing it as much as possible. Most of the time, this approach has given me at least a chance to come in for a first interview.

Other obstacles are mandatory screenings or assessments that are not accessible, these are generally standardized tests that cannot be deviated from according to the company you are applying for.

This has the usual consequence of generally ending the job interview procedure right there. Obviously, the issue can be forced but in the vein of creating a positive working environment, this is really not something I can recommend.

This has to do with the above mentioned emphasis on your status as a blind person. The more you make an issue of it, the more importance it gains for the person considering your job application.

What follows is generally an almost scripted procedure. The job interview goes off without a hitch in most cases, but gains an extra component I like to call the "Monkey show, Monkey do" portion.

This part of the interview is usually preceded by a question like: "You can probably imagine why I ask, but ...how? How do you program without looking?"

At this point, I explain about screen readers, the blazingly fast rate they spit out information at and I usually get out my laptop to give a bit of a demonstration.

I usually get stares of amazement. Once people even clapped for me.

Although that is of course very flattering, being stared at in admiration for doing something that is second nature has a tendency to get old from time to time. This is nothing personal. It's just possible that you are the third person doing so today. Answering the same questions over and over certainly falls in that same category as well.

As a result, I wrote an article, my first one on freeCodeCamp in fact, to answer some of the questions I often get when it comes to being a blind developer.

Fortunately, both this demonstration as well as this momentary period of being stared at usually doesn't last very long. I've found that doing this makes it a lot easier to explain why something is or is not a challenge further down the road.

Being put on display like that - although sometimes uncomfortable - is very much worth it in the end. After all, the reactions are understandable. I am doing something a lot of people can't even imagine doing without sight.

Picking your tools: The constant Struggle for the constant Juggle

For various pursuits, you require a set of tools to be effective. Climbers will need rope, anchoring hooks etc. And programmers require tools to program, test, collaborate, share and look up information etc.

Unfortunately, this is where a lot of people quit. Perhaps even more unfortunately, this is totally understandable.

The amount of work you have to put in to get a decent stack going that works for your use case - on top of your normal 40-hour work week - can be a bit overwhelming.

The operating system is the first hurdle. A lot of dev teams here in the Netherlands use Macs exclusively. Sadly however, the accessibility APIs available to the MacOS screen reader, Voiceover, is in a lot of cases inferior to those in Windows.

The amount of keystrokes required to perform a task on the Mac is often higher than on Windows, with MacOS being a very mouse-oriented operating system.

Finally, the screen reader itself lacks a lot of the convenience features and customization options of it's Windows counterparts.

In an industry that is supposed to be equally accessible to both the blind and the sighted, these shortcomings translate into serious productivity hits in comparison to my sighted colleagues. This can be stressful and requires some understanding and flexibility from my colleagues at times.

Once you're familiar with a codebase and tools have been sorted out, you can perform a lot of tasks just as fast as sighted colleagues.

Achieving that familiarity however, can take time. Especially if tools are not as accessible as they can be. You can lose precious time wrestling with a tool that is supposed to help you in your work, but rather, hinders or even blocks you entirely.

Fortunately I have usually been met with understanding and, a lot of times, curiosity about the shortcomings from my sighted colleagues. This isn't something to depend on though. When a lot of work needs to be done in a short amount of time, every productivity hit is in a sense one too many.

To alleviate these problems as much as possible, it's paramount that you know every little shortcut and trick of the trade in your tools of choice to shave off time wasted on actions you repeat all the time. Macro keys, shell aliases, editor extensions that give you more keyboard shortcuts - these are the name of the game.

But sometimes the tools that are supposed to help you will get in your way instead. Where my sighted colleagues often use graphical tools to manage certain aspects of their jobs, these tools are often inaccessible. This requires me to - often on the spot - figure out some kind of workaround to still perform the same task with some modicum of efficiency.

For a graphical application, this might be a command line equivalent. A website might have an API. Sometimes, a second graphical tool might work better than the de facto one. Constantly puzzling out alternatives for inaccessible technology is a constant part of the job when you do it with your eyes closed. Getting the freedom to bring your own tools is very important for that reason.

I've rarely seen tools being enforced because developers generally have a strong preference for their own workflow. But for the jobs that do insisted on me using specific tools, this often becomes a dealbreaker for any future contracts I would take on. Tools are that important.

Your first thought might be to just use Windows if MacOS makes you less productive. In an ideal world, that would be a viable solution. However, especially in older codebases, dev teams have often devised little hacks to make older code run on their newer hardware/software that shouldn't even be running anymore in the first place. These hacks are OS-specific, and are often hard to replicate on Windows - even while using the Windows Subsystem for Linux. They can sometimes take weeks to get working. It's often not worth it.

Right now, for that reason, I am almost mandatorily running a Windows 10 virtual machine within Vmware Fusion on the Mac. I am forced to use two operating systems at once to get my work done. Windows holds my web browser, my code editor of choice and various other tools I use to increase my productivity:

• Google Chrome
• VS Code
• a decent PDF reader
• an office suite for working with DOCX and XLSX files

Basically all real applications run on the Windows VM, making the MacOS part more of a server that just hosts the application code.

This is a good example of the freedom of to use your own tools I referred to. Nobody else in my team runs the same setup I do. But doing this has generally been met with understanding and support from my colleagues because they can see I can get work done this way.

Accessibility, especially in dev tools, can be incredibly hard to defend. Often you are not being taken seriously when you ask for what should be a basic feature. In a sense, you are merely asking to be able to use the application.

But it is not on the roadmap, developers can't be spared to work on it, it doesn't have priority, etc. Are reasons for not fixing a tool's accessibility almost like clockwork. Other times, promises are made for fixes that never materialize.

I would love to see this improve, and have had the pleasure of seeing it happen now and again. It is still a problem that keeps coming back though and as developers, me included, we should do better.

My sighted colleagues take a lot of tooling for granted. In a .NET team for example, it is rare to see a developer that isn't using Resharper to boost their productivity.

Ironically, this extension for Visual Studio, itself quite accessible, uses a lot of keystrokes to do what it does. You would think that would make it an ideal tool for a blind developer, who only uses a keyboard to code. However, the output of this extension is more often than not inaccessible, rendering the tool more of a hindrance then an aid.

I have been hounding Jetbrains for years to get them to fix this tool's accessibility, which even at the time of this writing is abysmal. I have been impolitely dismissed, ignored and finally made promises to, so far unfulfilled. This unwillingness to fix what is obviously a problem that has been there for years makes me hesitant to commit on a .NET-based position. Even if the problems get miraculously solved, the track record of leaving it unsolved for so long would make me wonder when it's going to break again.

In one of the first dev teams I worked with, Postman was used heavily to test API endpoints the back-end developers created. Postman has a number of glaring accessibility issues that make it hard to use with a screen reader. For a perfect example of unfulfilled promises, have a look at this GitHub issue. Observe that the issue is still open after almost 2 years and promises are made but not being kept.

Accessibility is often an afterthought, something that is undeniably proven again and again. Slack, sadly, is a good example of this. The accessibility of this now almost undismissable tool was abysmal, screen reader users could simply not work with it.

We are definitely seeing improvements in that space, something this article aptly demonstrates. But the amount of time all of this takes is incredibly high - months, at times years, that people using a screen reader cannot adequately access resources their colleagues have access to. This kind of deficiency can and does cause people to lose their job because they just can't keep up with the communications within the company they work at.

The tools mentioned above (Resharper, Slack, Postman etc.) are key players in their chosen fields. Not having access to these tools hamstrings you as a developer and forces you to spend cycles you should be spending on getting work done on finding workarounds and alternative tools instead. This is wasteful, tiring and shouldn't be necessary, but it is and it is one of the core skills I've had to get very good at to keep up.

As time goes by, I will say that there seems to be a downwards trend of this being necessary, though. Efforts of Microsoft, Apple, Google and other big players are making more and more people aware of this almost constant battle for equal access to productivity. By no means are we out of the woods though, something that was quite clearly demonstrated by the Gutenberg WordPress debacle that is currently raging through the accessibility community.

Blind people are a niche market to software and web developers. Blind developers are a niche market within a niche market.

Blind developers who keep at it, become productive and hold a full-time job, are sadly even more rare. This can and should change, but until that happens the fight for accessible developer tooling is one you fight on your own. I hope it is a fight we won't have to fight in the future, I will do my best to contribute to that goal.

Odds and ends

I want to end this article on a positive note. The fact that I am still in this field, the fact I hold a full-time job as a developer brings me a lot of happiness even through all the seemingly constant obstacles. I'm happy I can contribute to a great team of colleagues that treat me as an equal and think with me when I run into something I am having trouble with.

I want to emphasize that even though the field of computer science is not free of obstacles, people can thrive and are thriving in CS-related jobs. The struggles described above are certainly true, but compared to other fields they are at least to a large degree manageable. I doubt that I will write an article any time soon about my career switch to a surgeon, a fighter pilot or a professional baseball player, but then technology might yet surprise me. For now though, I'm happy where I am and have a great team around me.

I am often asked for my opinion when it comes to the effect on the accessibility of the product we are working on. My opinions definitely aren't always going to cause things to change, but I'm glad I am at least able to make people aware of the importance of accessibility and what will happen when it is being disregarded.
I am, after all, a living breathing example of just what happens when a tool is not or no longer accessible.

The WordPress article linked to above sends this message very clearly; a tool that has been very usable and accessible for years is now nose-diving. This is something that can happen to any tool a blind developer depends on, the Russian roulette of the business so to speak.

By writing articles like this, by giving talks, educating developers and by experimenting with new tools, new techniques and new methodologies I hope to stay ahead of the curve. By writing down my findings, I hope to teach others the tricks of the trade I found out by trial and error so the threshold to this field is lowered for screen reader users.

The main goals of this article align with many, if not all of those goals. I hope I have given you a glimpse into both the struggles as well as the positives of a blind programmer.

I hope I have pointed out that even though doing this is possible, we can and should improve the experience immensely. I hope I have sparked the readers of this article to think, really think, about the consequences of inaccessible software and I hope I have shown off that even through all the obstacles, it is very possible to become good, even great in this field once you achieve escape velocity.

In light of the positive note I was just referring to, I want to end this article by mentioning two huge accessibility wins that are perfect examples of how we have done better, both of which I have been an honored contributor to.

For learning how to code, a lot of the more interactive resources out there like Codeacademy are not very accessible. This has to do with various components that are used in these projects not being accessible. Fortunately, this is already being worked on.

One of the resources that has been gaining a lot of traction over the last few years is freeCodeCamp. This initiative used to have some rather severe accessibility issues which very recently have almost been completely fixed and overhauled, making the platform very viable for screen reader users who want to learn how to code.

This has a lot to do with the Monaco Editor which is a very accessible web-based code editor and is in fact the editor component Visual Studio Code uses. This editor, when it came out, was literally completely inaccessible. However, in a relatively short time this was not only fixed to a large degree, but now makes projects like freeCodeCamp accessible by default because they use the same component. This is the way it should always be, this is what I am hoping to see more of as I keep at this. And with that, I think it's high time I get back to programming.

"Do you have any advice on finding a job as a developer?"

Many people have asked me that question, but I can’t give a proper answer because I have never been hired as a developer before. What I did was:

1. Wriggled my way into a Wordpress dev role in an admin-based internship
2. Freelanced
3. Run my own company

So I'm horribly inadequate at answering a question about finding a job.

But Chris Lienert is an expert at it. Chris has experience hiring and building teams of excellent developers. (A fun aside: He used to co-run CSS Singapore, which is a monthly CSS Meetup in Singapore).

I managed to grab Chris (before he left Singapore for good) and asked him to talk about the job application process. You'll hear golden advice in this interview from Chris, like:

1. Chris' opinions about the hiring process.
2. How to improve your chances of getting an interview
3. What to do if you don't get a job
4. How you should write your CV
5. What to do during the actual interview
6. What questions to ask during the interview
7. How to answer any tricky questions you get

Note: We jumped around a lot in this 1.5 chat because Chris has so much to say about this topic. I highly recommend you listen to the audio version if you can.

To make it easier for you to digest, I also summarized what we talked about into three stages:

1. Preparing your CV/Resume
2. Before you apply for a job
3. The interview process

Your CV / Resume

It's hard to write a CV. On one hand, you want to pad it with enough information to make you attractive. On the other hand, you want to keep it short enough for recruiters to not hate you.

(Note: I use the word "recruiter" to describe anyone who participates in the hiring process).

We'll first talk about three keys to writing a CV before we talk about the structure of the CV. The three keys are:

1. The Crayon Test
2. Keywords
3. Differentiate yourself

The Crayon Test

Recruiters are busy. They have to go through hundreds of applications for each job opening.

This means recruiters will scan through your CV quickly. They'll put away your CV immediately if there are any spelling errors. They will also put away your CV if you miss out any important information (like your email or phone number).

Chris calls this The Crayon Test. (Because it tests whether the candidate is able to fulfil basic requirements like spelling their name correctly).

What you should do is make sure your CV is clear and understandable. It should not have any spelling mistakes. It should contain the necessary information a recruiter needs to contact you.

Keywords

Make sure you have the right keywords for the position you want to apply for. For example, if the job ad is for a "React Developer", make sure you have "React" somewhere on your Resume.

You need to do this because people (and machines) scan your CVs for keywords. If you don't have the necessary keyword(s) in your CV, you'll get passed over for someone else EVEN before you get an interview.

Back to the "React Developer" example. If you don't have enough confidence in React, you still need to find a way to put React in your CV. Good ways to include keywords (if you don't have the skill) is to put them under Job Experience or Community. More on this in the CV structure below.

Differentiate yourself

What makes you different from thousands of other applicants out there?

If you're a fresh graduate, the answer is nothing.

You need to make it SOMETHING.

There are a variety of ways to talk about your passion and experience in this industry (even if you haven't got a job yet). Some ways include:

1. Notable Codepen projects
2. Your projects on Github
3. Things you built before (on your own, not by following tutorials!).
4. Articles you've written
5. Contributing to open source

Most of these can go into the "Community" section of your CV. More on this later.

Length of your CV

Your CV should be short. Keep it to 1-2 pages if you're starting out.

As you gain more experience and want to switch to more senior roles, your CV can go beyond 2 pages. (Chris' CV is four pages longs. It needs to be that long to show he has the qualifications for a job at his level).

The structure of your CV

The structure we're proposing here is drawn from Chris' experience. You may find conflicting information elsewhere on the internet. Take what you need.

Your CV should contain the following things:

1. Contact Details
2. Summary
3. Skills
4. Experience
5. Education
6. Community
7. References

Contact Details: This section should contain information about yourself. You need to have these three items to pass the Crayon Test:

1. Your name
2. Your email address
3. Your phone number

Summary: Summary is a one-liner of what you're looking for. You want to be clear here. For example, "I'm looking to be a frontend developer in a great team" is a good one-liner.

Skills: This is where you showcase 5-10 skills you're good at. No need to put version numbers because they're irrelevant. Example:

1. HTML
2. CSS
3. JavaScript
4. Node
5. Making simple web animations

There's no need to list your years of experience on a skill. It doesn't matter. If you work hard, you can become great in 12 months.

Don't lie about your skills. Only put the ones you're confident in because you may get questions on each of them.

Experience: This is where you write about your job experience. For each job experience, you should have:

1. The company name
2. A one-liner explaining what they do
3. When and the duration you worked on this job
4. 3 bullet points of what you learned from this job that's relevant for the position you're applying for.

It's a good pattern to have at least 18 months to 2 years per job experience.

If you have a time-gap between jobs, you want to state what you did during the gap. Freelancing, backpacking, etc. Stating this gives insight into how you developed yourself since school.

If your experience is not relevant to the job (like if you're a waiter/waitress), then simply say that and move on.

Please DO NOT LIST the things you DON'T want to do. It might get you the job, but you'll be miserable in it.

Education: This is where you list your education experience. Create some bullet points if you have experience that's relevant to the position you apply for. Otherwise, just list your certification and move on.

Community: This is where you can stand out if you don't have prior job experience. Here, you want to talk about what you do for/in the web community. You can include things like:

1. Attending conferences
2. Attending meetups
3. Talks you gave
4. Articles you wrote (that's not on your own blog)
5. Videos you made

One way to game the keywords (if you need to) is to include the keyword in the title of your talk/article/video.

References: References are people who vouch for you. They can be hard to get in the early days of your career. Omit if you don't have any.

Your cover letter

Some companies require a cover letter. Keep it short if you need to write one. You don't need an essay for our industry.

Your cover letter should contain these three paragraphs (in your own words):

• Paragraph 1: "Hi, I'm X. I saw your job. It looks good and I want to apply".
• Paragraph 2: Why you fit the role
• Paragraph 3: You can reach me at [this number].

Before you apply

Most job requirements seem daunting. Everyone is looking for some JavaScript experience. Everyone want React Developers. Some even want Full Stack developers.

What can you do?

We'll talk about four important things you need to understand. Some may create a paradigm shift for you. They are:

1. Why some job ads suck
2. Imposter Syndrome and minorities
3. The "Full Stack" developer
4. Keep applying

Why some job ads suck

The person who hires for the person and the person who crafts the job ad may be different people. This is especially true in large companies.

If the person who crafts the job ad knows nothing about the industry, they may require "10 years of React experience" even though React has been out only for 6. This is why you see jokes about bad job requirements all over the place.

To put your bias aside, people do try to improve their job ads. Chris, for example, does this.

In the interview, Chris shared about an experience where he rewrote a job ad. And he gave the HR strict instructions to post the job as it is. But when Chris looked at the actual advertisement, he didn't recognize the ad. It was butchered badly.

The key takeaway here is: Don't be too concerned about what's written on the job ad. It might have been inflated with unreasonable demands.

Imposter Syndrome and minorities

If you feel like a minority, you've labeled yourself as a minority. It doesn't matter if you're a white male, or a black woman, or an Asian, or anything else. Chris, for example, is a white male that feels like a minority because he doesn’t feel like he easily fits with anyone else.

The thing about minorities is minorities have high rates of Imposter Syndrome.

• They wonder if they're qualified for the job.
• They wonder why people should pick them over so many qualified candidates out there.

As a result, most minorities only apply to when they feel they're qualified for the job. This means apply to jobs if they can meet 80% of the job requirement. (On the other hand, majority candidates apply for a job if they meet 30% of the job requirements).

This is insane.

Minorities are usually better candidates because they have to fight through lots of barriers. They have better skills, better attitude, they work harder, and they know more about they're doing.

What this means is: If you're a minority candidate, please apply to more jobs. Apply to jobs even if you don't meet 80% (or 100%!) of the requirements.

Don't worry about meeting the requirements. Apply if you are confident you'll be able to do the job (and you're able to learn on the job).

Job ads are often inflated. Remember that.

The Full-stack developer

Many jobs require a "Full Stack" developer experience. This puts pressure on developers to learn the "Full" stack (and it makes them feel inadequate in the process).

But how full is a "Full Stack"? Do you need to know databases? Do you need to know how to write server code? Design? Draw? UX? There's no concrete definition for a Full-stack developer.

Most companies don't actually want to look for a full-stack developer. They think they want to look for a full-stack developer based on what they know.

They'll only interview you if your CV matches what they think is "Full Stack". They might be wrong. And they might not even know what they need.

What this means is: Don't worry about getting a full-stack experience. Read the job description, apply, and ask questions during the interview (more on this later).

Keep applying

It can be dispiriting to apply for jobs. You'll get rejected (many times without even knowing). It sucks.

It doesn't matter where you are in your career. If you're looking for jobs, the same thing will happen. You'll still get rejected.

Chris is a top qualified candidate in what he does. He shared with me that during his recent job search process, he applied for 16 jobs, but only heard back from 3.

Even Chris can't get interviews at places. (I thought Chris wouldn't have a problem with finding jobs). But this just shows how messy the hiring process can be.

It's hard to get over a rejection. You're emotionally invested in the process, so it becomes especially hard.

But you got to keep applying for jobs. You have to continue to review your CV and Cover letter.

Don't give up. You'll get a job eventually if you keep it up.

During the interview

Interviews are nerve-racking. We'll talk about five things in this section:

1. Feeling nervous
2. Whiteboard interviews
3. Answering tricky questions
4. Questions to ask
5. Be honest

Feeling nervous

You are going to be nervous. You're going to be frightened out of your mind. It's normal because you're getting tested.

You will stumble as you answer questions. You will get something wrong during the interview (only to remember the actual answer later on).

It's okay to be nervous and mess because everyone will be nervous and mess.

Hopefully, this makes you feel better. The more relaxed you can be, the better. But don't stress yourself to be relaxed.

Whiteboard interviews

Whiteboard interviews suck because people test you on the wrong things. You won't be writing code on the whiteboard in your job, so it makes no sense to create a whiteboard interview.

Chris argues that interviewers should mirror the person's job as much as possible during the interview. If you're hiring a developer, you'd want to put a laptop in front of them.

If you want to observe what they do, you can mirror the laptop onto a screen so you can observe from afar. This way, the developer can focus on coding.

We didn't answer how to tackle a whiteboard interview during the chat, but you might want to take what Chris said in mind. Maybe you can request for the interviewer to put you in a comfortable space to perform? It's not always possible, but it might make you stand out in the right way :).

Answering tricky questions

You will face at least three tricky questions during most interviews. They are:

1. What's your strengths and weaknesses?
2. Where do you see yourself in 3-5 years?
3. Why did you leave your previous job?

You'd want to prepare answers for these questions (and any others you can find). Chris has some thoughts on how you should answer.

What's your strengths and weaknesses?

There are no good answers for this question. What you want to do is avoid any bad answers that can skew what the interviewer thinks of you.

The key is to be honest while being tactful. You can't be boastful because they'll take note.

When you answer the question about your weakness, you want to say what you're doing about it and explain why you're good for the job.

Here's an example Chris gave:

I was a team leader for 10 years. In the first five years, I didn't understand what being a team leader was about. I focused on myself. It took me a while to realize that the benefit I provide as a leader is what we produce as a team and not what I produce as an individual.

My weakness then was I was too focused on the individual and not very a good leader. And I did something about it.

My weakness now is: I'm not technically as strong as I used to be, because I spend more time making sure everyone is doing their job properly and happily than focusing on my technical side.

(This weakness makes a great manager).

Where do you see yourself in 3-5 years time?

This question gives an insight into what you're looking for. If you say something along the lines of moving up the career ladder, it hints that you're not interested in the job itself.

If you're looking to be a frontend developer, a good example is to say you see yourself coding for the company. Keep it direct and straightforward.

Example from Chris: "My focus then is a job where I can code. My focus now is to make the company I'm working for succeed. I'm going to code really well and lead the team really well.

Why did you leave your previous job?

If you left your job because it's a toxic environment, you want to be specific about what made it toxic.

We didn't tackle this question any further in the chat I had with Chris, so I don't have concrete answers for you if you got bored and simply wanted to switch.

Standing out

You need to sell yourself during an interview so you stand out. You can do this by answering questions the interviewer has not asked.

Tell them the things you listed on your CV. Tell them about contributing to open source, attending meetups, conferences, blogging, and anything you can think of that helps you stand out.

It is the nature of our industry to think creatively. If you managed to solve a problem in a useful way before, talk about it. It'll put you in a good light. The more you've done this, the more you're of a right employee.

Questions to ask

As much as the interview is interviewing you, you're also interviewing the interviewer. Remember this.

Chris says he'd ask two questions:

1. What will I be doing if you sit me down at my desk and put a computer in front of me?
2. What are the skeletons in your closest?

What will I be doing if you sit me down at my desk and put a computer in front of me?

This question tells about the work you'll do day-to-day with the company. If they say something concrete about the work that you align with, good!

But be aware that expectations don't always line up to reality. If this happens, Start applying for another job.

What are the skeletons in your closest?

This question means: What are the dirty things I should know about your company? To me, this question flips the "What's your weakness" question back to the company.

You'd want to hear what they want to hide. You want to test their honesty as well. If they say everything is perfect, they're lying.

Everyone will try to sell you the job if they're interested in you. They'll tell you about shiny frameworks and greenfield projects. But when you show up, they might ask you to work on legacy systems.

Be honest

Always be honest. It's not going to work if you bluff.

The worst part about lying is you might get the job. And then you're screwed because you're expected to perform.

Final words from Chris

So much about finding a job is not cutting yourself out of the process.

They're only looking for one person for the job. The odds are, you're not going to get the job. So how do you NOT get eliminated? How do you move on to the next stage and meet the next boss?

You'll feel awful if you get rejected, and you're going to get rejected a lot. You'll also get interviewers who are awful and you come out of it feeling awful. But if you don't apply, you'll never get anywhere.

You nothing much to distinguish yourself from other candidates at the start. It boils down to your luck. You have to play your odds. If possible, get someone in the industry to check your CV for you. It helps.

Good luck.

Please thank Chris Lienert for spending his time with us if this helped you. You can reach him through Twitter.