Becoming a developer

My name is Rodrigo Pontes and this is my personal blog with thoughts on my path to becoming a software developer.

There is no fixed schedule for posts (yet). So please leave your email if you want to be notified of future posts:

Up to September 2016, at 37 years old, all my professional experiences were around sales and marketing. In November I started to study web development full-time. In June 2017 I was hired as a junior front-end web developer at a medium-sized startup. I want to share what I was thinking in October, the month I decided to change careers.

A decision based on passion and money

This would be the title if I were to share this post on LinkedIn redacted by a BuzzFeed editor with a penchant for soap operas. And a very misguided title it would be. Basing a professional decision in potential money is not a very good idea. Basing a professional decision in passion is a terrible idea.

Passion frames the decision the wrong way and is detrimental to the point, joy provides a better context. The lure to advise someone to follow their passion on their career decision is understandable. Passion is both clickbaity and aspirational, making it the sugar of processed career advice. It tricks your brain into making you think that you should care about whatever is consumed with it. The little truth in this advice is that how you feel about a profession should indeed count on the decision. But passion gives you a context of absolute, urgent feelings welded to present-time circumstances. For decisions that will shape years in your future, it is better to base them on more relative, perennial feelings aligned with more fundamental values.

I believe a better concept might be 'joy'. Do you enjoy the everyday activities you will be executing in this profession? But it is tricky. Joy is a feeling and feelings change a lot and we project them through all dimensions of our lives. So it helps to think relative to other potential professional choices, not comparing to leisure activities or in absolute terms. On a good day, when you are happy with your friends and family, it is a great sunny day out there and you have to work: would you prefer to be coding or working in one of your other career options? And on a bad day, feeling sad and confused with some personal issues you don't know how to solve and you have to work: would you still prefer to be coding than the other work options?

Money is part of the equation, but a too narrow focus on it is counterproductive. Money fulfills a useful role as a goal and, for some people, as motivation. But obsessing about it increases the ever-present pernicious risk of letting the outcome overshadow the process. The practical effect of it is to make us think we deserve the outcome and not that we should earn it, which nearly guarantees a life of under-achievement and frustration. Software development is full of high paying jobs, but money is the outcome of job performance and career choices. Small digression: Luck is also a factor, but it is a constant of the equation, not a variable we can control. Office politics is yet another factor, but even if some people can use it as a controllable variable to earn more money, it is more of a constant when considering the decision of changing careers. End of digression, back to thinking about career choices and job performance.

So consider what are your career choices on software development. A good start is to answer this question: "How good are the jobs in my area that would be suitable for me?" Your area can be your city or your country if you are ok with relocation. It is hard to start as a junior developer in another country, the same for remote jobs. Don't include these possibilities in your decision. Understand what kind of software development jobs are more suitable for you to start your career. Machine learning and AI is in very high demand and pays well, but it demands a very strong math and statistics knowledge and significantly more time of study to get the basics than web development for example. Check job boards for quantity and quality of companies hiring for junior roles. Don't stress about the intimidating list of requirements in these posts, they matter much less than you think. Find out how much companies are paying junior developers, but also senior developers. Understand that "senior" is a term for which each company has its own meaning. A good heuristic is to consider that the lower range of salaries companies are paying senior developers is how much you could be earning in 3 years and the upper range is how much you could be earning in 6 years. You end up with a very realistic view of your prospects. Do you see yourself progressing through this career satisfactorily?

Job performance in software development is about knowledge and work ethics. There is a lot to learn about software development. The body of knowledge grows constantly and fast. It may look intimidating like a crowd marching out of a stadium, so you have to keep moving with it. The worst reaction is paralysis. Are you in good terms with the idea that you will have to be learning new things for your job all the time? Forever? This should feel exciting for a software developer, so if you feel lazy just to think about it, software developing may not be for you. It derives from this that your work ethic should reflect the will and diligence to learn. Other than that, you will likely bring with you the same behavior on the other aspects of your work ethics, like commitment, time allocation, teamwork, and transparency. Your self-awareness on this topic will become more relevant when you start looking for jobs, something I am planning to write about in future posts. But it doesn't affect a lot your career decision to become a developer at this point.

