Featured

“Letters To a New Developer”, the book

Dear new developer,

I hope you enjoyed reading these letters. I’ve certain enjoyed writing them. When I chat with new developers, at meetups, on slack, or via email, they let me know when letters are helpful or unclear. They suggest topics. They give me feedback, which, when you’re writing into the howling abyss of the internet, is very helpful both for calibrating your message and improving your motivation.

I’ve also posted these letters to some online communities. I’ve received plenty of feedback from those folks as well. Some kind, some caustic. That’s not unexpected.

After writing a hundred or so posts, I thought, there’s a book here.

And so I wrote one.

You can buy it from any of the usual suspects:

You can also check out a preview of the chapters on the publisher’s website. I’d love if you’d do so.

Here’s who I wrote it for:

For new developers
You are new to the software development job market. Perhaps you have completed a bootcamp or college degree. You may refer to yourself as an entry level or junior engineer.

While everyone’s background and skills growth happens at different speeds, new developers generally have less than five years of professional experience. Many new developers are worried about their abilities, don’t feel welcome, and have a difficult time finding that first job.

But as an industry, we need more new developers. There are so many problems with which software can help. Companies want experienced engineers, but all the senior developers I know started out as new developers. A senior engineer is just a new engineer seasoned with gaffes, education, and time.

For new developers, this book will help you avoid missteps I’ve made. It also introduces you to disciplines beyond coding critical to success. While programming is crucial for any software product or service, there is much more required to deliver an application.

For anyone considering software development
If you’re not sure if software engineering is right for you, this book offers perspectives on how to succeed.

I’ve intentionally kept the barriers to the layperson low with limited technical jargon. Only a few technologies are discussed, and those sections can be skipped. If you are thinking about becoming a developer, I’d recommend buying this book and a book about programming.

Giving a computer commands that it can execute is an important skill for any software developer. But software engineering is so much more. You must know what to build, how to work with your team, and how to maintain your systems.

For mentors
If you are mentoring a new developer, this book can serve as a discussion guide. Because each chapter has letters approaching a theme from different angles, you and your mentee will find it useful for focused mentoring sessions.

As an experienced developer, you’ll of course bring your own insights and experience to each topic, from your debugging process to the value of an online community for continuous learning.

And, of course, you may have had a different experience than what I share. Such contrasts are a jumping-off point to discuss the diversity available in a software development career.

Introduction, “Letters To a New Developer”

Sincerely,

Dan

PS If you shoot me an email, I’ll give you a discount code.

You’re gonna be OK

This is a guest post from Jerome Hardaway. Enjoy.

Dear new developer,

So, you’re in the office, learning a million things a minute that you were never exposed to. Everyone around you seems super competent and you don’t want to take time away from them, but you have no idea what you’re doing. You feel like you should probably be a janitor instead of working on a million dollar web app. I’m here to tell you, you’re wrong.

Every person who seems competent has felt like you or still feels like you do, they are just better at hiding it. I know people who have been doing this work for years and feel silly at least once a week. Hitting your head against the tech wall is a rite of passage here and normal and whether they tell you or not, we have all been there. We have all either accidentally taken down prod, nuked the repo, felt lost, accidentally ran up the AWS bill, and just straight up sucked at this job. So long as you focus on having more good days than bad, you will be fine. More than that, you’ll do great, so relax cause we are all rooting for you.

— Jerome

Jerome Hardaway is a Developer Advocate at Quicken Loans and Executive Director at Vets Who Code, Where they help veterans get jobs in software by teaching them how to program for free.

You’re probably going to want to quit

This is a guest post from Mia de Búrca. Enjoy.

Dear new developer,

You’re probably going to want to quit.

The very qualities that make writing software appealing can also make it frustrating beyond belief. You’re headed down this path because you like to be challenged, to learn and grow. However, facing new harder problems day in, day out can take its toll on your morale. And keeping up to date, familiarising yourself with the breadth and depth of topics in this domain – it can be overwhelming. But if you’re reading this it’s likely you’ve already felt the deep satisfaction of writing code to be proud of, so I hope that by sharing my experiences, from early in my career and from a few weeks ago, you will be motivated to push through and keep enjoying the journey.

