"What Code Have You Written Professionally?" - Getting (and Giving) the Big Break

"What Code Have You Written Professionally?" - Getting (and Giving) the Big Break

TL;DR - This is how we help people start their new careers in software, and companies find the right talent, at the same time.


  • The Problem - Most code school graduates have the right skills to start their new careers, but lack real experience working on a team, building a project for some kind of monetary compensation.
  • Our Solution - Provide code school/bootcamp graduates with real world experience, with mentoring from proven engineers, getting experience on a real project, and making money for themselves and their clients.
  • Everyone Wins - We build quality software for clients, at significantly reduced costs and improved convenience using onshore talent. For clients who want to hire, we provide trained, mentored developers to work on their existing codebase. This minimizes the risk in hiring these talented, newer developers in an improved, "contract-to-hire" scenario.

Change Careers, Change Your Life

Eleven years ago, I left the Navy and started my new career journey in the private sector. I had spent the last six years driving ships, operating nuclear reactors, and living an adventure that although was very exciting and challenging, really wasn't for me. Once I decided to leave the Navy, I had no idea where I would end up but I knew that because of my master's degree in Computer Science, I would have a good shot at landing my first job post-Navy, even though I had very little practical IT experience.

After the Navy, I began to weave my way through a winding yet gratifying career-path, working in Information Security, Software Development (web, mobile, and DevOps) as both an employee and a freelancer, and finally making my way to Tech Recruiting, with an earnest desire to build something special being the only driving force I ever needed. Today, there are thousands of Code School and Bootcamp graduates that want the same thing:

These aspiring developers want to discover if that voice that tells them that they need to build something is leading them to a dead end, or if they have something creative inside of them that needs to come out.

This is the driving force for many new software developers, and especially code school graduates. A career in software is a way to build a future where this creative force can be used on a daily basis to hopefully improve the lives of others. They can also provide for their families, and make a living that they're proud of, as software development salaries continue to increase for skilled coders, while the need for a degree in CS (let alone a master's in CS) is becoming less important by the year.

The Big Break

The secret sauce in all of these career moves comes down to a few steps that are fundamental to any career change:

  1. Knowing in your heart there is something else you want to be doing, and actively envisioning yourself doing whatever that is (aka Dreaming).
  2. Setting a goal and planning out a strategy on how to achieve your goal.
  3. Deciding to take some positive action in the direction you want to go.
  4. Putting in some really hard work and long hours.
  5. Accepting any obstacles and challenges that may come your way as opportunities for growth.
  6. Landing yourself a good bit of luck to get your big break

It also doesn't hurt to have some big, primary motivator for the life changes you're considering, or the "why" behind your decisions. It may be a better life for your family, more job satisfaction, or just because you don't like where your life is headed, and you want to try something different. We all have different reasons for doing what we do, but I think the healthiest moves I've made in my life had to do with wanting a better life for myself and my family. That's always been my "why".

Of the six listed steps above, though, the first five are completely within your control, and when done with consistent energy and passion, can be executed and completed faster than you might have initially thought possible. The last one, whether you believe in luck or not, becomes less important the more you work on the first five, but ultimately it comes down to you believing in yourself, and equally as important, convincing someone else to believe in you too. This is the hiring manager, or interviewer and convincing them to believe in you enough to give you a shot at the job you want, is your most important task, post-graduation.

Easier "Blogged" Than Done

But that's easier said than done, right? It takes a great amount of resilience to go months knowing that you want to do something and having rejection thrown at you left and right. Also, despite all of those people that seem to know what they're talking about, telling you that you can't do it, you have to find the belief in yourself to not let those people discourage you from your dream. It's like you have a small pilot light inside of you, that represents your belief in yourself, and every two to three weeks after going through an average interviewing process, a stiff wind comes by and tries to blow out your light. That's what code school graduates face after graduation, and depending on how well their chosen code school prepared them for interviews, the wait for the right opportunity, and trying to overcome that last bit of self doubt on their first day on the job, that can be a long time.

The Question Every Code School Graduate Dreads

So why is there so much rejection when most code grads can do far better as a Junior developer than I ever did ten years ago? These graduates have been highly trained using curriculums that have been designed to deliver as much information in a short amount of time to aspiring developers who may not have come from a technical background.

Imagine you're walking into a your fifth on-site interview, and predictably, inevitably, they ask you the question:

What kinds of coding have you done professionally?

This is not the question you think it is, though. Yes, on the surface it seems like they just want to hear if you've spent time coding for someone else, but what they're really asking you is:

Can you convince me enough with your answer to hire you on blind faith, because without experience, I'm having a tough time seeing you as a "good risk".

Yet, worse is if the person asking you isn't very technical, like many of my fellow recruiters, because they're trying to get enough of a warm and fuzzy feeling to send you on to the next round when really, they don't know an API from an ATV.

If you don't have the best possible answer to the question, which is that "you completed X project, you were paid on-time in gold bars, and the app went on to become what we now call Instagram," then what do you do? You have the same problem every other person trying to catch their first break has to face, which is convincing a total stranger to believe in you. What kind of answer do you give them if you barely believe the answer to the question you're about to give: that you have confidence in your ability to do a job you've never actually tried yet?

The Problem (From all Angles)

From the new developer's standpoint, it's the classic chicken vs. egg scenario. I can't get a job if I don't have experience. I don't have experience if I don't have a job. I can't get confidence to convince others to give me a job if I haven't had either.

