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.
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
no python repos, 3 commits in last 3 months. hmmm..
I've been experimenting with a few front end frameworks hosted on different platforms to try to learn common coding and hosting patterns.
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.
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.
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.
tldr: explain the goal not just the steps/techniques to achieve it.
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:
I was looking to the candidate to be able to describe:
tldr: writing software is solving problems you haven't solved, tell me a story of your hero's journey.
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:
tldr: software is a team sport, show you can work well on a team
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.
Enter your email If you would like to get an email the next time we post.
We post about ~1-3x per month, and up to once a month about company news.