The Daily Schedule That Helped Me Land My First Full-Time Dev Job After A Coding Bootcamp

By Brady Gerber

First published: November 2021

Last updated: September 2022 (added new book recommendations, my 10 rules of code, and the steps I take to solve live coding challenges)

THE TL'DR

• Aim to do a few things consistently every day, with breaks.
• There are so many aspects about the job hunt that we can't control. Looking for a job is more of an art than a science. Focus on what you can control.
• Be ready, financially and emotionally, to not land a job for at least a year.
• Make your schedule flexible enough to account for the days when you're sick, dealing with personal matters, or feeling drained and need to recharge. It's easier to take a short break than to try and bounce back from burnout. You’re not being lazy by taking a rest day.
• The right people aren't going to find you, pluck you out of obscurity, and judge you just on your work. You need to network.
• Practice coding challenges not to solve them, but to practice thinking and talking out-loud to break down difficult problems.
• When in doubt, Hash Table.
• Building side projects help, but only if you're actually excited about what you're building and want to talk about them.
• Other people's success is not your failure.

THE INTRO TO THE SCHEDULE

THE IDEAL READER

A recent college/bootcamp graduate or self-taught programmer seeking their first dev role and who doesn’t yet have an internship or apprenticeship.

THE GOAL

Create a flexible daily routine that builds up your skills and confidence and connects you to new people. The way I'm recommending is to do five "themed" tasks every weekday, in any order you want.

“DO YOU HAVE TO DO ALL THESE TASKS EXACTLY AS WRITTEN?”

No. However, I found that these “themed” tasks with specific quantitative goals helped me plan each day with activities that actually helped me in the job hunt, instead of spending hours each day sending a million generic applications into the void (like I did at first).

“HOW LONG SHOULD THESE TASKS TAKE?”

Each task should take at the most 50 minutes, with at least an hour break in-between.

“SWEET, I’LL REPEAT THIS SCHEDULE EVERY DAY AND EVERYTHING WILL BE PERFECT AND STRESS-FREE”

If you’re feeling ambitious, you could also do this during a free Saturday or Sunday. I would NOT recommend doing this every single day. This schedule is designed to help you treat the job hunt like a 9-5 job, including one or two days of the week when you don’t do anything regarding the job hunt. (I picked Saturday as my free day.) Having at least one day to recharge and step away from this very stressful work will only do your brain good. You’re not being lazy by taking a rest day.

"I THOUGHT SOFTWARE ENGINEERING WAS IN HIGH DEMAND. IT SHOULDN'T TAKE THIS LONG TO LAND A JOB, RIGHT?"

Yes, there is a high demand. For senior software engineers.

Part of my reasoning for joining a bootcamp was also because I heard that there was a high demand for software engineers. I figured that it would be relatively quick to get that first entry-level position. I was wrong. From all the recruiters and employed engineers I connected with throughout the year, the story remained the same: During COVID, most companies, for various reasons, were focused on hiring talent that could plug-in, work, and add business value right away, instead of taking the time and resources to invest in new talent.

I also decided to go back to school during the first fall of the pandemic, which, looking back, felt like it was during a low of the COVID job crash. I believe that the job market is now doing better and that more companies are now able to invest in more entry-level positions.

A NOTE ABOUT SETTING EXPECTATIONS

You know your goals, abilities, and limitations better than anyone. Some people have the means and resources to take their time with the job hunt. You may have a family to take care of, or you may have to work another job to pay the bills while you look for a job. We have to make due with the time and energy we have, and the time and energy we're willing to put in.

Yes, you will see less qualified programmers get jobs quicker than you. No, it doesn’t get easier seeing another “SOME PERSONAL NEWS!” LinkedIn post after you just received another rejection email. No, this doesn’t mean you’re not qualified to get a job. Other people’s success is not your failure.

This schedule worked best for me, but it’s most important to be inspired to create your own schedule that works best for you. The job hunt is more of an art than a science. It’ll take a lot of trial-by-error. It’ll also take time. You might not see the benefits of what you do until maybe a week, a month, a season, or even a year later. That fellow bootcamp graduate you met at that virtual networking Meetup and bonded with over John Wick might be the same person who five months later gives you the personal referral for a new position at the company they just joined. Truly, you never know.

