If you enjoyed this book considering buying a copy

Chapter 9: How to get a job in tech #

An essential part of getting a job in tech is to think through the problem from top to bottom. What are the bottlenecks, and how do you solve them? A critical bottleneck is the humans involved. These humans range from Human Resources to Engineering management.

What can you do to speed up the bottlenecks? One thing you can do is become a “Triple Threat.” This concept helps reduce the friction in deciding whether to hire you.

Triple Threat #

What is a triple threat? It means you have many qualifications that individually make you well suited for the job. An example could be:

Threat One: Advanced degree or Extensive work experience #

One easy way to stand out for a job is to have an advanced degree in a relevant field. If applying for a Data Science position having a Master’s degree in Data Science is very helpful. Not everyone has the time or money to get a Master’s degree.

Other alternatives also exist. There is intense competition in education, and one alternative is a “stackable” degree. Udacity calls these a Nanodegree and Edx calls them MicroMasters. The general concept is that they are highly condensed and focused on learning environments that prove you know a specific domain: cloud computing, data science, machine learning, or more.

Another alternative is the extensive work experience. If you have enough relevant experience, this is a powerful signal to future employers that they should hire you.

Threat Two: Portfolio #

A portfolio is perhaps the most direct method of proving yourself hireable. If you hire a painter, a carpenter, or a mechanic, you ask for a collection of their work. This portfolio helps decide on whether to use them. The same applies to people in the tech industry.

Threat Three: Certifications #

The pace of change in the tech industry is as breathtaking as it is consistent. One way to signal to an employer and yourself that you know a technology is to get a certification. Some of the most popular and lucrative certifications involve cloud computing. Of these certifications, perhaps the AWS Certified Solutions Architect is the most substantial value.

Build a real portfolio project and share it #

There are three core pillars that I use to gauge an open-source project and its maintainers. These are (in order of importance): documentation, user experience (how easy it is to interact with the project), and its test suite. When I produce production-grade software at work, I use these same pillars to deliver useful, robust applications. Documentation is so necessary to me that I’ve gone as far as writing the documentation before doing any software development. It doesn’t matter if you are just starting out or if you are a seasoned developer already: document your code, make sure it is easy to install and use, and have a healthy amount of tests.

When I interview candidates, if they have an account on Github or any other coding repository platform, I go there to look for these three things in the projects they author. A lot of the time, there isn’t an example to look at, which makes the hiring process complicated for me, because I need to come up with other alternatives to see how the candidate develops projects. Having something out there, regardless of how popular it is, is crucial, and you should think about having at least one pet project to give some attention. Having a plan is vital because you will get ahead of most people who are too worried about displaying their skills publicly. I have over a decade of Python experience, and the oldest project I have on Github is a templating engine that is quite terrible. There was absolutely no reason at all to create a new templating engine, but I did - and it is entirely wrong!

It doesn’t matter. I’m fully aware that the wheel got reinvented with my templating engine, but it gave me lots in return. I improved my skills dealing with text file processing and handling arbitrary inputs (files), became used to writing more tests, and verifying the code I was dealing with along with some documentation.

There is nothing that should prevent you from trying other languages as well. My most popular project on Github is a Vim plugin for Pytest. I wrote it in a language called VimScript, which is hard and nothing like Python. Do you think a VimScript language project is relevant at all? It is! Because as a professional software engineer, I can say that I solve problems, and I use the best solutions to these problems. Python for Vim plugins is not a good solution, it is actually going to create more problems than it solves. I acknowledge that VimScript is very hard to deal with as a language, but I use this story when I can as an example of perseverance and knowledge-craving purpose.

I’ve described briefly the three pillars of a good (publicly available) project, let’s dive into a bit more detail on each of those.

Documentation #

I like Sphinx, but it can be intimidating to get started with it. You don’t need to use Sphinx or any other tool for that purpose. Concentrate on writing proper documentation that explains what the project (or portion of its code) is trying to accomplish. Plain text files as literary works, or if you are feeling fancy, you can try using a flavored markup language like Markdown (Github supports it) that has formatting for text as well as code, much like this book.

“Go and write some good documentation” is not very good advice without substance. I tend to go through a few items that can then get expanded, which you can also follow to have some guidance. First, start with a good description of what the project’s intent is. The first line in my Pytest plugin for Vim it says: A simple way of running your tests (with py.test) from within VIM.. To the point, no overly verbose, you can’t possibly take any words away from that first sentence. That is your target: explain, in as few words as possible what the project’s intentions are - what is it trying to solve. It doesn’t need to be a single sentence; a small paragraph can do as well.

Next, describe its most important aspects, or whatever the most common pieces are to be useful. Re-using the Vim plugin as an example, these are: showing a session with test errors and showing failures from running tests. Then, some description on how to install it, and you are on your way to a great start. Sometimes users like having the install instructions very close to the top (beginning). There is room to shuffle things around.

