Pay It Forward

Hitting the ground running

Don’t worry about “acing the coding interview”, focus on producing quality code instead

So: you’re a CS program or bootcamp graduate, and you’re wondering what you should be focusing on to get interviewed. A lot of people recommend that you focus on coding skills: data structures, algorithms, LeetCode problems, etc. The usual reason given for this is that programming interviews tend to focus on these sorts of skills.

Personally, I think coding interviews are as a rule conducted so poorly as to have practically negative value, but that’s a post for another time. That said, the coding interview happens only after you’ve gotten an interview. How can you show yourself to be someone that should be interviewed?

Given the outsized importance many budding engineers assign to coding interviews, showing off coding skills in your resume or your GitHub repositories would seem to be the natural thing to do. Sadly (or maybe not so sadly!), precious little of your data structures knowledge or LeetCode mojo will be called upon in any software engineering job you get. Most of the time you will be working with other engineers on not-especially-difficult coding tasks using the tools of the trade. That is to say, learning to code is only the beginning of what you need to learn to be an effective software engineer.

My own humble opinion is that, from the perspective of a prospective interviewer, demonstrating some facility with how working engineers get their work done will make a more significant impression than your awesome hack3r skillz. That is, you’re much better off focusing on how to create production-quality code in a collaborative environment.

What does this mean? Well, production-quality code is code that (1) fully meets the requirements for the task, (2) has been sufficiently well tested via accompanying automated tests, and (3) meets the team’s coding and formatting standards. And a collaborative environment is a team of engineers and relevant engineering stakeholders, each of whom you’ll need to be work with.

Learn to use the tools of the trade

How do you demonstrate this sort of facility, without already having had a software engineering job? The closest thing you can get to this is to demonstrate your facility with the tools engineers use to collaborate to produce production-quality code. These tools include, but are not limited to:

  • source control management (git, almost always)
  • code formatters and linters (Go has gofmt, Python has pylint, flake and ruff)
  • containerization software (Docker)
  • IDEs (e.g., Visual Studio Code)
  • terminal shell languages (e.g., bash)
  • unit testing frameworks (virtually every language has at least one)
  • deployment frameworks (e.g., GitHub Actions, GitLab CICD)

There are many different ways of combining these tools to get code into a production environment, but the following pattern is common:

  1. A shell script runs formatting and linting tools against code that’s been checked into a source code repository.
  2. Another script runs unit tests against that code.
  3. Finally, some automated framework is invoked to push the code into an application environment, often using Docker images.

To demonstrate this facitlity, then, you can create repositories that make use of these tools. For example, you can create a Python or Ruby web service, complete with automated unit tests, that runs in a Docker container and is deployed via GitHub Action to AWS or Google Cloud. The repository uses a simple branching strategy (I’ll cover git branching strategies in another post), and there are straightforward conditions preventing deployment when the code isn’t properly formatted, or has linting errors, or unit test failures. All of this is fully documented in the repository’s README.

Furthermore, anyone checking out the repository should be able to run all the (passing) tests and get a local version of the service running on their local machine within 15 minutes; 5 minutes would be ideal.

Speaking for myself, if someone wanting to work on my team had repositories like that, I would have no worries about their ability to contribute on my team.

A simple homework assignment

Request to shadow two or three people you know who are working at places you might want to work. When shadowing, pay attention to:

  • what IDE they use
  • what tests they write, and how they write them
  • how their code get deployed
  • what a typical code-review session is like
  • what kinds of developer tooling do they use, e.g., Docker, Github Actions, Terraform

Basically, you want to see how they get their work done. After shadowing several people at different shops, look for commonalities. These commonalities will give you starting points for what to focus on in your studies.