The Import

One of the first times I nearly quit was a few weeks into my first role as a dev. I was fortunate enough to land a great job at a small startup, and I was pretty awe struck by the talented and motivated people on my team. So after a while of pairing, I picked up a piece of work to try on my own. After doing some copy-pasta from other files and then tweaking I was chuffed and attempted to view the web page that would now be perfect, right?

Much to my dismay I was met with a blank page and an obscure error message. Baffled, bit by bit I undid all my changes, at each step feeling less worthy of the job, until nothing was left except one measly import statement. I could feel myself go red in the face as I still couldn’t understand what was going on. I should be able to do this, but I’m not good enough. Eventually, I turned to my mentor to admit defeat, and my panic dissolved when he said “oh yeah, this one is definitely confusing” then casually pointed out a simple syntax error. I realised that unlike him, I was not yet equipped with the necessary debugging skills, I was not yet familiar enough with the language I was working in to decode the error message. It takes time.

The Library

It has been four years since the import statement that stumped me, but just a few weeks ago, when I volunteered to update a library which was many versions behind, this seemingly trivial task wound up with me ready to quit yet again. Between a broken development environment, failing tests (was it the tests… or the code?), and still this library integration that refused to obey, I was at a loss. I should be able to do this, I should be good enough by now surely? These thoughts drove me to stubbornly dig my heels in and devote hours to diving into the library source code, reading in circles, dipping in and out of StackOverflow, getting more and more frustrated. Much time wasted I was no better off, so I went and made myself a cup of tea and called up a colleague and good friend to lament my problem. Typically, within seconds of this accidental rubber ducking session the solution to my worries became apparent.

The Lessons

And I could probably list countless other occasions. There may be many different things that leave you feeling like quitting, for me it often boils down to not feeling good enough to tackle a problem. But when you come up against a roadblock, you shouldn’t see it as a reflection on your own ability. If like me you find yourself paralysed by feelings of inadequacy, recognise that the foundation of all programming is problem solving – if there were no annoying problems, you wouldn’t have a job – and as you progress through your career you will gain more tools to solve them. Step back and remember, when it comes to tech, there is a reason to be found – sometimes it takes time, distance, or some help to see it.

These are lessons you should try to internalise, or like me you’ll relearn them throughout your career. You can’t change the fact that deeply frustrating problems are coming your way. You can only change your perspective. Put your energy into solving the problem and don’t assume that you’re not good enough. “Good enough” is an arbitrary concept, an ever moving goalpost. Give up on the notion of “good enough” and instead give yourself some time.

Sincerely,

Mia

Mia de Búrca is a Senior Software Engineer working full stack at 99designs, a company connecting creatives around the world. Originally from Ireland, Mia started out as a translator and computational linguist before landing in Melbourne, Australia and setting her eyes on a career in web development. Mia enjoys solving problems with a focus on bringing real value to users and seeks opportunities to create a supportive and empowering workplace. When not hiding from apocalyptic pandemics, Mia is also a circus performer and teacher.

Sometimes you just have to ship it

Dear new developer,

For me, there comes a point at the end of every project where I’m just sick of it. I’m sick of the project. I’m sick of the technology. I’m sick of project management system. I’m sick of the code.

Sometimes, I just want to see the whole thing burn. Or better, just ship it.

Now, I think that there are two solutions to this problem, and which one you pick depends on your timeline. The first is to take a step back. Talk to a team mate. Work on something else. Talk a walk. Take an extra half hour for lunch.

This may give you perspective to help you dive back in and add just a bit more polish. That polish, which may take the form of additional UX refinement, testing, or even wordsmithing the help messages or marketing text, can help make the project shine.