If the suitable job opportunities you found look interesting and you see yourself capable of working hard and studying hard for several years to perform well in these jobs, then you have a good fit with the career of software development.

A decision based on joy and career fit

So, how do you know you will enjoy coding? You don't until you try it. My first contact with code happened a couple of years before my decision to go all-in. I was focused in founding a startup and I decided that learning to code would be useful in my endeavor. I didn't have the goal of becoming a developer at the time, I just wanted to know the very basics and be better prepared to communicate with actual developers that would build my product. I spent around 2 months studying part-time C# and .Net and loved every minute. I was building a very simple web app that would act as a medication organizer for people who take 5, 6 or more pills every day. I remember being eager for Monday to arrive. I never felt that so many times in any job. So, when October came, after failing my startup and being frustrated with marketing jobs in general, I knew I would enjoy being a developer.

And how do you know you will perform well in software development jobs? You can't possibly know before your first job, but there are signs. A great sign is if you can actually build something that works. While facing the huge, intimidating mountain of knowledge you don't understand, you still manage to find some of the small, more graspable rocks and actually build something with it. It counts less if you just follow command by command a detailed tutorial that shows each tiny step of the way. It counts more if you go further and ship a working prototype to be available on the web, hosted and deployed. Your code will be terrible, be sure of that. But if you can imagine, learn some tech, build something on top of things you are barely recognizing and it actually works! That's a good sign that you are capable of learning and overcoming obstacles to deliver value through software.

I built a few projects, like a to-do list with a creative UI, a search tool for animated gifs, a Facebook Messenger bot, a note-taking web app for personal development; a page that would show random, old, upvoted Hacker News comments. All of them with terrible code, no polishment to have a chance as a real product, but all of them working and deployed. This gave me a lot of confidence that I could deliver value to a company as a web developer. I could learn things and use this knowledge to build something else.

I knew I would enjoy coding every day, I knew I had a good chance of being a capable developer, I was ok with the prospect of having to study hard in order to keep growing, I didn't have any illusions about the kind of jobs that I would get (no glamorous job at Silicon Valley for me), I knew which jobs I would like to avoid. I discussed all of that with my wife and we decided that I would quit my job and start studying full time to become a web developer. I'm pretty sure it was the best professional decision of my life so far.

Coming next

My next post will be about the 7 months I was full-time studying web development. I will explain my belief that you shouldn't pay for anything until you are capable of deciding for yourself if that course/book/bootcamp is worth its price in knowledge. And discuss some things I didn't know I didn't know while studying by myself. And the next post after that will be about the search for my first job as a software developer.