That's fair (or maybe a bit unfair), but from the hiring manager's perspective, you can't blame them for feeling as though there is a great amount of risk involved in every code school graduate hire. Estimates will vary, but the cost of a "bad hire" is a significant portion of that person's first-year salary, which is why my job as a recruiter isn't just about throwing resumes at a wall and hoping they stick. Saying "oops, I goofed" on a new employee can be a tough pill to swallow because it impacts delivery timelines, team morale, and makes even seasoned hiring managers second-guess future hires that even closely resemble "the one that got by our defenses".  If the "bad hire" was a code school graduate, if the manager doesn't see the real reason why the hire didn't work (poor cultural fit, lack of mentoring, etc.) then he or she may make a poor assumption, and throw all code school graduate resumes in the "bad pile", which hurts everyone.

What's Left To Do?

What about working on your own projects, though, will that help? Sort-of, but not as much as you would think. There is a great amount of self-validation that comes from saying, yes, someone paid me to build something, and it's still standing today. Saying that you've actually been paid for a gig inspires so much more confidence in others as well, because it shows that there is actually value there, that it makes it worthwhile to trade some money for your time and effort. The thinking goes, "someone was willing to pay you for your work, and it paid off for them, so most likely, it will pay off for me too." I do tell aspiring developers to polish their personal work if they are showcasing it on their resumes or LinkedIn profiles, because these projects can leave a lasting impression.

It seems then, the only real way to calm everyone down and prove that someone can do a job is to go ahead and give them a shot at building something for pay, but how? Although quite a few companies tried the tactic of a two week "trial period" to begin a new job, not many experienced developers, these days, would take the risk of quitting a perfectly good job to have a "try-out" at another. There has to be another way.

Our Solution

The idea came to me when I was thinking about the problem of code school graduates not possessing confidence in their abilities, and as a result, not being able to inspire confidence in the person trying to hire them. When I started coding professionally, I knew a little ruby and had done some Java and C++ in college, but nothing that could come close to professional grade. After writing code for a decade, I've worked, mentored, and talked with code school and bootcamp graduates and their code is light years ahead of anything I wrote a decade ago! I gladly spent most of my time in these mentoring sessions building up their confidence, not critiquing their code.

Also, when the idea hit me, I knew that the one thing that builds confidence faster than anything, from my experience, is practical experience. I thought of my time in the Navy, going to the Naval Nuclear Power School which sounds dangerous and explosive, but really is quite cerebral and quiet and how in just a year, we were taught and gained confidence in our own abilities to operate a nuclear reactor. The first six months were spent learning the theory behind reactors, i.e. nuclear engineering in a nutshell, and then the second six months had a practicum element, where you had to apply what you had learned by operating a real reactor (on a retired submarine). The first part was just to cram our heads with as much book knowledge as possible, and the second part was where we could prove to the Navy that we could actually do the work they were training us to do. Luckily, software teams operate very similarly.

What does this look like for a software team?

  1. Bring one or more developers onboard (at least one senior) to learn the codebase and get used to working with the team's dynamic, or start a new team on a greenfield project to allow it to establish its own culture.
  2. Bring on one or more recent graduates of a code school and mentor them through:
  • Code reviews: adhering to coding standards, refactoring, and team coding style.
  • Team Dynamics: managing expectations, conflict, and interpersonal issues
  • Quality: learning how to find and squash bugs, write great bug reports, QA their own work before submitting, testing best practices, etc.
  • Retrospectives: periodically reviewing and celebrating both individual and team successes.
  • Use Your Words: teach them that no matter how junior they feel, they have a right and a responsibility to speak up if they need to.

3.   Carry out weekly touchpoints with each developer to give honest and thorough feedback to help address any issues early, talk about goals, and evaluate them against a standard.

4.   Once they are ready to be hired, or move on to a different opportunity, work with them through that transition, and if needed, start the process over again with another developer.

Everyone Benefits

This kind of an approach creates mutual trust which is the foundation of any relationship, especially one at work. It also gives the developer confidence that they can work on a team, and sets a standard for the follow-on teams that these developers can use to measure and apply to other teams. This also simplifies and eases the new developer into an onboarding process which is tailored to help them succeed. Success can be defined simply as whether confidence has increased from Day 1 to Day X, but the ultimate measurement of success is continuity and whether the relationship between developer and team remain intact. If it isn't a good fit, that can be determined earlier than if the mentor isn't as hands-on, and the feedback loop is not established.

For the client, it is a contract to hire setup, with training wheels to help both the team and developer gain confidence in each other before making a full-time commitment. It's also a way to get work done for less as a good amount of the work will be done by the junior developers, with as much pairing and oversight from the more experienced developers as possible.

This type of scenario really is a win-win for everyone involved because it cuts the risk in hiring new developers for clients/hiring companies, and gives the new developer a chance at their first big break, maximizing everyone's chance for success through mentorship.

So Here's Our Pitch

We've mentored many junior developers in a very similar or the same manner as we described above. Some were mentored through more than just the "soft-skills" mentioned: we also had to teach them how to code. With codeschool graduates, theoretically, that isn't necessary because they have already paid tuition for that part. All they need, instead is a chance, and we give them that, along with confidence that they can get the job done, and the oversight to make sure everyone stays happy in the end.

If you'd like to work with us, let us know! We've proven this model works and we would love to help you achieve your development and hiring goals: help you complete your project successfully, save your budget for other things, and line you up to easily hire and onboard the team you've been working with. You can submit your info here on our signup form or by sending us an email.

Photo credit: Mimi Thian / Unsplash