It took me eight months after I graduated from my 12-week full-time bootcamp to get my first full-time salaried offer. This was during the COVID job crash, and looking back, I probably picked the worst (or best?) time to get into software engineering. I was fortunate enough to be able to take a loan from my family to go back to school and help pay for living expenses, along with the money I made from my freelance writing. After a few months, I moved back home to save money. I signed my offer almost a year to the date after I put in my two-weeks of my last full-time job to pursue software engineering. I had to pause my job search a few times, including a few weeks when I moved back home. I submitted nearly 200 applications, and I heard back from maybe a third of them, mostly rejections. I was invited to interview with 12 different companies, where either I didn't make it past the first phoner, or I made it to the final round and, out of the 10 chosen candidates out of a pool of hundreds of applicants, I was #11. Ironically, it was company #13 that worked out.

All it took was one yes. I wish that one "yes" came earlier. I also believe that the right "yes" came exactly after I had trained myself to be ready for that exact "yes." I hated hearing this advice while I was looking for a job. Now that I'm on the other side, I understand it. In other words, if you didn't get that one job, that might have been a blessing in disguise.

There was no one single thing I did that turned me from a total beginner into a qualified applicant overnight. It was the cultivation of staying consistently devoted to practicing and learning, rolling with the highs and (many) lows, and listening to my mind and body and knowing when to step away. It took me eight months, but I believe if I had this schedule from the start, I would have either found a job quicker, or I would have saved myself a few periods of depression and a lot of stress.

Focus on creating fruitful and meaningful individual days, and you’ll be surprised by how quickly and strong your garden of knowledge will grow. As the saying goes: chance favors the prepared mind. Here’s another saying I like from Annie Dillard: How we spend our days is how we spend our lives.

ANOTHER NOTE ABOUT BOOTCAMPS

Overall, I had a positive bootcamp experience at General Assembly. They do a lot of things well, and at the time, I needed more hands-on and interactive teaching, instead of teaching myself from scratch without any accountability. With that said, if you can teach yourself software engineering and don't have to take a loan to do a bootcamp, save your money and do that. I'm a music journalist and went to a four-year college and got degrees in business and music, but before GA, I had built a few Wordpress blogs and I knew very basic HTML and CSS and was aware of JavaScript. When I was deciding if I wanted to make the leap to a bootcamp, I first did a few course on Treehouse just to see if I even wanted to code. When I realized that I actually enjoyed coding even in my most frustrated moments (how do you center a div again??) I knew I was ready.

I think a good bootcamp is one that can teach you how to learn and practice new languages and frameworks quickly, how to be comfortable jumping into difficult problems and breaking them down with other people, and how to develop a healthy relationship with frustration (as someone who now codes full-time, that frustration never goes away). Actual employers don't care if you're the world's greatest React developer. They want to know if you're a good team player, and someone skilled enough in React who also can learn Vue or Go (or whatever is the next trending framework) right away if needed. Anyone can watch a bunch of YouTube videos and start building stuff - but can you explain the WHYs instead of just the HOWs?

This schedule is meant to build off what you hopefully learned in bootcamp, but this also works for someone who hasn't done a bootcamp and is starting from ground zero.

AND A NOTE ABOUT BURNOUT

If you're in the job hunt long enough, burnout is going to happen one way or another. There's no perfect planning that you can do to prevent it. It often felt like the universe's way of checking in and asking: "Do you still want this?" It's brutal. Most of the time, I made the mistake of trying to power through burnout instead of stepping away for a second. Most of the time, that decision kept me burnt out. The longer I stayed burnt out, the longer it took me to recover, thus the longer it took me to get a job.

Seriously, take breaks.

And now, onto the dang thing.

THE SCHEDULE

APPLY (50 minutes)

Networking for people who hate networking.

Networking can feel gross and unnatural, especially if you're an introvert like me. It’s also necessary. I wish it wasn’t. However, the right people aren’t going to pluck us out of obscurity and base our value only on the quality of our work. I know this because at first, I just waited around and focused on only coding by myself. But no one does anything on their own.

People get jobs for many different reasons. Many of those reasons are beyond our control, good or bad. Some of those reasons remain mysteries to us (and to the people who hire us!). The one thing you can control is how you grow and treat your network and support system.

