How to Get Your First Developer Job

I've hired roughly 30 developers where the job would be their first professional position as a developer. I interviewed nearly 150 candidates. I reviewed resumes for about 300 candidates.

None of this is certainly going to get you hired, the goal is to just improve your odds. Also, each hiring manager is different. Sometimes the person doing the screening and first line interview may not have ever coded. This advice is much geared to increasing your odds with a hiring manager who is technical.

Github timeline

At the screening stage one powerful hack was to look at the applicat's Github timeline. All else being equal, I probably could have done ok just hiring the individuals with more activity in our target language.

Looking at the GH timeline also was a good reality check against the career story that the candidate would tell.

"Oh I've really been getting into python and machine learning" (checks github) no python repos, 3 commits in last 3 months. hmmm..

vs

"I've been experimenting with a few front end frameworks hosted on different platforms to try to learn common coding and hosting patterns." (checks github) Four differnt front end framework repos, each a similar app, all hosted on free services. 3-5 commits a week for past few months.

Notice how the second trajectory syncs to the history, whereas the first one doesn't. Given two candiates that seemed equally as strong I would lean towards the one that had a more consistent history. 3-5 dots / week for 6 months was better than a wall of comimts over the last 6 weeks.

tldr: As your math teacher said, show your work.

Understanding the Why

As a manager I wanted to explain our goals as a company. Then explain our goals for a project. Then describe the feature we were looking to build. What button was needed on which page, or how to store what data only mattered in the context of the user/customer accomplishing their goal.

During the interview process I wanted to see if the candidate was connected to the why of what they were doing and could explain how thier actions flowed from their own thinking connected to that why.

Often times school projects have a constraint imposed to drive practice with a particular concept. This creates some areas of subtley in describing the why for those projects. Here is an example:

Q: Why did you use Jupyter Notebooks and Pandas?

A: I don't know. Its what we used for that class. The lab was to run word frequency analysis on books.

vs

A: The goal was to practice the NLP we were learning in class. I had been reading alot of Sci-Fi so thought it would be fun to do pro-noun usage comparisons between male and female authors. I couldn't find the data easily, but I found all the books for one author, so I compared the first half their career to second half.

Even if

tldr: explain the goal not just the steps/techniques to achieve it.

Story Telling

My experience of writing software is that it is a journey into the unknown. I need to study, learn and plan, but also respond to the unexpected. When interviewing I wanted to ensure that the candidates had the right skills and attitude to confront the unknown and find a way through.

The best was when a story of debugging came up naturally. However sometimes I would try to prompt it with questions like:

• What problems did you encounter in that project? What did you learn?
• Tell me about a time you couldn't solve a technical problem, what did you do?

I was looking to the candidate to be able to describe:

• what they attempted
• the why of what they were attempting
• what broke/failed
• how it failed
• their thinking about approach to solve
• what they tried to do to fix the issue that didn't work
• how they approached the failure
• the technical specifics of what they tried
• what the failure looked like
• their approach to find a solution
• how they fixed the issue
• the technical specifics of what they learned

tldr: writing software is solving problems you haven't solved, tell me a story of your hero's journey.

Demonstration of Team Ability / Cooperation

Software is rarely built by one genius alone in a cave. Software and companies are a team sport. Rarely could I tell how good of a teammate someone would be. However, I certainly passed on candidates that didn't seem to have a collaborative orientation.

Examples of failures:

• bad mouthing former teammates
• a pattern of interrupting me or talking over me during the interview
• using I to describe all the work done on a team project but then not being able to explain the details and only when pressed admitting that a team mate completed that part of the project

tldr: software is a team sport, show you can work well on a team

Summary

None of this will get you a job for sure. Hopefully this will help you improve your chances of getting hired. If you are just starting out on a career change or planning for a professional coding job, you can do it.

• Consistency beats intensity
• Be able to explain your thinking
• Software is a team sport