This Month We Learned gives us an opportunity to share short stories about what we’ve learned and to highlight the ways we’ve grown and learned both in our jobs and outside of them. November was a pretty crazy month! But we still found time to learn about people-first hiring and onboarding and using nix-shell for consistent development environments.

• 

• 

People-first hiring and onboarding

Brigid Woolery

This month I learned how to successfully hire and onboard new employees (by being hired and onboarded!). As I’m sure you can imagine (or may be experiencing yourself), looking for a new job is incredibly stressful. Now add a pandemic on top of that and often the job search can feel pretty hopeless. You spend hours on applications, tailoring each resume, and patiently (or not so patiently) waiting for a response. Often it can feel like you just threw your application into the void. You get nothing. No response. No followup. As someone who just went through that hiring cycle and then was hired for a people operations role, I have the unique perspective of seeing this play out from both sides of the hiring process.

From my first interaction with Azavea, I knew I was dealing with a company that values its job candidates. The flow of communication was constant. I was reassured that all my efforts were not in vain and that people were taking the time to review and consider me for the role. As my application moved through the pipeline I was kept up to date by the hiring manager. After my first interview, they even reached out to give me feedback. Whether I was hired by Azavea or not, I was leaving this process having strengthened my skills as a job candidate, with an experience that made me feel valued and important.

The onboarding process was similar with tasks that were intentional and purposeful. From day one there was constant learning and support. I felt encouraged every step of the way and knew exactly who to go to with questions.

I think the key element that differentiates a successful hiring and onboarding program from one that is not, is how much a company values people. The hiring company needs to recognize that there are living, breathing humans on the other side of the hiring experience — people with lives and responsibilities, who are working hard to apply to work with them. It is critical to respect these people and the time and energy they put into their job search.

Fortunately, it seems that more and more companies are recognizing the need for change in this field. I feel fortunate to have landed at one that is at the forefront of making this happen.

nix-shell for development environments

James Santucci

In November I started a small side project using Haskell to build a server for choosing topics to discuss in un-conference-like settings. However, I had a problem — my Haskell Language Server installation kept randomly breaking. This kind of instability in my development environment was a serious drag, so I went looking for a way to fix it.

A while ago I did an R&D project about using nix for setting up development environments. Frequently at Azavea, that means docker-compose for isolation of different services, often inside virtual machines to keep docker isolated across projects. I wanted to replicate that exactly, and it went really poorly, so I abandoned it.

However, recently two things caused me to reconsider nix — Gabriel Volpe published a Scala project template using nix, and Susan Potter published a template for a serverless Express app using PureScript. Both examples were oriented around a shell.nix file, which was a different strategy from my floundering a few years ago.

Since I was working on a Haskell project, I wanted to define two things: my set of Haskell dependencies and my set of uh “general” dependencies.

My description of my Haskell dependencies looked like this:

# 1
with import <nixpkgs> {};

# 2
pkgs.haskellPackages.ghcWithPackages (ps: with ps; [
        # actual project dependencies
        aeson bytestring postgresql-simple resource-pool servant-server time uuid wai warp
        # build / environment-required tools
        haddock ghcide cabal-plan
])

The first statement says “import commonly used packages,” which you can think of as like the nix standard library. The second statement says that this expression should return a ghc environment with a collection of packages available in it. Importantly, this includes my project dependencies like servant, postgresql-simple, and aeson, and my development environment dependencies, like ghcide and cabal-plan.

This ghc.nix file is an expression, which can be imported and used elsewhere, so in my shell.nix (a special file automatically picked up by the nix-shell command), I can import it into the build like this:

with import <nixpkgs> {};

{ pkgs ? import <nixpkgs> {} }:
  let
    ghc = import ./ghc.nix; # <- re-use the expression from ghc.nix
  in
    pkgs.mkShell {
      buildInputs = [ ghc
                      ...
                    ];
}

With nix-shell, I expect to be able to manage more complex development environments more consistently. My Haskell Language Server installation hasn’t broken once since I switched.