That’s what I call ‘running through the finish line’ where you want to leave it all on the field. That doesn’t mean you don’t make compromises or that you won’t revisit decisions, but it does mean that you do the best you can. Sometimes to put in that final effort, you need to take a break.

The other choice is to just ship it. This is a good option when you are up against a deadline. It also helps if you know you are a perfectionist and/or afraid of putting your work out there. Nothing is perfect and if your work never sees the light of day because you can’t accept that, the world is losing out (as are you). Finally, it can help if you take that time off, acquire that perspective and know that you’re done with this phase of the work.

I just published a book. It was released on Aug 16. I’m very proud of it, but there were times when I was just plain sick of it. I ended up taking some time away from it and that helped me make sure it was the best book it could be.

When you are working through the final bits of a project, sit back and get that perspective. And then, ship it!

Sincerely,

Dan

Make it work

This is a guest post from Tim Bourguignon. Enjoy.

Dear new developer,

Let me tell you a story.

Once upon a time, there was a black chalk board in a dark room. The board carried remainders of countless creations. Diagrams that could pass as hieroglyphs for the non-educated eye. Or well crafted UML to the others. From systems to modules, modules to components and component to classes, it all seemed to flow. Generic, inter-operable and reusable, it was beautiful. Those architectural blueprints led the creation of the software. Countless tests secured it, using the best means at hand. Production servers welcomed the bits. But a few week later, the company shut down. There was no market for this software. There was not enough cash left for the company to pivot and explore a different idea. Too much time was lost writing the most beautiful and never used piece of code in the world. Beautiful or well crafted code that doesn’t solve a real problem doesn’t count.

Once upon another time, a software crashed in production. A website was down. A shopping system was not taking orders. A customer was losing a fair amount of money for every hour, every minute and every second that passed. And boy was she furious. A few caffeine-doped hacking hours solved the problem. Thankfulness replaced the customer’s furor. The architecture of the solution lacked flexibility. The re-use potential was at an ever lowest. A bitter smell of copy-paste still held in the air. And the amount of technical debt in the codebase reached new heights. But the fix saved the business. Sometimes, ugly or imperfect code that “do the job” is the best you can hope for.

Here’s how David Heinemeier Hanson and Jason Fried described the launch of Basecamp:

When we launched Basecamp, we didn’t even have the ability to bill customers! Because the product billed in monthly cycles, we knew we had a thirty-day gap to figure it out. So we used the time before launch to solve more urgent problems that actually mattered on day one. Day 30 could wait.

Rework by DHH & Jason Fried

Let me rephrase this: they launched a paid-product with no way to earn money! Does this sound sane to you? It actually is. Worst case scenario, nobody is willing to pay anyway. They don’t have users, they don’t need a payment system. Period. They concentrated their effort on making a great product until the launch date. If the product attracted customers, they would need a payment system. The month that ensued might have been smooth… or very bumpy. Again at the end of that following month, some code had to be running. Good or bad, perfect or crappy looking, it had to do the job. Otherwise they would lose money.

Let’s generalize by putting code aside for a moment. Have you ever written a text to throw it out seconds later realizing how crappy it was? I know I do it countless times every single day. Have you ever had a great idea put you into ecstasy, only to throw it away the moment you put it on paper. Have you ever realized how dumb an idea you had, after hearing you verbalize it? I know I do every single day. Plans are perfect, until they meet reality.

For everything you do, there is a right time. Sometimes it is “yesterday”, sometimes it is “now”. But more often than not, it is “later” or even “never”. The best way to find it out is to strive to make “it” work. Whatever you do, try to make your plans meet reality as fast as possible. Only then can you be sure you are not working on false promises.

Don’t underestimate this first rule. We often forget about it at the first pinch of peer pressure. If you write software as part of a team, you have experienced a variation of the following in the past:

My coworkers will review my code. What will they think of me? I’d better refactor this component, make non-trivial changes to this module, enable future extensions in this class and clean my code up to its core to uphold the design standards…

What I could have done in a few minutes has grown into hours and the peer pressure increases. What has taken a long time to craft must be excellent, or was it the contrary?

