🇬🇧🇺🇸 Beginner programmers, listen here...

Beginner programmers who try to break into the software development market, listen here...

This post is probably going to be a cold shower for a lot of you and you might not like it because it's not all words of encouragement. It's the reality we're living in, and the sooner you accept it, the sooner you can start working on the things that actually matter (and eventually land a software development job).

I have seen so many mistakes in how beginner programmers go about breaking into the software development market, when having no development experience. Is a crazy hard feat to do, especially in these times during the pandemic, where a lot of entry-level/juniors jobs disappeared, or the requirements got harder.

People who a few years ago would have gotten a junior position with little to no effort, now struggle to even land a few interviews. The junior market is more flooded than ever because people are getting sold dreams by scumbag "professional reconversion teaching schools" just to profit off people's hopes, and any junior job available or internship instantly gets flooded with applicants that have only 4 months of total code writing (not software development) experience, in which they didn't even manage to scratch the surface. But these companies are pushing hard with marketing to get to vulnerable people with the empty promise that they will change their lives in a few months and some courses.

But let me tell you what: programming is hard. It is difficult. Getting into this field requires daily work for years just to train your mind to face the kind of problems this job is going to throw at you.

Here are the hard truths about the situation you are in and how to deal with it. There is no magic formula, it's all hard work, and if you don't like what you hear, well... I have bad news for you.

Get busy learning math and algorithms

Math and algorithms are the central piece of software development. Every piece of code deals with algorithms. No matter how mundane your job is going to be, you will have to solve problems through algorithms.

I hear a lot of people arguing "Hey Vlad, that's dumb. I don't need math or sorting algorithms because I won't have to ever implement that. I'll just use a library" but they are exactly the kind of person I'll never hire. They fail to understand the big picture: writing algorithms and doing math problems will build up your algorithmic thinking, that is crucial for problem-solving. I want to work with problem solvers, not with people who, when deal with an error, smash their keyboard chaotically until the problem goes away.

Without algorithmic thinking, all you will be able to do is write code following some specific tasks. Once the task doesn't have all the required information and you'll be forced to improvise, you'll get stuck.

Solving problems is the ability of being able to go from a problem (having a set of inputs and a desired result) and produce a set of instructions for the computer to do get to the correct result every time, in a somewhat repeatable way (heuristics and probabilistic programming are a topic for another time).

I have met a lot of programmers who are not able to do that. That's why when I interview, I follow Joel Spolski's Guerilla Interviewing strategy and ask the candidate to resolve a very simple algorithmic problem. Usually something related to list or string manipulation.

If they get it done, all good without too much help, it's all good. It shows that the person has some algorithmic thinking and can get things done with less guidance, aka will be more independent. My more experienced colleagues won't have to babysit them 8 hours a day. Maybe just 1-2, but they will also have time to do their own tasks.

Personal projects that are not low effort

I usually recommend beginner programmers to start working on personal projects that are using the tech stack they are targeting. Some frontend interface for some public HTTP API if they ware eyeing a frontend career, some API/process heavy thing in Python if they want something backend or data science related, etc.

It's actually pretty common for everybody to have public projects on Github or Gitlab, and advertise them in their CV, so that they are more attractive for the people that triaging the stack of CVs.

But man... I have to tell that a lot of the personal projects I've seen are so low effort that they actually made me refuse the candidate from the get go. Having no public portfolio would have given them a better chance.

"Projects" like tic-tac-toe, password generators ( import secrets; print(secrets.token_urlsafe(20)) ), hangman, to do or task lists are too low-effort. They require at most 30 minutes of work, and if it takes you more than that to complete such project, you are not ready for a software engineering job.

You have to build more complex projects that actually does something useful and you can talk passionately about. As a rule of thumb, a project you should publicly put on your name on should have at least 1000 lines of (decently written) code. You might have some luck with projects with 500-1000 lines of code, but anything less than that won't cut it.

Know your language, I don't want to have to explain to you what a list is

A lot of beginner programmers for some reason expect to learn everything on the job. They do a few hello world programs and then start applying to jobs.

There is a time for learning and there is a time for working. Nobody is going to hire you if they have to teach you the absolute basics. You'll have to learn on your own at least the basics of the programming language you are going to use, and be comfortable with its syntax and basic features.

Knowing the standard library by heart is not a must, that kind of knowledge comes with experience. But there are some types of mistakes that are unacceptable even for an entry level job:

• not being able to iterate lists or dictionaries, or accessing keys/indexes
• not being able to work with files (opening, reading, closing)
• not being able to do fors, ifs and whiles
• frequent off-by-one errors
• not being able to trace and debug issues in your own code. If you don't run your code and debug it, however you might do it (with prints or using the debugger), it's a mistake that will cost your interview.

I'd even as far as adding exception handling and basic OOP to this list (being able to create a class, with a constructor with some methods and instance variables).

I get that "employers need to invest in their employees" but teaching them programming from scratch and what variables are does not count. Sending them to industry specific conferences (eg. DjangoCon) and having paid advanced trainings does. You have to put in some effort to get the ball rolling before you can expect any company to take a risk hiring you.

Remove useless certifications from your CV

When I see people putting every Udemy or Coursera course they did in their LinkedIn profile or in their CV, it's a bad sign. It communicates that they more concerned with hunting things to put into their CV, rather than learning and expanding their skill set. That's not the kind of people who turn into valuable employees. They are usually the kind of people who have no idea how to learn and have no ambition.

If you do some courses, props for you! Keep doing some of that, but also do some projects on the side to apply the things you learnt on your own problems.

Putting Udemy courses on your CV is the equivalent of saying "I have watched some videos on the subject" but there's no value in it for the employer. I can't tell how it helped you, I have no idea what was in that course and how (or if) the information stuck with you.

Conclusion

Get busy learning what matters (improving your algorithmic thinking) and build something useful you can talk passionately about (more than 1000 lines of code).