Finally, go into details of all the other pieces of functionality, one by one, grouped by their interactions. For example, in a command-line tool that uses configuration files, one interaction group could be “Tool configuration”, another would be “Command arguments and options”. Those can follow a similar pattern as the project:

First few lines should accurately describe what it is, what it is trying to solve.
Next, it should describe the feature, flag, option - the core of the functionality.
If possible, examples and combinations of those examples should follow.

These are not rules; they are guidance. If something like a --verbose flag is almost self-explanatory, it doesn’t make sense to have four different examples.

Finally, pay attention to users (even yourself). When something is not quite right, create an issue so that you can improve the docs. I’ve had numerous times where I came back to one of my projects and didn’t quite understand the docs that I’d written myself. That is a bug that needs fixing. If a user asks for something that you know the answer to, and you can’t point to documentation that explains it: that is also a bug! Open an issue, assign it to yourself, and fix it.

User experience #

As you improve your skills with repeated usage of tooling, you will realize that some tools are just better than others. This situation is not only valid for the technology, of course, but it is also true for almost anything. One of the most mesmerizing and amazing little handy tools I have for electrical work at the house is a Klein Katapult Wire Stripper. It does three things in one movement: it will hold the wire tight, then it will cut the plastic encasing the wire, and finally, it will pull out the plastic leaving the wire ready for connection. It is entirely mechanical, and it has all these moving parts that get active as you press the tool. It is no longer in production; it seems, but it doesn’t matter. I love it. When I can’t find it, or I’m being lazy and decide just to try to peel the plastic away with anything else, I cringe. Internally, I’m boiling.

It is the same experience I have with command-line tools and other things like Python. There are lots of things that I love about Python and some others that make me cranky. I’ll let you discover what makes you happy and won’t spoil the party, but there are some general ideas that I believe are important to describe.

Installation #

Most Python libraries out there will be easy to install and use right away. Sometimes though, libraries and tooling will need other system dependencies. What happens if you are building a web service that requires a database like PostgreSQL version 9.1 installed to work? How do I configure the service to connect it? Things can get tricky. We live in times where all items can be containers, and that solves many things; perhaps the service could be a container? Sure! You need to solve the problem of how do I run this container now. Here are a few things to think about:

Doesn’t matter how easy it is to install it, write it down, make it part of the docs
If requiring system dependencies, make sure those work. Fail gracefully if the dependencies don’t' work.
Non-Python installation methods (like using containers) needs testing. A user that tries to install and fails is probably not coming back.

I want to emphasize on the last bullet point: a user that has a lousy time installing, or fails to fit your project is either a cranky user or one that will not come back. Make it impressive and straightforward.

Errors #

A lot of libraries either eat up all the errors and generalize the output or simply spill out their guts as gigantic tracebacks. The sweet spot is in the middle. I used to maintain a configuration tool called ceph-deploy, which had to connect over the network to other systems and perform installation and configuration of various components. When the tool failed, it wouldn’t say what or where all you would see is an enormous traceback from the library used to establish the network connection. Can you imagine solving issues reported by users? It was a nightmare. If the installation failed, for example, if the tool were trying to run sudo yum install libssl because the package is really libssl-dev on CentOS and not libssl you wouldn’t know. All you would see is a traceback. This situation is a nightmare. After weeks of hacking in the tool, I was able to produce meaningful output, especially on errors.

Errors might even be what makes your project great. Another small project I wrote called notario (a dictionary schema validator) concentrated in producing human-readable error messages. Here is a quick example from its documentation:

>>> data = {'foo': 1}
>>> schema = ('foo', 'bar')
>>> validate(data, schema)
Traceback (most recent call last):
...
Invalid: -> foo -> 1  did not match bar

Tests #

This book has lots of content about testing; make sure you test what you produce - always. It doesn’t matter how tiny the project is, it will save your sanity when you come back three weeks later to add a new feature or fix a bug, and you have your tests helping you out to ensure everything is working great. A project out in the open that has lots of tests tells me that the author (or authors) have put extra care ensuring that everything is as robust as possible and that they will continue to produce great software.

A while ago, I worked at a place that used a small project as a test for their interviews. You had to write a Tic-Tac-Toe program, and there was only a single constraint: the program could never lose. It was entirely up to you how to craft this program and make it ready to submit for your interview. When it was my turn to do it, I had over a hundred tests for the small project, a good chunk of documentation, and I made sure it was installable. When I arrive at the panel interview, where others could ask me about my project, I didn’t receive a single question about it. I asked the hiring manager if there was any problem with my project submission to which she replied: “You should feel proud of yourself, it was so good, with so many tests, that nobody thought to ask anything about it”.

You can bet I would grill candidates about their lack of tests (or inadequate testing) when it was my turn. Tests tell me how much the author cares. If you are reading this book, and you’ve made it this far is because you care and you want to improve. Show it off with excellent user experience, documentation, and tests.