Every weekday, submit at least 1 new application, with your resume tailored specifically to the job description; send 1 cold email or LinkedIn message to a senior software engineer at a company you like and wish to learn more about how they got into their role; attend 1 networking event or Hackathon; or complete 1 part of the interview process (the initial phoner, a live coding challenge, etc). Even spending 50 minutes researching a company and writing out potential questions for an upcoming interview is a good use of time.

You can do all the above in one day if possible, which I encourage. At the very least, just aim to do one of these things that gets you out of your head and connects you to the outside world.

Some engineers and recruiters will recommend that you send 40+ applications a week. If you can do that, go for it; I've had friends who did this and succeeded. However, from the past year of trial-and-error, I found that a few very thoughtful and intentional connections were way more helpful than a million generic applications quickly thrown into the void. Instead of "networking," think of it as "making friends before you need them." And friendships take time.

It was because of my network and personal connections that I landed my first production environment Agile-team work (Patrick!), my first paid work as an engineer (Sophia!), and my first full-time job offer (Patrick, again!) all of whom I kept in touch with throughout the past year, even just to check in and gossip about Kevin Bacon. Don’t just reach out to people only when you need someone. Check in on them, too.

A NOTE ABOUT DISABILITIES AND ACCESSIBILITY: I have a disability, and for the first couple of months, I made a point to not bring it up during the interview process because I didn't want to be taken out of consideration, even though I knew that my disability affected my ability to take technical challenges. I was too proud, and I thought that I wasn't allowed to ask for the help that I knew I needed. But eventually I decided to bring it up to recruiters and hiring managers early on in our conversations, and I was amazed by how accommodating and respectful everyone was. I know bringing up disabilities is tricky and emotional, and recruiters might advise different ways to bring up interview accommodations. I also now know that you are not hurting yourself by being honest. And if a company doesn't want to hire you because of who you are, do you want to work there?

• ACTION STEP #1: Before you do any networking, make sure your LinkedIn profile is fleshed out and that you're taking advantage of everything it has to offer. (Here’s my profile, which I'm always trying to improve. Also, if you're reading this and this helps you, reach out and let me know!) Two books I recommend to help you clean up and use your LinkedIn (and how to write excellent cold introduction messages) are Steve Dalton’s The 2-Hour Job Search and Nick Bull’s Win The Interview Game (the latter is where I learned the trick of doing several themed tasks each day with breaks).

PRACTICE (50 minutes)

Make the eventual technical challenge easier … or at least less of a pain.

This is my least favorite task. You still need to do it. Every weekday, Complete or review 1 coding challenge that teaches you something new, tests what you already know, or teaches you new ways to solve problems you already know that you’ll eventually see during an interview. Many people like LeetCode, but I found NeetCode and CodeSignal to be easier to use and where I consistently ran into the most problems I saw in actual interviews.

To make your life easier, create a private repo where you can save all the challenges you practiced and completed for interviews for later review and refactoring. Did you complete your challenge in less than 50 minutes? Sweet! Do it again! And can you find a more efficient or cleaner solution?

Remember: the majority of these companies are not expecting you to solve the entire problem perfectly or in time. They are testing to see how you handle difficult questions and problem-solving on the spot. Do you freeze up and not talk? Do you first ask questions to clarify the problem and try to make a plan? Do you ask if you’re allowed to Google, or clarify what resources are available to you? Do you dive in right away and hope for the best? Anyone can learn syntax; the goal is to prove that you can learn and ask informed questions, and that you seem like someone a company can work with.

• ACTION STEP #1: Before you start NeetCode or CodeSignal, the first three beginner problems you need to master in your language of choice are Palindrome, FizzBuzz, and Fibonacci. If you can solve each problem without referring to any notes or Google and can articulate your logic and thought-process (and how you would improve upon your solution if you had more time) out-loud in under five minutes, you’re way ahead of the pack. My favorite book on how to improve your logical problem solving skills is George Pólya's How to Solve It.

STUDY (50 minutes)

Give your future self a break.

Create a new Google Doc (or Notion, or whatever note-taking device you prefer) and every weekday, fill out 1 page with whatever topic you want to learn. Reread your class notes, read new articles, or watch YouTube videos or anything else that teaches you something new.