Can you live up to this first rule? Our formal education taught us to seek the unattainable best grade and to hunt for any flaws. To the contrary, this rule tells us to seek the “good-enough” and then iterate on it. Use those intermediate versions to foster discussion. Lay a “good-enough” version of your work on the table, be open about its flaws and be sharp in criticizing it yourself. As a group, you can then decide whether to invest in making it suck less, or leave it be. As J.B. Rainsberger said in his talk “7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development”:

If every item in our shop either costs $8 or $13 and we hard-coded those values, we are done!

Of course, not every draft that does the job is production ready. Production is often far away down the road. You will have to work hard to find out what “good-enough” means for every new challenge you face. But by seeking working solutions in your daily life, you will make true progress. Refine working software. Keep both feet on the ground and focus on tiny measured steps. This is the basis for producing a good solution. The solution that is there when the deadline falls. The solution that makes the business work.

— Tim

This post was originally published at Auswanderer Quatsch ².

Tim has been building synapses between human beings since 1983. Passionate developer, Mentoring advocate, mentor and mentee himself, he works as Chief Learning Officer, Head of Agile and technical Agile Coach for the MATHEMA company in Germany. In his free time, he hosts the Software Developer’s Journey podcast and spends as much time as he can with his wife, with [1;3] kids clutched on his back!

When do you feel like you’re “senior”

Dear new developer,

I thought this was a great tweet. It’s worth clicking through and reading the responses. I wrote my own tweet in response, but thought I’d write about it a bit more here.

First, it’s worth acknowledging that the term “senior developer” means different things in different places and times. Certainly the knowledge expected of a senior developer in 2020 is different than in 2010. And likewise, a senior developer at a small consulting company will probably be ineffective at Google and vice versa. I’ve written more about the various types of senior developers here.

It is also worth pointing out that a senior developer isn’t the same as being a good coder. A senior developer has that skill plus many others. So, how do you know you are a good coder? In my mind, there are three attributes:

  • You know your tools
  • You can figure out what the right code to write is
  • You can make the right set of tradeoffs

Let’s examine each of these in turn.

First, it’s important to know your tools. These could be low level tools like the syntax of your language or your text editor. They could be higher level tools, like an open source framework or a custom library. They could be computer science focused tools like a parser.

But you need to know these tools and what are the right ones to apply to solve the problem at hand. Otherwise you’ll either be re-inventing something that has already been done or trying to apply the wrong tool to a problem (much like using a saw to hammer a nail; can be done, isn’t pretty).

Next, you need to figure out what the right code to write is. Even if it is no code. This means that you don’t expect to be handed a full set of requirements from some all knowing figure. It means you dig in and understand the domain. That you apply your knowledge and skills to the problem. And that you use the above tools to solve the problem within the constraints that you are operating.

For that is the final piece. Every bit of code has its own context in which it was written. The code that you write to load a CSV file one time can be undocumented and slow. The code that you write that will be executed multiple times by every application user should be polished, tested and fast. As a senior developer, I think you know that “good code” is context dependent.

You understand that context and make appropriate choices to get the job done.

Sincerely,

Dan

Choose inspiration over imitation

This is a guest post from James Turnbull. Enjoy.

Dear new developer,

Steve Jobs made the phrase “Good artists copy, great artists steal” famous in the tech industry. However, there’s considerable debate about the origin of the expression. Ironically, he was possibly cribbing from Picasso, who might have been cribbing from Igor Stravinsky, William Faulkner, or perhaps T.S. Eliot. Of all the many variants, I prefer Faulkner’s “Immature artists copy, great artists steal.”

What does this phrase have to do with writing code? More than you’d imagine. As engineers, we’re often stuck on something, banging our heads against a wall over a block of code, or a problem we can’t solve. Some people go for a walk to overcome these blocks, and others take a shower or switch contexts. But many of us go searching the Internet for answers. We try Google, Stack Overflow, or Github for error messages, snippets of code, or implementations that might overcome our problem. When we find something that helps we take this code, often morph it a little, and then use it in our codebase:

Commit message

Or in a code comment:

# From https://stackoverflow.com/questions/62048888/how-to-select-a-floating-point-or-integer-using-a-regular-expression-from-text
text.lines.find { |l| l[' Running Total '] }[/[\d.]+/]
. . .

But there is a lot of disdain, even hate, for this approach from other engineers. This hate is often combined with gatekeeper overtones or remarks about how this wasn’t how things were done when they were learning. I’ve heard it described as “copy-pasta coding” or “cargo coding,” or sometimes even described as outright plagiarism. So is it plagiarism?

To me, there’s a clear distinction between imitation and inspiration. When you go looking for that code, you’re looking for inspiration to solve the problem you have. It is rare to find the exact code you need that you can without modification, nor do you often find code can be used by simply copying it in place. By the very nature of trying to understand how someone else solved the problem, you’re learning, inspired by their creation. Later, as someone finds your code when they seek to solve the same or a similar problem, they can see your implementation and the original, and potentially receive further inspiration and insight.

There are best practices, though, that you should abide by when you use this approach. Firstly, credit the source of your inspiration, acknowledge the work of the original author, and help the next person who is following the same path to a solution. Indeed, if you feel uncomfortable about acknowledging the source of the code that inspired you, perhaps that’s a signal that you’re not doing right by the original creator?

Secondly, use the code as a learning tool; experiment and apply your knowledge and perspective to it. I recently found a Ruby method to work with a nested hash. I liked the solution but realized there was a way to make it more functional and easier to understand. So I took the code, modified it, and made it my own. In has been my experience that the best code results from code shared, whether developed with others or even code reviewed to get other’s perspectives. This process is how we learn to be better coders by learning the lessons of those who came before us and building upon them.

So ignore those folks who hate on this approach. I am sure they protest too much because I can guarantee they have done this in the past, and their disdain draws from the rose-colored glasses that inhibit memories of how they learned. Great artists don’t spawn from nothing, and “Great artists steal” is about finding inspiration; finding the key or the “eureka” moment someone else’s implementation sparks and using it as a starting point to creatively solve your problems.

– James

P.S. This post draws some ideas from Adam Kurtz’s excellent Things Are What You Make of Them and from numerous articles and interviews from the team at The Creative Independent. I strongly recommend both if you’re interested in understanding artistic creation and how great artists create.

James Turnbull is an engineering leader, author, and open source developer. James was the VP of Engineering at Glitch, a CTO-in-residence at Microsoft, CTO/Founder at Empatico, and CTO at Kickstarter. He was previously in leadership roles at Docker, Venmo, and Puppet. James was chair of O’Reilly’s Velocity conference, speaks regularly at conferences, advises a number of startups, and teaches engineering and technology skills. You can find him on Twitter.

Seek feedback loops

Dear new developer,

Feedback loops are so important. (If you’re not sure what that is, I’d recommend “Thinking in Systems”.)

These loops help systems improve. If you don’t have feedback, you’ll improve more slowly, in my experience. Why? Because you won’t know what you are doing that is good and what is garbage. It’s really hard to evaluate that kind of stuff yourself. You can do it, it just takes time and perspective.

And of course, you want to do more of what is good. Here are some kinds of feedback loops which have helped me.

  • tests
  • one to ones
  • public writing
  • being a contractor

Automated tests are a really tight feedback loop. You can make changes to code and know if you’ve blown things up. (Type systems are another tight feedback loop preferred by some.) This is helpful in many situations, including when you are debugging a problem.

One to ones are a great way to gather feedback from your manager on problems, challenges and situations that you have faced. By doing it in a one to one (rather than a one off meeting), you’ll build context and history around these. After all, the tenth time you bring up the fact you find front-end development challenging indicates that this is a pattern, and you should evolve yourself or the position to help with the challenge. When you have your meeting, make sure you ask for feedback explicitly. When you get it, avoid being defensive. If you make it hard to get feedback, you’ll get less.

