Advice to New Developers (or, How to Get Hired)

I get asked a lot by new developers: “how do I find a coding job?” What should I do/learn to get a really good job? Here’s my advice.

I’ve been in this industry a long time. My first Linux kernel was before it was 1.0. I’ve been a coder and a manager, and director, and VP. I currently head all software at BrightSign and I’m hiring. Recently I was in London for the Silicon MilkRoundabout recruting event, and I attended the Friday session just for early-in-career folks.

In addition, the son of dear friends had exactly the same question as all those folks. “How do I get hired in software?” . Here’s my advice.

What Can I Actually Do?

Don’t Be Afraid

The job hunt will feel like a vast wilderness filled with scary beasts.

Don’t be afraid. Hiring managers are desperate to hire you. Software does not write itself. Companies need coders!

Get out of the mindset that the companies have the power and you have to avoid the monsters to get hired. NO!

That said, there are definitely things you can do to stand out and better prepare yourself to get the best job for you.

Have Stuff on GitHub

GitHub is the new resume/CV. Do something and publish it open source. You don’t need to invent the next Linux. You can just patch a library that you use, or write a new one. It does not matter what. Something useful is better, but seriously: if you have some things on GitHub that show that you can use GitHub and that you can code something, you automatically are ahead of most.

Contribute to Open Source

This implies that you actually use open source. Which you do, but if you are not paying attention you may not know it. Find something you are passionate about and work on it. See above about using GitHub. And if you are using something that’s open source contribute to it.

This is where you will think you are not good enough. Baloney. You can make the docs better if nothing else. Clean up the Makefile. Add a new description of how it works. Look in the Issues and find a bug and fix it and submit a Pull Request. Even if they reject your PR! You will learn from that, and your work will be seen and be see-able.

Understand the Purpose of a Resume/CV

Your resume/CV is not a document that accurately describes everythign you are or have done. It’s just an advertisement. For YOU. It’s only purpose is to get a hiring manager interested enough in YOU to want to talk to you. That’s it. Definitely don’t lie. But there is nothing wrong with editing things so that the most important things TO THE HIRING MANAGER will pop right off the page. Consider making a version just for the job you are applying for, and focus on addressing every point in the job description for which you have experience. Seriously. The person screening your resume (or AI) will be looking for reasons you don’t match. Don’t give them one. Match up every point you can. Yes, this is more work for you. So? You want that developer job right?

Practice Interviews

Practive makes perfect. Don’t go into the one interview for the job you really want and have not practiced. Seriously. Spend the time to have someone ask you practice questions. Read a book on how to interview. Always repeat the question back and ask clarifying questions. DO NOT just dive into what you THINK the answer is. Give yourself a minute, rephrase/repeat the question back. Then summarize what you know about the solution, then walk through your thoughts as you answer the question.

Most of the time the questions are designed to expose how you THINK, not what you KNOW. If the interview is a trivia game with short answers you really may not want to work there. Software is a job that requires problem solving, planning, and then execution. Don’t jump right to execution in the interview!

Practice! Goodness. Professional athletes practice their whole life, nearly ever day. What makes you think you can do well in an interview without practicing?

Know Yourself

Why do you want to be a Software Engineer?

No, seriously. Is it the money? Probably not. You probably fell in love with coding. You might understand computers better than you do people. You might love to solve puzzles and coding is the best puzzle. Whatever it is, KNOW THAT ABOUT YOURSELF. And be open about talking about it. The best thing to make you stand out from others is YOU. You are an interesting human with likes, dislikes, and passions. Be YOU. Don’t get me wrong: you definitely want to be positive. But have a perspective. Be genuine. At the end of the day humans hire other other humans and if you are an interesting human with a perspective and a passion - and especially if that fits the role or the company - then you will stand out.

What Should I Know?

Understand the Linux Command Line and Scripting

Even if you are applying at Microsoft, you need to know this. Being fluent at the shell is simply critical these days. Things in production are not done by point at click (not anywhere you want to work). It’s scripted. You need to be able to write shell scripts and probably do at least basic things in Python. This tutorial on the command line is amazing. Developers these skills are limiting themselves to a tiny fraction of the job market.

Understand Containers

Containers are the new abstraction layer. You simply have to know the basics. There’s a million blogs about it but this one seems simple enough to grok in a few minutes. I could have picked anything though. Know the basics of VMs and Containers, what they are for and how to use them. It’s not excusable to not know this in 2022.

Understand the Basics of Cloud

Unless you are ONLY working in mobile or embedded systems you should know the basics. You don’t HAVE to have an AWS or Azure cert (I’m ignoring GCP because I predict they won’t have a cloud within 3-5 years anyway - Google gets bored and kills product lines). But you do need to understand the core basics of how things scale using cloud. You don’t absolutely have to grok Kubernetes (k8s). But you really should understand how VMs are scaled in auto-scaling groups using Load Balancers, how regular databases can scale horizontally using sharding, how static content can be distributed using CDNs, etc. Know the difference between Block Store and Object Store. Know what k8s is and what it’s advantages are, even if you have never used it.

None of this is particularly hard. But it’s surprising to me how few candidates - even for mid-level roles - just don’t understand these basics. Yes, algorithms and data structures are important. But they don’t matter, practically, if you don’t understand the building blocks of how modern software is constructed. You really can’t even pretent to be a “full stack” developer if you don’t understand the basics of this. You should at least grok the how cloud makes things different.

Understand CAP Theorem

You also cannot talk about Cloud unless you can talk CAP Theorem. Consistentcy, Availability, Partition tolerance. All the cloud stuff above is all about this. It’s the WHY behind how cloud systems are built. I really like “An Illustrated Proof of the CAP Theorem as an explanation.

You will want to just skip that. Don’t. Understand it. You will thank me later.

Understand the Basics of Distributed System Desgign

This is on the road to more advanced, but it’s something you need to know soon even if it won’t be in your early inteviews. Read the System Design Primer. It’s especially amusing these days to think that some folks may (gleefully) ask you to “design Twitter” in an interview. This is the culmination of the above two areas, put into practice. As a junior developer if you have been exposed to those things you are far more likely to be useful right away to a new team.


There’s a lot more I could say, but I won’t. If you follow the advice above you will rise to the top of the pack. It may not be THE THING that gets you the offer, but you will be in the mix for the final decision.

If you are a mobile/front-end/embedded Engineer then you may think that less of this applies to you. But I would disagree. The principles above apply to embedded too. Ever tried to talk to multiple things across an I2C line? Tell me again how that’s not a network? Mobile has events propogating across multiple listeners. Tell me again how CAP doesn’t apply, at least in principle? And all three talk to other systems, so all the complexities of distributed systems will apply to how YOUR code works in the real world.

If this helps you, drop me a note on LinkedIn. And yes, you can pay for this advice: pay it forward. Someday, you will be a seasoned veteran with years of experience. Help others out. Share your knowledge. Mentor someone. That’s how it works.