It’s best to focus on one specific topic a day or create a theme for the week (i.e. spend a week following a YouTube series that breaks down everything you need to know about React). Did you bomb a technical challenge because you didn’t understand JavaScript Promises or HTTP GET requests? There’s your next topic. Create the ultimate reference tailored to your knowledge gaps and how you like to organize your thoughts. And the underrated benefit of creating a master reference: when you run into technical challenges that’ll allow you to refer to notes, you’ll have one ready.

If you don't know where to start, here are some topics that I believe most of us should know pretty well, as a full-stack software engineer who mostly enjoys working in the front-end and works in vanilla JS, React, and Python:

• HTML
  • Basic semantic HTML structures & attributes
  • Be comfortable creating a working HTML file on the spot from scratch (aka do you actually know what each line of code does?)
  • Know how to build out input fields & tables
• CSS
  • Flexbox & CSS Grid
  • Responsive design & media queries
  • The basics of Bootstrap and Material UI (or at least know what they are and how they are different)
  • Working with SVGs
  • Pretty much every topic covered in CSS-Tricks (their Flexbox and CSS Grid references are the best I've seen anywhere online)
• JavaScript
  • Variables (know the difference between var, const, and let and when to use each)
  • Scope, hoisting & closures ("this")
  • Data types (number, string, boolean, null, undefined, etc)
  • Operators & expressions
  • Objects & OOP
  • Arrays & the major array methods (ex. Map and Filter)
  • Functions and knowing the differences between callback functions, higher-order functions, function declaration, function expression, and arrow functions
  • Know how to build a Hash Map/Hash Table from scratch, and then with Map. (This is VERY important; if you think you can solve any coding challenge with some type of Hash, try that first.)
  • Conditional statements (if, ternary, switch)
  • Loop statements (for, for of, for in, while, do while)
  • DOM events & manipulation
  • Promises and Async & Await
  • JSON: know what it is and how to work with it
  • REST APIs, HTTP routing, and making API calls (Fetch, Axios)
  • Using different kinds of Auth
  • Using setTimeout and setInterval together (can you make a console log countdown timer from 10 with 2 seconds in-between numbers?)
  • RegEx
  • Testing (ex. Mocha or Jest)
  • Modules (exporting and importing)
  • Basic JS Security theory (XSS & CSRF)
  • jQuery (Some engineers will roll their eyes at me suggesting jQuery, but in the real world, I encounter many websites that still rely on it. It's good to spend at least one day learning the basics. I also use jQuery for my job, so you never know.)
• I also have notes for React, Node.js, Express, MongoDB, how to "Hello, World" with the MERN-stack, TypeScript, Python, Django, Go, SQL (Postgres & MySQL), AWS S3, Accessibility, and more.
• ACTION STEP #1: Whenever I’m starting a new topic, I usually start with a solid YouTube series where I follow along with the code in a new study repo. My two favorite YouTube coding tutorial channels are Traversy Media and Web Dev Simplified. A lot of people also like The Net Ninja and Programming with Mosh. If you also enjoy books, I'd start with Robert C. Martin's Clean Code and Clean Coder (read the former before you read the latter).

CODE (50 minutes)

Keep your GitHub green.

Every weekday, Create 1 new GitHub green square. You can do this by committing code a few different ways, including refactoring your old bootcamp projects, creating and working on new repos (public or private), and contributing to open source and making pull requests. GitHub allows you to pin any six repos on your profile, so make sure those six pinned repos are projects you’re really proud of and can talk about during interviews. Also, every interview I did involved me talking about an example of when I worked with other engineers on a project; if you can build at least one repo with other engineers or UX Designers, you'll be in good shape. Here’s one way to approach these six repos (thank you, Howie, for these tips!):

1. A creative app that shows off the tech stack you wish to get paid to do. If you're applying for React jobs, build something in React that demonstrates your understanding of state, hooks, and all the things that you can do in React that you can’t do in vanilla JS. No matter your tools or frameworks, include some type of testing. (What I built: a React-built study guide teaching Big O, algorithms, and data structures through The Simpsons, with amazing designs created from working with a UX Designer.) (Thank you, Molly!)
2. A working app that conveys your understanding of databases and APIs and which creates real-life business value. For example, you can build a calendar app with the PERN-stack and include some type of Auth, testing, and AWS functionality. If you share this app with your grandparents, would they be able to understand what it is and how to use it?
3. A clone of a popular app that proves you can recreate something that a lot of people use. THEN add your own personal spin and improvements. (What I built: a minimalist Spotify clone that prints off lyrics while you listen to a song.)
4. A functional app using some kind of object-oriented language: Python, Go, Java, C++, etc. Even if you’re a front-end or full-stack engineer focusing on JavaScript, it’s good to show that you also can work with other kinds of languages. Keep it clean and simple, even just to show off the fundamentals.
5. A shared, open-source repo that encourages collaboration. Through your bootcamp class, Hackathon team, or open source collaborations with other people. This will force you to work with other people, and it’s a great way to practice contributing to open-source and making pull requests on GitHub. For example, you could start a repo with your bootcamp class where everyone contributes one terrible animal pun in one always-expanding README file. Keep it simple and engaging.
6. Whatever you want! If the five previous ideas sound boring, first make something you’ve always wanted to make. It’s a lot easier to code something when you … actually want to code it. It also shows that you actually enjoy programming and that you’re not doing this just for the money.

• ACTION STEP #1: An easy way to get started with building more repos: Create a personal GitHub README (here’s mine).

STAND UP (50 minutes)

Get away from the computer.

Seriously. Every weekday, do things that take care of your body. Do 1 type of exercise or non-sitting activity that raises your heart rate. This is so important that it deserves to be its own task. Even if you only have time to walk for an hour, that’s enough. If you don’t live in an area that’s great for walking or going outside often, walk around your living space, do home workouts, stretch throughout the day, or whatever you can do. Make sure your work space is built to work with, not against, your body. Get at least seven hours of sleep every night. Try cold showers. Eat at least one raw veggie every day. Eat until you feel only 80% full. And so on.

• ACTION STEP #1: My go-to workout when I’m strapped for time is this 15-min HIIT workout (no equipment needed). I also do this 10-min morning yoga exercise every morning.

LAST NOTE

You are not your work. The job hunt is hard, and no one owes you success or a career. It is not your employer's job to make you more marketable. Keep your eyes on the prize, and your future self will thank you for taking a chance and doing something very difficult and very rewarding.

If I can do all the wrong things and still get a job, believe me, so can you.

Thanks for reading.

EPILOGUE: MY 10 CODING COMMANDMENTS

In honor of the (almost) one-year anniversary of publishing this guide, I've updated it to include some lessons and reminders about coding that I've learned as a full-time software engineer. These are the rules I didn't quite understand while originally writing this guide that I now embrace every day at work.

1. Life is not a line but a circle: breathe in, breathe out. Work, play. Write, edit. Code, refactor. Garbage in, garbage out.
2. Before you do anything, first identify the problem, then break it down.
3. Create automated tests - and make sure your tests fail when they should, as fast as possible. (Fail fast!)
4. Either add a feature or refactor old code. Don't do both at the same time. Repeat as needed. As soon as all your tests pass, stop!
5. Does this code makes sense hand written?
6. Don't be great. Be good, and have great habits.
7. A good function is like a good sentence.
8. I owe it to my boss to say No.
9. "I will [action] by [set time]." Doing anything more complex at any one time is overthinking.
10. Coding teaches us to problem solve. This is a good thing.

ALSO, MY REMINDERS FOR LIVE CODING CHALLENGES DURING AN INTERVIEW

I mentioned George Pólya's How to Solve It earlier in this guide, which really helped me gain confidence in doing live coding challenges. Based on Pólya's book, I also wanted to add the steps I try to remind myself ahead of a coding interview:

1. First, remind yourself that you don't need this job. Putting too much pressure on just one interview will hurt you more than it will help. You're still a capable engineer if you don't get this job.
2. Read the problem (silence)
3. Clarify the problem (ask)
4. Confirm the problem (re-tell)
5. Break down the problem and the steps to address each step (outline)
6. Solve the now broken-down problem, step by step (sanity)
7. Review your work and next steps if given more time. End strong. ("In conclusion ...")

All photos taken from Doodle Ipsum.