If you want to be notified when the next posts come out (I don't have a defined schedule for that yet), please leave your email here:

Thank you for your time and I hope my experience and thoughts can help. If you want to contact me, and I would love to hear from you, use my github handler with gmail.

When I decided to become a software developer I quit my job to study full time. I was decided to learn to code enough to get my first job as a developer. My goal was to get a job in 4 months, it turned out to take 7. I studied using solely free, online resources. I believe this was one, among a few right choices that led me to successfully get a job - aside from luck, and I want to share what and how I studied. My intention is to help those who are really starting to learn to code from scratch, possibly coming from other professions and diverse background.

My personal choice and, in my opinion, a very good one for anyone who has never programmed before is to start with web development. Particularly frontend web development. There are a few reasons for that. At a basic level, it has an easier and simpler code than other domains. It offers instant feedback on the code you are writing; you write a few lines and just check how it looks on the screen. There are no hard choices to make at the beginning, you just have to go on and learn HTML, CSS, and Javascript. This quite evident beginning contrasts with the myriad of libraries and frameworks for web development that starts to pop out as you advance your knowledge. But, for starters, it is a fairly straightforward path. Also, even if you decide to move fairly quickly to backend development, this basic experience with frontend will be valuable. So, keep in mind I'm mostly talking web development in this text, even if sometimes it can apply to other domains.

How to study is worth some thought

Don't study too much what you should study, just start this journey with the first step. Although, an informed decision on which path should be your first step might help. The medium from where you learn the content can make easier or harder paths to follow. Before going into details on each medium, let me state that I firmly believe that you should not pay for any learning resource until you can decide for yourself if it is worth your money and time. Meaning that if you are indeed just beginning to learn to code and do not have a clue about what is software development, don't pay anyone to find out for you. This is particularly true if you can read in English, the language of most of the resources available on the internet.

The lure of paying for classes is the belief that they are a shortcut to knowledge. You rationalize that by paying it will be easier to learn because someone will be teaching you, it will be easier to create a habit of studying because there will be some sort of schedule, it will be easier to commit to it and don't quit because you have paid for it. It won't, it won't, it won't. You will learn more by teaching yourself, it is better to create your own study schedule based on your own needs and if your commitment derives solely from the guilty of spending money you will cut corners on your learning whenever you can and just do the minimum to justify the expense for yourself. Now back to how can you learn.

Books are a great source of knowledge. Just not for now. All the relevant books on software development require at least some degree of basic programming knowledge. Most of them will only have a real impact on you if you are already coding in a professional environment. When you begin to know the right questions to ask, some books will have the power to put you into a different level as a developer. While you are still learning the basic syntax of a language, there are more straightforward resources online.

Videos are popular among paid courses, which is surprising to me, as I just don't believe is the right medium to learn software development. In a video, it is common to have several minutes spent on preambles and explaining already familiar concepts and all of a sudden a new, important, complex concept is thrown at you. You missed it because you were annoyed or bored with what was before. You pause and go back. You don't know if the concept is better explored going forward or if you will be lost for the rest of the lesson. You go forward, you still don't quite get it. You are not sure if you should pause and google it to properly learn or trust the pedagogy of the course and just keep going. These situations happened to me all the time when I tried to learn by video. It may be just me and the fact that different people learn things in different ways, but now I ignore video as a learning resource.

Bootcamps are expensive. This alone made it out of the question for me. What it gets right is the full-time commitment to learning. Three months of full-time studying is much more productive than a year on nights and weekends. Learning to code demands a lot of your focus and attention. It is great if you can do it without being tired from a day of work. But if being able to quit your job and focus on studying full-time is a privilege, bootcamps seem like a luxury to me. I never tried one myself, so I can't go deeper into its pros and cons. I have the impression that if you are not doing it for the fallacious lures I mentioned before - a shortcut to knowledge, a crutch for habit creation or a guilty trap to commitment - then it might be a good experience. After you spent some time learning the basics by yourself, for free, of course. The "free-first principle" remains.

Code on the browser is how I call these interactive learning web platforms where you are given a lesson or a challenge on one side of the screen and an in-browser text editor on the other side ready to compile and run your code. This is how freeCodeCamp works. freeCodeCamp was the most important resource in my learning path and one that I wholeheartedly recommend. The method allows you to just start coding with immediate feedback. In minutes of starting, you will already have written code that works. You only need a browser and the bite-sized lessons are perfect for continuous and cumulative learning. It is for free, it has an active forum and you can get in touch with thousands of people going through the same things as you. I have no doubt that freeCodeCamp is the perfect first step for anyone wanting to learn web development from scratch.
It is up to you to decide how long to stick solely to freeCodeCamp. It took me about 2 months to complete the estimated 477 hours for the Front End Certificate. It is a good milestone to make a break and start with other resources.

Learn enough to start building. Start building before you learned enough to finish it.

A good rule of thumb to follow is: build a small, unambitious project with the tech you are learning, as soon as you learn enough to start building. The only way to know how to complete a project is to start your own. And finish it of course. When you try to build things you imagined is when it really starts clicking and all the information you had absorbed before transforms into knowledge. You start with tutorials, you improve with documentation.

Tutorials are great resources if you know how to use them. Usually, you find them on personal blogs or Github, they are made by individuals who are generous enough to share what they know in an organized way. They are a great way to start building something. The more detailed they are, the better. For a beginner is very valuable to read instructions on basic stuff, like what command to use on a terminal to install some library or framework. I like when they are even more basic, like explaining what a terminal is. Or even what is a text editor and mention some common ones for you to install. These fundamental preparations are usually taken for granted by senior developers, but they are very alien to beginners, especially those that are switching careers and do not have a background in Computer Science or spent some time coding fun stuff as teenagers. I remember spending some time googling what a terminal is.

The danger of tutorials is using them as an immutable recipe. They are a starting point to get you to that point where you can change things. As a rule, your final product should never look exactly the same as the tutorial's demo or screenshot. What to change is up to you and your preferences. The layout, the design, the UI, the use case, the name of functions and variables, the data structure, the way you deploy it. You may want to introduce your changes while you are building it - my preferred method - or complete the tutorial step by step, then edit it afterward to match your ideas. Anyway, make it your own project. Or else you will be only exercising on how to follow instructions, not on learning to code.

Finally, official documentation, the source you should always be learning from. The sooner you can get something useful from the official documentation of the tech you are using the better. For me, this tipping point came only after freeCodeCamp and a couple of tutorials. There is good and bad documentation, but it is a necessary skill to be able to read and learn from it no matter what. For HTML, CSS, and Javascript I consider Mozilla Development Network (MDN) Web Docs the best documentation out there. Then, each library or framework has its own. When you are always going back to check its documentation to learn how things work, that's when you know you are on the right path to master that particular technology.

How to ask Google

To be fair, this is more about how to frame your question in the same way someone already asked it at Stack Overflow, which is where you will end up 90% of the time. I only keep using Google because it is better at finding and presenting the results than Stack Overflow own search tool and because of those 10% of the cases when someone happened to write a blog post on the precise issue you are facing.

Before you google it, take some time to more precisely understand where you are stuck and what is that you are missing. Read any error message that you find. Make some changes in the code to try to narrow down where the error is happening. Learn how to use Chrome Dev Tools, the most accessible debugging tool. Inspect the HTML elements, check its CSS properties, read what is being printed at the console. Learn first how to use the console.log() command on your code to understand how your code is running, then evolve to the more sophisticated debugger; command. One important lesson: those hours stuck in a stupid mistake you just couldn't find and ended up to be a typo on an HTML tag or the lack of a ";" at the end of the line aren't "wasted time". It is training in debugging. Yes, this is a real skill, not something I made up to make you feel good about being lost for so much time. A skill you will use throughout all your career. It is a very frustrating training, for sure, but a useful one. Only that you must face it as part of the learning process. Meaning you should consciously try to get better and better at it. New approaches, new tools, new mistakes.

But sometimes, almost all of the time when you are beginning, no amount of lonely debugging will unstuck you. To quickly get to the stage where you know what is wrong, you just don't know the answer is part of the training. And that's the perfect time to google it. Of course, that's the ideal. "Debugging by multiple googling" is a thing when you don't even know what is broken (I think it is a thing at least... I do it). But the goal is to improve in debugging, to become more efficient. My google queries usually start with the tech I am working (css, javascript, react, ember...) and I phrase my doubt as a question. This is how it normally appears on Stack Overflow. It never crossed my mind that it would be any different, but I think is worth mention that googling in not "cheating", as I saw this concern appearing in beginner forums. Searching for answers is basically all you are going to do while learning. Finding someone with the same doubt that got their question answered online by someone with more experience is a great way to do it.

How to ask people

Sometimes, you are not sure what are your doubts. It is very common that you don't know what you don't know. Other times you just need a better explanation of a concept or need answers to some follow-up questions you have. These occasions the best thing to do is to talk personally with someone. An actual conversation with a more experienced developer about concepts and syntax and code. I was only able to do this when I got my first job as a web developer on a company with a particularly friendly and collaborative work environment among the developers. This advice probably does not help if you are learning alone, on your home computer, like I was. But I will talk about it anyway, so you are more prepared when you have access to other developers willing to help you in person.

Your stuck time should be measured in hours. If you are stuck for minutes, you still have homework to do debugging and searching before asking anyone to solve it for you. If you are stuck for days, you are not being productive anymore, not even as debugging training. This is a generalization, of course, but it helps you find the sweet spot between being too early and being too late, asking too much and asking too little. Another good proxy is checking if you have the right feeling when you think about asking someone for help. The right feeling, in this case, is that you feel you genuinely tried to find the answer by yourself and honestly think you won't find it alone. When you ask too early, the wrong feelings are of just being lazy and feeling how it would be much easier to someone else solve your problem for you. When you ask too late, the wrong feelings are of feeling shame about not knowing how to solve a problem without any help. If you don't feel lazy and don't feel ashamed of your ignorance either, you are probably asking for help at the right time. It is very easy to deceive yourself that, actually, it is not laziness or it is not exactly shame, just pragmatism or shyness. So always look for honest feedback from the people you are reaching for help. Also, not everyone has the kindness, patience or time to give you proper answers, so when it goes wrong, consider that before you think it is your fault.

Learn bit by bit and it will pile up

In the path of learning to code, you will be afraid. You will have crises of confidence, self-doubt, and discouragement. You will think that you will never be able to do the most basic jobs that developers do. But if you already made the decision to become a software developer, trust the process. Remember the reasons you made that decision, to begin with. Visualize your goal with it. Every little thing you learn matters. They eventually pile up and become something useful. That's why to keep building stuff while you learn is essential. You make the abstract more concrete. You can show it to yourself, to people that care about you, to strangers on online forums. On a path with no finish line, it is reassuring to look back and see how much you have already advanced.

Coming next

This post is a good description of how I spent the 7 months between starting to study web development full-time and getting my first job as a developer. Around month 4 was when I started to apply for jobs, so this 3-months period is the topic of my next post. Applying for jobs was not as new to me as software development, so I knew how to do a few things right and they worked. But I was also very lucky. I will try to distill the factors that made me lucky and possibly make it into actionable advice that others might apply to better prepare themselves. After that post, I plan to write about some things that I didn't know I didn't know while learning to code. Namely: code readability and maintainability, design patterns, architectural choices. I initially intended to make it part of this post, but I decided they are essentially different topics. It is good to know about these things now, but my ignorance then didn't stop me from having success in my first steps.

I still don't have a defined schedule for my posts, so if you want to be notified when the next posts come out, please leave your email here:

Thank you again for your time and I hope this was helpful to you. If you want to contact me, and I would love to hear from you, use my github handler with gmail.

After 4 months studying web development full-time I decided I knew enough of the basics to start looking for a job as a junior web developer. It took me 3 months of job hunting to get hired. During this period I applied to 10 positions and my time was grossly divided like this: 60% of the time still studying, 20% looking for good jobs, 20% applying to them. I know that only 10 applications sound too few for such period, but I believe that fewer applications actually improve your odds of being hired in a given time period. There is a lot of luck involved in getting a job, but regarding what is not luck, I want to share what I did when looking for jobs, applying for jobs and interviewing.

Learn how to be a good developer, not a good candidate. That said...

When I stated at a public forum (Hacker News) that I had just started to study software development and my goal was to get hired in 4 months, one fairly upvoted comment was that it was "not possible unless I fake my way in". Obviously, I ignored the "not possible" part as it was just a dismissive blank statement, but I was surprised for a moment that someone could fake their way in a job as a developer. I thought one couldn't fake how to code but then realized that, like any profession, people could abuse interviewing skills and lack of ethics to get hired and stay in jobs they can not perform. To go this way is obviously a poor, unfulfilling, short-sighted choice. This is just to say that I will focus on skills that are applying mostly to the hiring processes of tech companies, sometimes orthogonal to coding skills. But remember that you still should spend most of your time studying and practicing the craft of software development, not interviewing skills. That said, to build your career, you have to land the first job.

One of the choices that might increase your chances to get lucky and land a job is the tech you study. Study what is hot, but not what is hype. When you are a hired professional you should choose the best tech for the job at hand, no matter what is hot or hype. But when you are starting, you choose the tech that is asked at the most job positions, simple as that. In the frontend world, for example, there is no doubt that a beginner trying to be hired should choose React. Just take a look at the latest Who is hiring thread at Hacker News, for example. A text search for React and you get 46 results. VueJS is a new framework, a lot of praise from developers and it looks the most hyped tech right now. But it is "only" mentioned 10 times in the thread. Ember is a very mature and solid framework, ready for production in professional environments. But it has 7 mentions. Angular has 16, a little better, but still no match for React right now. So at least one project using React in your portfolio is a great asset at a beginner's resume. Just don't forget that a good foundation in Javascript precedes any dive into the world of frontend frameworks.

Another part of the preparation before you even start applying is your portfolio. Every junior developer should have a few public projects to showcase their skills. The projects don't have to be awesome and the code can be a mess, as long as they improve from one project to another. Your more recent projects should be better built and more evidenced in your resume. But don't delete your early projects, no matter how bad the code and the end result are. Those senior developers evaluating you want to find candidates that can learn and improve. They know everyone's first projects are terrible.

What to look for when you are looking for a job

Companies that are serious about hiring. There are a lot of job ads out there that no one that cares is actually reading the applications. Look for good signs that a job ad is for real. The description of the company and of the job should be well written, with relevant technical information that you can tell was detailed by a developer. It is preferable when the method of contact an individual email, not a standard form. This excludes most of the huge companies, that get thousands of applications for any job position. That's why networking is a much more effective path to get hired at huge companies.

One thing that is a blessing for junior developers is when the hiring process starts with a code challenge. That means that the company actually cares about the hiring process, that some software developer will be part of the decision to hire from the beginning and that almost for sure you will get a response, Some few times even a feedback on your code. More senior developers usually don't like code challenges because they are time-consuming, not enough to evaluate in depth high skills and they have more real work to show. But for junior developers just beginning it is an opportunity to learn while doing, get valuable feedback and stand out for your hard work, as these jobs filter out lazy applicants. You will have less competition in any job that asks candidates to build something as a first step. This was actually my main criteria when searching for open positions, find the ones with a code challenge.

Find a job/company that suits you, so you don't have to pretend you are a good fit. This is not only about the "culture" of a company, I am of the opinion that you can adapt to almost any corporate culture if you have a nice boss and nice colleagues. But it is mostly about the job description. There are a lot of shitty jobs in web development. A typical example is some advertising agencies where the only task of a frontend developer is to transform graphic design templates into HTML and CSS. You will work alone, almost no Javascript, usually no senior developer to mentor or teach you and you will be treated as a disposable asset with no saying in anything that matters to the business. Sure, there are desperate times when one should accept worse conditions, but if you can, run away. Good jobs might also be filtered out for lack of a good fit. If you are planning to be a frontend developer more dedicated to the UX and design area of the field, don't apply for jobs looking for a full-stack more inclined to the back-end side of things.

Care about each application as it was the last one

The main perk of spending more time looking for and filtering the right job positions is that you can now spend more time on each application. Because there are just a few of them. Never do just the bare minimum to apply. You will end up being discarded by companies that really evaluate an application and be selected by the ones that don't care much about who is applying, they just need to fill a vacancy (which usually means it is a shitty job). Again, companies that ask for code challenges are expecting hard work. It is the reason they ask for it in the first place. A half-baked application will only waste your time and the chance at a good job. Back to my main mantra of only applying to a few selected jobs: only apply for those that you are motivated enough to put the effort.

Interview preparation and attitude

Interviewers of junior positions are always looking for three things: basic coding skills, ability to learn things and ability to communicate professionally. The coding skills assessment is usually based on the code challenge or your portfolio. Be prepared to answer questions about those. Review the code of your projects and, more important, the decisions you made when building it. Why use some tech, the doubts you had while building it. Interviewers will use these questions to check if you indeed build the things you say you built, but also to see if you care about the craft of software development. It matters more than you think to leave a good impression that you care about your code.

Your ability to learn things will be assessed through your curiosity, your desire and diligence to improve, your awareness that a software developer will be learning forever. It is important that you let your curiosity and eagerness to learn new things show in the interview. Another measure that interviewers will use is what have you studied and built so far against the time you took to do it. This is a reminder that slacking and procrastination while learning to code is a cardinal sin. Try the most to be really intensive in the hours you designated to study software development. Learn things, build things, create a body of work that you can show and impress people on how fast you get to that level. Even if it is still a basic level.

Professional communication is all about confidence and practice. Some people can fake confidence and some people are more natural as communicators. But you probably aren't one those people. Your confidence should ideally come from your acquired knowledge. That's why it is important to study for your job interview. Study your code, study the job description, study the company product, study the company culture. For each interview, spend one or two hours reviewing all of that. For each one. Don't be lazy. And practice. Practice with someone or in front of the mirror how to answer some common topics. Like explaining your last project and your code decisions. Or the classic "Why are you a good fit for this position?". It is common to become too self-aware and awkward during these practices, but they help. A lot. Don't avoid doing it because you feel stupid. You looked stupid too while learning to ride a bicycle. Deal with it. But don't practice only for the interview. Practice explaining tech concepts to non-tech people and product concepts to tech people. It takes some effort to properly communicate, if you realize it and care about it, you will inevitably get better.

Learn what the company's software development team values. Stalking mode. Find the developers and the CTO on LinkedIn, Twitter, their blogs. Read what they write about, what they care about regarding tech, the advice they give about software. You will probably come across a few common concepts they follow. Like Test Driven Development. Read about these concepts, but don't memorize the dogmas, understand the reasons why some people consider it a dogma. Create your own critical opinion about it. Don't be arrogant believing you have it all figured out, but don't be a sheep repeating what you read online. The idea is not necessarily to show the interviewer that you have the same opinion. But to show you know about that concept and have considerate thoughts about it.

Learn what you are good at. Learn what you are bad at. Mention both of them in the interview. I was very self-aware of my strengths: communication, work/study ethic, background in marketing (relevant as I was applying to be a web developer, mostly at startups) and my weaknesses: total lack of CS background (meaning I lack fundamental concepts in my education, like the architecture and design patterns basics), no experience as a developer in a professional environment (never worked on a code project within a team, no code reviews), very very basic Git knowledge. I was able to show how much value I could deliver to the company through my strengths and how self-aware and eager I was to learn and fix my weaknesses.

What not to care about, what to run away from

Hiring is broken, but it is not up to you to fix it. Most of the time you won't know why you got rejected. Most of the time the people that rejected you won't know either, even if they think they do. All hiring process in the world is a mess full of random decisions and all kind of bias. There are a lot of legitimate reasons why you never get an honest, straightforward feedback from companies too. Someday you might be in the position to try to fix this in your company. But not now, not as a candidate. Accept that you will never know why you got rejected or rationalize some reason that doesn't make you too emotional. And move on to the next application. Be pragmatic.

People will undervalue you. Chances are not all interviewers will be nice. On a promising application for a cool job, I got a call from the founder. He said something in the lines of "You know, you have to understand that you are competing with a lot of young guys who are coding since they are twelve. You have a lot of catch up to do. You have to expect an intern salary and even so work harder to show you can become a good developer. Because I'm not sure you can." Maybe he was just using some shitty negotiation technique to hire me on a low salary, maybe it was ageism, maybe he thought I was delusional on my aspirations and decided to give me a lecture to be more down to earth. Whether he was stingy, mean or patronizing, it was definitely a place that I wanted distance. Learn how to identify places where people are not nice. Maybe it is just me and I shouldn't be advising people to follow such a subjective criteria. But I use "niceness" as the first and most important criteria to choose which people I want to be around and it has served me well all my life.

Coming next

This is a distilled advice from my experience getting my first job as a developer. I was very lucky to be hired by a great company with a great environment for a junior developer. And that's when my real education in software development begun. There is a lot you don't know about software when you are learning "just" to code. Most of it you learn by something called Code Review. Other developers take a look at the code that you want to add to a project, analyze it and criticize it about things you had never considered when you were just building amateur projects for your junior developer's portfolio. A new world of knowledge that I had to gain opened to me through the gates of Code Reviews. The next post will the completely dedicated to this process of professional software development.

I have no defined schedule for my posts, so if you want to be notified when the next posts come out, please leave your email here:

Thank you for your time and I hope this was helpful to you. If you want to contact me, use my github handler at gmail.