Public writing, especially a blog, is a great way to get feedback. You’ll be able to put your thoughts out in public. This can be scary and frustrating; some communities are more gentle about feedback than others. But the act of writing forces you to make the implicit explicit. And sharing that knowledge is a great way to get feedback. (Even a lack of response is feedback; what you were writing didn’t resonated with the audience you shared it with.)

I think everyone should try being a contractor. First it makes you appreciative of everyone else in a business, because when you are contracting, you often have to take on roles outside of development (sales, accounting, marketing). But for the purposes of this post, contracting is a great way to get feedback from the market. You’ll learn about which skills are in demand and what organizations will pay for those skills. Of course, you can find this out as an employee, but if you are a contractor, especially a short term one, you’ll be interacting with possible hiring managers much more often than as an employee. And the feedback loop is brutal and blunt: do they hire you or not.

Feedback loops are a key way to find out whether what you are doing is working or not. Seek them out.

Sincerely,

Dan

Write good commit messages

Dear new developer,

Take the time to write good commit messages. Such messages communicate intent across time, and live very close to the code. Here’s an example of a bad commit message:

Updated the code.

There’s no intent here. Yes, of course, you did update the code. Why? Inquiring minds want to know.

updated the acceptForm method to accept a URL escaped code

This is slightly better, but is still no good. This is a bad commit message because it focuses on the how but not the why. Why did the acceptForm method need to be modified?

In general, great commit messages focus on the intent of the change, not the mechanics. Why was this change needed? What drove it? What would you want to know about this reasoning or decision a year from now? What would you want a new team member approaching this code base to know? These are good questions to guide you as you consider your commit message.

Document the reason for the change because those reasons can get lost. They may be captured in a doc, yes, but git log is far more accessible than a doc. In some teams and situations, you won’t even have a document to capture the purpose of the change; it might have been just a hallway discussion, a ticket filed by a customer, or a change made by a single developer without consultation. Code reviews and pull requests can help capture intent as well, but again, they may or may not be easy to find; they certainly won’t be as easy as git blame.

Here’s a good commit message:

Updated the acceptForm method to except a URL escaped code.

Client ABC was sending a URL escaped code instead of what we expected. This means that the system was throwing a null pointer exception. Investigated changing client ABC, but that would involve releasing another version of the client library, which we are deprecating.

More details in this thread: http://slack.com/aaa/bbb

