Now that you know how the system works on a high level, let's look at what the system is expecting from you. Specifically, why a company would bother to hire you in the first place and the kinds of characteristics they are looking for.
This is useful because it will help you to craft a better personal narrative and to sell yourself well on your resume and in interviews. It will enable you to maximize the few shots you'll get.
Why You Are Being Hired
The most important thing to understand is that someone is hiring you because they can make more money or save more time by hiring you. We'll say it again -- your job is almost always some form of making them money or saving them time. Internalizing this simple fact will hopefully help you to see past the BS job description and to the pain that someone in that organization is feeling that they believe will be solved by you.
Hiring managers are busy people and, based on prior experience, they generally have a pretty good idea of what a "good developer" looks like. They generally don't spend too much of their valuable time worrying about how to seek out good candidates who might not fit their profile because that takes too much effort. They just want to get back to building stuff and not have to hire again anytime soon.
A "Good" Developer
So what is the profile of a "good" developer?
Let's look at this from the perspective of a hiring manager. The hiring manager is looking for someone who can:
- Write clean and effective code
- Work well with other members of the team
- Present well to clients (if it's a client-facing role)
- Generally require little help to get going.
- Continue to grow skills and knowledge without needing to be asked to.
- Stay with the team as long as possible.
Basically, Can you add value immediately and grow fast enough to keep up with the team?
Hiring managers generally determine these things by looking for the following characteristics in applicants:
- Intelligence to take on challenging problems and not be broken by them.
- Curiosity to constantly learn more and grow skills.
- A Hacker Mindset to solve tough problems in innovative ways.
- Passion for development, which drives both work ethic and curiosity for new knowledge.
- Deep Technical Knowledge, ideally but not necessarily in the relevant technology stack.
- Good Communication with other team members.
- Genuine Passion for both development and the company's specific mission.
They tend to try and identify these characteristics in applicants by using the following markers (whether you believe that should be the case or not):
- Relevant prior work history. It sure helps if you've already done the job already! It means someone else has already gone through the hard part of training you in professional workflows and how to work in that kind of environment.
- Relevant school experience (a CS degree), especially from a good school. Again, it means that someone else has decided you're "smart enough" to admit to their school and that you've persevered through 4 challenging years of studies.
- Relevant side and open source project experience, especially with the technologies that are most relevant and at a production scale which would mimic the real work environment. Projects are particularly interesting when they are side projects because it indicates that the developer is passionate enough about learning and building that they will do so on their own time. That sounds a lot like "free training" for that person as an employee!
- Ability to code live, especially in interviews. There's no substitute for actually coding.
- Ability to solve challenging conceptual problems, especially technical problems in interviews. These are used both as an intelligence test ("can you figure it out???") and as a test of your previous education ("you really should have seen problems like this before if you'd had a 'real' CS education").
- Ability to answer trivia questions about languages and development practices, especially any languages you claim to know well. This is a test of your previous education (was it just surface-level or did it actually cover true fundamentals?) and of your tendency to constantly seek greater learning (because you learn most trivia simply by being curious about how languages or systems work and discovering it on your own).
- Smooth and "normal" communication with team members and interviewers. Everyone's quirky (especially in this space) but if you can't communicate with the team, you aren't as useful as a less talented developer who can.
When you are coming from a non-traditional background, you won't be able to hit all of these bases but it's important to know what they are.
A "Bad" Developer
Most hiring managers have been burned by bad developers or candidates who have wasted their time. Just like your code can have "code smells", here are a few "applicant smells" they will be on the lookout for:
- The "9-5" Developer: This is the developer who is pretty good at his or her job but doesn't really put in much effort outside of work to keep up with new technologies or keep learning. While there's nothing absolutely wrong with working your hours and having a life outside of work, the best developers are always learning and curious about it. Managers don't want to have to tell you to go and learn the latest design patterns, they want you to already have explored it on your own.
- The "Shallow Experience" Developer: This developer was trained on the latest framework and can put together a very specific kind of app but has no fundamental understanding of how development actually works and is therefore unable to innovate or solve truly challenging problems. Asking this person to use technologies they haven't tried before is a disaster.
- The "In It For the $$$" Developer: Like the "9-5" developer, this one essentially puts in the minimum effort necessary to get the job done and only learns on company time.
- The "Sloppy Cowboy" Developer: This developer has some raw talent but simply can't be bothered to follow good code conventions or proofread code for bugs. This developer causes significant headaches down the road and leaves the code base a mess.
- The "Hero Solo" Developer: This developer is good and knows it. Unfortunately, he or she is simply not capable of playing nice on a diverse team and ultimately poisons the team dynamic through some combination of imperialistic, condescending or generally asshole-ish tendencies.
- The "Bad Work Habits" Developer: This developer can't keep a schedule, show up on time for meetings, or follow up with reasonable human communication. Too much of a pain for a manager to keep track of.
- The "Rigid Non-Creative" Developer: This developer is talented when presented with previously encountered problems but needs to be told exactly what to do and can't solve problems he or she hasn't seen before.
- The "Just Waiting for the Next Thing" Developer: This developer is simply harvesting skills at this job and will leave as soon as a better one comes up or a group of friends has a cool startup idea to pursue. That leaves the manager in a lurch because they've just invested time and money to train you when you decide to call it quits.
You would be well advised to do everything in your power to avoid fitting into these stereotypes.
How to Play to These Things
When you have a non-traditional background, you are at a significant disadvantage in the "credentials" category, which includes work experience and educational credentials. But you generally have a much stronger growth curve, passion, and project portfolio than your average recent grad or intern. Essentially, you are a case of "talent" instead of "knowledge".
If someone would just give you a legitimate shot, you could prove how useful you can be!
As mentioned in the previous lesson, the way to use this to your advantage in the hiring funnel is to avoid the top of the funnel (blind resume submission) and focus on skipping steps to the middle by connecting with real humans inside of an organization. We'll show you how to do so in upcoming lessons.
Hacking the hiring funnel explicitly isn't the only way to use these ideas, however. You should think about this stuff when you imagine how to present yourself online, in your resume or in an interview. How can you fit yourself more cleanly into the kinds of expectations that hiring managers have for what a "good" developer is while avoiding the "smells" of a poor hire?
We'll discuss this as well in upcoming lessons, but the key is to focus on cultivating the characteristics of a great developer -- intelligence, passion for the art, rapid growth and great communication.
There are a handful of other useful principles you should keep in mind when thinking about how to fit yourself into the expectations that a hiring manager will have for you:
- Social Proof: If others have shown their support for you in the past, your perceived value rises significantly. So emphasize any times that you have been accepted into selective programs, won selective awards, or worked on teams with other people.
- Be a Growth Line, not a Point: It is much more powerful for someone to see you grow from one place to another than for them to see you only at the end point. In the first case, if you simply make yourself known to someone early in your learning process and then demonstrate how quickly you have learned later on, they will be able to extrapolate your learning curve and should be duly impressed. In the second case, they have to evaluate you completely based on a single interaction (eg. an interview) and that is quite challenging. This principle is the basis of many tactics we will present later on.
None of these are silver bullets, but you can gain significant leverage by incorporating them into the way you present yourself and interact with hiring teams along the way.