[#123]

Feel free to write as much as you need to communicate intent. It’s also good to have a summation in the first line, then two newlines and then as much explanatory text as you want. I like to do this on the command line so that it’s easy to edit.

If the mechanics are particularly tricky or misleading, that’s one time you may want to focus on the how. For example, if a piece of code is purposefully using a particular deprecated data structure for compatability reasons, outline that in the commit message.

An additional benefit is that this forces you to think about what you were trying to accomplish with this change. If you make more than one change at a time, you can use git add -p to commit only a section of a file.

If you make a mistake and you are using git and haven’t pushed to a remote, you can use the --amend command to make a change to the most recent commit message. You can also use the git rebase command to rework your entire commit structure, including getting rid of “there was a typo” commit messages. Here’s a video about a rebase workflow:

Presentation on git rebase

Now, I’m definitely not perfect about this. I sometimes make errors in my messages. In that case, just as when I make any other mistake, I find out what I did wrong and try to do better next time. You can also use tooling to avoid errors. I have heard of people use tools like Gitcop to enforce rules, but haven’t used it myself.

You can also add a git hook, as a team require all feature branches to reference an issue number, and parse the branch to put the issue number on every commit. Or you can modify that git hook to append the branch name, as outlined here. I’ve done this on different teams and it’s low effort and effective. This isn’t perfect because you can still have a commit with a one word message, but at the least you have some link between a code change and the impetus for it.

Whatever you do, find out what the team norms are around this. Have your commits meet at least that level of detail. This norm may be delivered when you start, or via code reviews, but you can ask as well: “what are some great commit messages that I should model mine after?”

Remember, the purpose of a commit message is to communicate intent. Strive to do that and you’ll thank yourself later when you’re trying to figure out what is going on.

Sincerely,

Dan

How I Got a Job Two Weeks After My Coding Bootcamp

This is a guest post from Randall Kenna. Enjoy.

Dear new developer,

Two weeks after I graduated my coding bootcamp, I had an offer. Two weeks after that, I started my first engineering job at a small startup.

Here are some of the strategies I used.

Treat your job search like it’s your job.

I was exhausted after I graduated from my bootcamp. But I had spent more than$15,000 on tuition and living in San Francisco so I knew I needed to get a job quickly to prove the financial investment was worth it. It was so tempting to just spend those two weeks napping on my couch and recovering from the most grueling process of my life but using the momentum I had from graduating the bootcamp was critical. I had read about a lot of students that had let their skills get rusty and it had taken 6–12 months for them to find a job.

From the hours of 9AM to 6PM, I was job hunting. I was obsessively updating my resume, finding new jobs, reaching out to connections, finding meetups to attend, and honing my skills. After 6PM, I wouldn’t respond to recruiter emails or do any prep work for interviews. I used that time to recuperate and prepare for the next day.

Optimizing my LinkedIn

The company that I ultimately ended up taking an offer at actually found me through my LinkedIn. For all the applications that I sent and meetups that I attended, they ended up finding me and asking me to come in for an interview.

I filled out my LinkedIn with my prior jobs to show that even though I didn’t have a ton of engineering experience, I had a past career where I had been paid to code a little in some of my past jobs. I added every course I had taken and every certification that I had gotten during the bootcamp to show that I was very interested in engineering and it wasn’t just a job to me.

Quickly moving on from companies that weren’t a fit

A few companies had interview processes that were equivalent to Google. They wanted a coding bootcamp graduate to be able to solve complex algorithms that even a software engineer with a CS degree and years of experience would have struggled to complete.

I would have spent so much time preparing for just one interview at one company when instead I could use that time to go through the interview process at several companies. I told the company that the process was far too intense for a junior engineer and moved on.

You don’t have to use this strategy however if you’re willing to put in a lot of time learning algorithms and focusing on building some CS foundations. Some people in my cohort focused on their algorithm skills and it took a little longer to find a job, but they started out with a better title and higher pay.

Build a coding portfolio

Thankfully, my coding bootcamp had helped me create a large portfolio with several applications. I was able to take this to prospective companies and discuss what I had learned during the project. In my final project, I had focused mostly on frontend so I took that work to companies and detailed exactly what I had worked on.

If you don’t have a portfolio yet, just get started on something small and push it up to GitHub. Each time you create a new project, challenge yourself to make it a little more complex than the last project.

Proving I was eager (and desperate) to learn

Two companies told me I could build a project in the framework that I was most comfortable in. But I knew that if I spent a little time learning the framework that they used, I would improve my odds of standing out.

Over the weekend, I taught myself the framework one company used and built a small (and very barely working) app that used it. I was able to discuss the principles of the framework and even though my app broke during the demo, I got the job.

This was a risky strategy because I ended up not spending any time learning the other framework for the other company but it worked out in the end when I received an offer from the company.

Focusing on my strengths and not my weaknesses

I knew that I wasn’t going to do super well at companies that focused on algorithms and prioritized having a CS background, so I intentionally found companies that wanted to focus on mentorship and had real world interviews.

In the interviews, I discussed how I had prior career experience that would benefit them if they hired me and I had been coding at those jobs as much as I could.

It definitely wasn’t easy but anyone can get a job in coding if you treat your job search as if it’s your job and keep improving your skills.

Sincerely,

Randall

This post was originally published at RandallKanna.com.

Randall Kanna is a Senior Software Engineer at BaseHQ, speaker and O’Reilly author. She’s formerly worked at companies such as Eventbrite, and Pandora.