RSS Feed: https://ericrallen.dev/

Advent of Rust: Part II

Wed, 07 Dec 2022 23:31:14 GMT

Last Updated: 2022-12-08

In Part 2 of my Advent of Rust series we'll explore the puzzles 6 through 10 of 2022's Advent of Code challenge.

GitHub Repository: https://github.com/ericrallen/advent-of-code/blob/main/2022/advent/src/days/day_six.rs

Challenges
Getting Started
Wrapping Up

Challenges

Day Six

Note: Each challenge has a Real Talk section where I share some Takeaways about what I learned during that challenge and how it contributed to my overall goal of learning Rust, various Notes I wrote down while going through the challenge, all of the Searches I made while working through the challenge, and what my key Next Steps were so you can see how I broke down trying to learn these concepts by doing.

Getting Started

After successfully solving days 1 through 5, I'm feeling okay about basic syntax and concepts, though I'm still trying to fully grok ownership and lifetimes, and want to address one thing things that was just weird before I started solving puzzles:

I implemented a test feature instead of relying on cargos built-in test runner

I'll go back and convert the previous solutions to use the built-in testing functionality at some point, but my goal is to use it for every solution going forward. It helped that Day 6 was the first to introduce multiple example inputs, which didn't fit into the pattern I was using previously.

Conclusions

Below are some conclusions I've come to during this stage of my journey (along with the date that I came to that conclusion just in case my thoughts change over time).

2022-12-07: Rust is still pretty neat. I might actually like it.

Day Six

Day Six is a deceptively easy challenge where we need to identify a sequence of unique characters in a longer string.

Like some more complex puzzles might do later on, we are given several examples with their solutions, so the first thing we should do is create a test for each input and then we can be reasonably sure we've got things right when all of our tests pass.

Real Talk

We're given several examples inputs:

mjqjpqmgbljsphdztnvjfqwrcgsmlb

bvwbjplbgvbhsrlpgdmjqwftvncz

nppdvjthqldpwncqszvftbrmjlhg

nznrnfrfntjfmvfwmzdfjlvtqnbhcprsg

zcfzfwzzqfrljwzlrfnpqdbhtmscgvjw

And asked to find the index of the last character in a sequence of 4 unique characters.

Breaking this one down into some logical steps:

Check to see if the first 4 characters are unique
Iterate through each character after the first one and see if it plus the next 3 characters are unique

Part Two introduces another Advent of Code trope: Adjusting the count of items you need to consider from your input. In this case we're going to start looking for a sequence with 14 unique characters instead of only 4.

Note: Another, potentially better approach might maintain a single stack of N characters and just keep removing the first character and appending the next character in the larger sequence.

My Solution

The first thing we'll need is a way to check if a given set of characters is unique. Rust's .dedup() method removes consecutive duplicate items in a Vector, so we can .collect() our string's characters into a Vector and then .sort() and .dedup() them.

fn check_for_unique_sequence(sequence: &str, size: usize) -> bool {
  let mut sequence_array: Vec<char> = sequence.chars().collect();

  // `.dedup()` only removes consecutive duplicates
  // so it needs a sorted Vector for our use case
  sequence_array.sort();
  sequence_array.dedup();

  sequence_array.len() == size
}

Note: It probably would have been more efficient to just compare the size of the deduplicated sequence to the size of the original sequence instead of passing the size in, too.

This utility method is technically extraneous, but it made the code feel a bit cleaner without the Range (start..end) needing to include the math for calculating the correct indices. It also gave me a chance to play around with returning and working more with Option types.

fn get_sequence(stream: &String, start: usize, end: usize) -> Option<&str> {
  // this could have just been a regular `.get()` call in the code below
  // but having the index math in the Range was hard to read
  stream.get(start..end)
}

Finally, we need to actually check our string for a unique sequence of some defined length.

Note: Initially the length was hardcoded to a specific constant, but it was easy to just make the length a function argument and pass in the relevant constant for each part of the puzzle.

fn find_end_of_sequence(stream: &String, length: usize) -> usize {
  // check the first N characters before we start iterating
  let first_sequence = get_sequence(stream, 0, length).unwrap();

  if check_for_unique_sequence(first_sequence, length) {
    length
  } else {
    // we'll update this once we find the right ending index
    // TODO: find a pattern that can make this `panic!()` if we
    // never find a unique sequence
    let mut sequence_end_index: usize = 0;

    for (index, _) in stream.chars().enumerate() {
      // skip first character since we already checked the first sequence
      if index > 0 {
        // get the next sequence to check
        let test_sequence = get_sequence(stream, index, index + length).unwrap();

        if check_for_unique_sequence(test_sequence, length) {
          sequence_end_index = index + length;

          break;
        }
      }
    }

    sequence_end_index
  }
}

Now all we have to do is call find_end_of_sequence() with our input string and the desired length of the unique sequence.

View on GitHub

Testing

Adding unit tests to the solution was really easy, although I'm still not sure if I put them in the right place. I think I'm a fan of the simplicity of Rust's built-in testing.

#[cfg(test)]
mod test {
  use crate::{read_input, read_solution, days};

  #[test]
  fn day_six_part_one() {
    // I put the first example for day 6 part 1 into a file
    // like I have used for testing the previous puzzles
    let input = read_input("6", true);
    let output = read_solution("6", "1");

    let result = days::day_six::part_one(input);

    assert_eq!(result, output)
  }

  #[test]
  fn day_six_part_one_extra() {
    // the other examples inputs and solutions
    let inputs = [
      "bvwbjplbgvbhsrlpgdmjqwftvncz",
      "nppdvjthqldpwncqszvftbrmjlhg",
      "nznrnfrfntjfmvfwmzdfjlvtqnbhcprsg",
      "zcfzfwzzqfrljwzlrfnpqdbhtmscgvjw"
    ];

    let outputs = ["5", "6", "10", "11"];

    for (index, input) in inputs.iter().enumerate() {
      let result = days::day_six::part_one(input.to_string());

      assert_eq!(result, outputs[index]);
    }
  }

  #[test]
  fn day_six_part_two() {
    let inputs = [
      "mjqjpqmgbljsphdztnvjfqwrcgsmlb",
      "bvwbjplbgvbhsrlpgdmjqwftvncz",
      "nppdvjthqldpwncqszvftbrmjlhg",
      "nznrnfrfntjfmvfwmzdfjlvtqnbhcprsg",
      "zcfzfwzzqfrljwzlrfnpqdbhtmscgvjw"
    ];

    let outputs = ["19", "23", "23", "29", "26"];

    for (index, input) in inputs.iter().enumerate() {
      let result = days::day_six::part_two(input.to_string());

      assert_eq!(result, outputs[index]);
    }
  }
}

Takeaways

This is the fist challenge where I really felt like I understood what I was doing and wrote code that I didn't feel bad about. It was really helpful to have another slightly easier puzzle as a way to try putting together everything I've learned about the language so far.

I'm also glad I took the time to abstract some of it so that I could easily reuse everything in Part Two by just adding a second parameter that would accept the desired length of the sequence we wanted to check.

Notes

I bet Day 7 is going to be much harder

Searches

Here are the actual search strings I used, taken directly from my browser's history.

rust testing best practices

rust break out of for loop

Next Steps

Should eventually figure out if having the tests live inside of the .rs file that they are testing is the best approach or if there is a better spot for them
Update previous day's solutions to use unit tests instead of test feature

Back to List of Challenges

Wrapping Up

Coming Soon.

Advent of Rust: Part I

Wed, 07 Dec 2022 23:17:04 GMT

Last Updated: 2022-12-07

In Part 1 of my Advent of Rust series we'll explore the first 5 puzzles for 2022's Advent of Code challenge.

Challenges
Getting Started
Wrapping Up

Getting Started

Anyone who has dealt with Python, Node, or Ruby versions knows that you probably shouldn't just install whatever language you wnat to work with without first researching the ecosystem and figuring out how people really manage versions, packages, etc. You can just install the default toolchain and go for it, but you'll eventually regret it.

As I was searching for the right package to install from Homebrew for this, I learned the first thing that I love about Rust.

Rust's default, recommended installation method, rustup handles this for you so that you don't need to figure out whether you should be using nvm or volta or pyenv or poetry.

This instantly made the languages I have been using for years feel very outdated.

Conclusions

Below are some conclusions I've come to during this stage of my journey (along with the date that I came to that conclusion just in case my thoughts change over time).

2022-12-02: Rust is pretty neat. I might actually like it.
2022-12-04: Fighting to get the right types (like &str, String, char, &&str, etc.) more than I am actually programming. Hoping this is just like the initial hurdles I encountered switching from JavaScript to TypeScript.
2022-12-05: Like any language, it seems like it is not hard to write mediocre, naive implementations in Rust.
2022-12-06: Feeling a bit more comfortable.
2022-12-07: What a roller coaster of emotion.

Day One

Now that we've got rust up and running, it's time to see what @ericwastl has in store for us with Advent of Code this year.

Luckily Day One eases us into things with iterating through some collections of numbers and adding them together.

As is tradition, I first needed to over-engineer a way to test the example inputs against the example solutions and run code for the various parts of each day.

Before we can solve Advent of Code, we must first invent an Advent of Code helper.

Note: I first actually needed to figure out how to get the rust-analyzer VSCode Extension to cooperate with the subdirectory I used for my crate.

Another Note: I'll also probably streamline the input gathering at some point so that my inputs are pulled down from the Advent of Code site automatically and cached, but we need to walk before we can run and we're taking baby steps here.

Real Talk

We're given an example input:

And told that each collection of numbers represents some collection and we want to sum those collections and find the biggest one.

Breaking this problem down into logical steps (assuming we've already solved the problem of getting the input into our program):

split the input on double line breaks to get each collection
iterate through the collections
1. split them on line breaks to get each value
iterate through the values
1. parse them as numbers
2. add them together
3. return the sum
find the maximum value among the totals for each collection

Part Two sees us taking the same logic, but sorting the collection and adding the top 3 totals together.

Takeaways

What's great about a simple challenge like this one for learning a new language is that it lets you play around with concepts that you are likely already familiar with and just sort of familiarize yourself with the syntax and how you execute programs in this new language.

Things may not have been perfect, but this felt like a very successful start with the language.

Notes

Rust is harder than I thought

I guess I do need to read about this whole borrowed vs. owned thing

Woah, this IDE integration with the rust-analyzer is amazing

I'm so glad I fell in love with TypeScript before I tried to pick up Rust

Why can't I join these numbers into a string? I guess I'll just dump the whole array.

I need to read the instructions more carefully.

Searches

Here are the actual search strings I used, taken directly from my browser's history.

rust read file input

rust concatenate strings with variables

rust analyzer failed to discover workspace

rust import from another file

rust string vs &string

rust match bindings cannot shadow statics

rust default value for argument

rust split string

rust sum of array

rust number types

rust apply function to each item in vector

rust sort array

cannot return value referencing temporary value

rust sort descending

You can pretty much reconstruct how I arrived at my solution for Day One by following that trail of search strings.

Next Steps

I still had lots of things to figure out, like:

How to implement verbose debugging messages without needing to manually flip a Boolean in the code
How to pass named parameters to the executable
How to actually test the output of the executable against the example solution when providing the example input

Back to List of Challenges

Day Two

Day Two has us tackling a Rock, Paper, Scissors game with some complex scoring rules.

Before I dug into the problem, I really wanted to tackle those Next Steps from Day One.

This is when I learned about the second thing I love about Rust: Features.

Having a built-in way to specify features for your program and a built-in way to have your code behave differently depending on the state of those features is awesome.

There are certainly ways to achieve this in every language, but this might be the simplest and easiest to implement that I've encountered.

Real Talk

Once again, we're given an example input:

A Y
B X
C Z

And told that each line represents a round of Rock, Paper, Scissors and that we need to model the outcomes and provide the relevant total score based on the game's outcome and our chosen weapon.

Breaking this problem down into logical steps:

iterate through each line
1. get the other player's choice (first column)
2. get our choice (second column) and its associated point value
3. execute the game's rules to decide who won
4. get the value of the round for us (based on win, loss, or draw)
5. add the value of the outcome and the value of our choice
6. return that sum
add up all the individual round sums to get our final score

Day 2's puzzle is the first to introduce the Advent of Code trope of Part Two changing how you interpret the input, and asks us to figure out what choice we should make in each round to achieve a desired outcome and then provide the final total score based on those choices.

It requires us to change things a little bit, but most of the logic is still there.

Takeaways

This one was also great to start groking the ins and outs of Rust because it takes a game we're likely already familiar with, adjusts it minimally, and makes us think about how to model those rules programmatically.

There are many approaches to the problem that give us a chance to explore control flow and logic in our chosen language while maybe also exploring some of its more complex data structures

Notes

Rock, paper, scissors is actually a little harder than I thought; the point system here makes it a little more complicated, too

I know there has to be a better way than all these ifs, but I guess I'll learn that later

I still have no idea when I'm supposed to use & and when I'm not; I'm really glad this IDE integration exists

Searches

Here are the actual search strings I used, taken directly from my browser's history.

rust println! in debug only

rust debug!

rust how to get feature

rust trim string

rust enum

rust get value from enum

rust import macro from another file

rust match multiple statements

rust remove empty elements from vector

Next Steps

Okay, it's time to actually dig into this borrowed vs owned thing
I need to take some time to learn about the differences with structs and enums
Am I overusing .collect() and .iter()? Do I need them as often as I have been using them? When should I chain methods and when should I not?

Back to List of Challenges

Day Three

Day Three has us comparing parts of a string and looking for duplicates.

This time I decided to try to make myself to explore the available functions in my IDE's Intellisense suggestions before searching for a solution to something. I think it worked out okay, and as a result you'll see that there are a lot less search strings focused on a specific task - and a lot more focused on a specifc error message I received while working in this way.

Real Talk

Example Input:

vJrwpWtwJgWrhcsFMMfFFhFp
jqHRNqRjqzjGDLGLrsFMfFZSrLrFZsSL
PmmdzqPrVvPwwTWBwg
wMqvLMZHhHMvwLHjbvcjnnSBnvTQFn
ttgJtRGJQctTZtZT
CrZsJsPPZsGzwwsLwLmpwMDw

We're supposed to split these strings in half and find the character that appears in both halves, then convert that character to a numerical value and add them all together.

Takeaways

This one sort of reinforces what we've already started learning and gives us a chance to explore those concepts a little further.

So far, using Advent of Code to learn a new programming language seems like a good idea, but I worry when the difficulty really increases it will result in a wall of frustration.

Notes

Okay, we're doing another reduce/sum of an Array; hopefully I get the hang of the language before we get into more complex structures

That Rust Demystified video sort of actually helped me understand the & and I kind of get some of the lifecycle stuff now, too - I definitely need to watch it a couple more times over the rest of the month to come back and pick up more

I cannot figure out why it seems so hard to map through stuff in Rust; I must be doing something really wrong or doing things in a way that isn't idiomatic

Searches

You may notice that many of the search strings are mostly error messages that are getting a little more complex - not sure what the takeaway from that is just yet.

a value of type `&str` cannot be built from an iterator over elements of type `&str`

consider introducing a named lifetime parameter: `<'a>`, `'a `, `'a `, `'a `, `'a `

this function's return type contains a borrowed value, but the signature does not say which one of `pockets`'s 3 lifetimes it is borrowed from

a value of type `Vec<&str>` cannot be built from an iterator over elements of type `Vec<&str>`

the trait `FromIterator<T>` is implemented for `Vec<T>`

rust vector remove duplicates

rust usize to i32

rust expected slice `[&str]` found tuple `(_, _, _)`

refutable pattern in function argument

cannot return value referencing local variable

Next Steps

Figure out if Vectors are even the right approach for this kind of thing; I think I'm doing it wrong
Revisit the ownership thing again - it still hasn't sunk in yet
Look into lifetimes more, I sort of understand why I needed to add a named lifetime (like <'a>) but it's still kind of unclear, too

Back to List of Challenges

Day Four

Day Four has us converting some strings into number ranges and seeing if they overlap completely.

I started off the day by trying to clean up my very naive approach to the two parts of a puzzle per day pattern and think about a more Object-oriented approach to setting up each day's solution, but ended up deciding I didn't quite grok enough of the language's idioms yet and decided to keep pushing forward with the current status quo for now.

I also wanted to switch from the cargo run --features test approach that I took and use the built-in #[cfg(test)] functionality so that I can just run cargo test, but will tackle that another day.

Real Talk

Example Input:

2-4,6-8
2-3,4-5
5-7,7-9
2-8,3-7
6-6,4-6
2-6,4-8

Once again we're doing a lot of splitting of strings here. We could probably do something with a Regular Expression if we wanted to, but I'm not ready to dig into if/how RegEx is handled in Rust just yet, so we'll probably naively:

Split on "\n"
Split on ","
Split on "-"
Create a range for each number sequence
Check both ranges to see if either fully contains the other

The second part introduces another common Advent of Code puzzle trope: Switching between a complete and partial match. So we just need to flip our .all() to a .any() and we're good to go.

Takeaways

The first part of this one gave me a chance to try to apply what I have learned so far and the second part gave me an opportunity to refactor and make my code more reusable, but I was lazy and just duplicated it instead of trying to follow the Don't Repeat Yourself (DRY) principle and clean things up.

Notes

I was able to do this all without too much trouble, but the code is definitely not what I would like it to be.

I actually felt like I kind of knew what I was doing this time. That might be some progress.

Searches

rust struct

// still haven't mentally accepted this one, I guess
rust default function argument value

rust check if two vectors contain same elements

rust create array from range

Next Steps

Should really be using cargo test instead of the cargo run --features test approach
Would love to use more of the language's features (structs, enums, traits, etc.)
Need to learn more about handling Option<T> types and best practices for when and how to unwrap() them idiomatically

Back to List of Challenges

Day Five

Well, that escalated quickly. Day Five introduces another Advent of Code trope: data visualization.

I started off thinking about making one of those fancy data viz solutions you see on the subreddit, but decided that I should probably just catch up to the current day first instead.

Real Talk

Example Input:

    [D]    
[N] [C]    
[Z] [M] [P]
 1   2   3 

move 1 from 2 to 1
move 3 from 1 to 3
move 2 from 2 to 1
move 1 from 1 to 2

This one is a bit more challenging because we have to parse the input in multiple different ways. We need to understand the total number of stacks we are dealing with and which item is in which stack while also parsing the instructions for moving items from one stack to another.

Breaking this down we're going to want to:

Split on "\n\n" to separate the stack visualization from the instructions
Pop the stack numbers from the stack visualization so we know how many stacks we need to keep track of
Parse the crates in each stack
Parse each instruction and manipulate our stacks

Note: One thing I've learned over the years with Advent of Code is that you can simplify and reduce your chance of bugs by just inserting an empty item as the first element in your Arrays when you are dealing with things indexed at 1 like these stacks of crates. Rather than having to constantly convert indices, you can just go with what's written and then filter out the empty item at the end if necessary.

And part two has us pulling multiple containers off the stack instead of doing them one by one, which is similar to the Advent of Code trope from Day Four, except this one has to do with moving from processing a stack as individual items to processing it as groups of items. Luckily most of the logic is still the same.

Takeaways

The most challenging part of this one was actually parsing the initial stack state correctly. It also introduced another Advent of Code trope: the reduced example case doesn't have edge cases that your real input might have (like multiple empty spots in a row so it isn't quite as easy to make sure you put the right crate on top of the right stack).

Notes

This one ramped up the complexity a good bit; there usually seems to be a bit of a hockey stick in terms of the difficulty scaling - and that's often reflected in the decreasing number of stars awarded.

Let myself get too behind by overthinking and messing this one up at first

Searches

// I ended up not using this one
rust update output in console

// stuff I actually used
rust regular expressions

rust for in get index

rust iterate n times

rust remove first item from array

rust can't compare `&str` with `str`

rust borrowed value does not live long enough

rust compar char to str

Next Steps

Should really switch to using cargo test instead of the cargo run --features test approach I ended up with
Get better at making reusable functions for this stuff (I've been avoiding it due to some lifetime and ownership issues) so that these kind of day two slight tweaks can just be a new function or parameter to an existing function instead of repeating so much code

Back to List of Challenges

Wrapping Up

Five days down; twenty to go.

I feel like I've already learned a lot and am starting to feel more comfortable and less frustrated with the language, but I know there's a long way to go before I'll be writing idiomatic Rust, much less efficient Rust.

I've always tried to follow the "Make it work. Make it Right. Make it Fast." philosophy, and feel like I'm definitely still in the Make it work. phase and probably won't make it to the Make it fast. phase during this exercise, but that's okay.

Advent of Rust

Fri, 02 Dec 2022 20:26:39 GMT

Last Updated: 2022-12-07

Rust always sounded pretty cool, but then I always heard you had to read this book to actually learn it.

I like reading, but I don't learn that way. I'm an experiential learner and I really like to just get hands on with something when I'm first trying to understand it.

So, I decided to just dive in and tackle 2022's Advent of Code using Rust.

After I grasp the basics of something and I can decide if I'm interested in pursuing it further, I circle back to research and reading to get a better understanding.

This series of posts will document my trials, tribulations, successes, failures, and "Eureka!" moments in hopes that you may gain some insight into this journey if you decide to follow a similar path.

The goal here is to stay in the Zone of Proximal Development long enough to grok the language well enough to start digging into slightly more advanced topics and reinforce all of the learning with spaced repetition (daily coding challenges) and increasing complexity.

Disclaimer: There is a chance that I will not make it to Day 25 Part 2 - I have never completed a full Advent of Code calendar in the past.

Due to the ongoing nature of this post's updates, here are some quick links to relevant top-level sections in case you want to skip straight to a specific day.

In This Post

Series
Getting Started
Resources
Conclusion

Series

This post serves as a hub with links to the rest of the posts in the series, some general information about the journey, my first impressions with Rust, and links to some resources I've found super helpful as a wannabe rustacean.

Posts:

Part I: Days 1-5
Part II: Days 6-10
Part III: Days 11-15: Coming Soon.
Part IV: Days 16-20: Coming Soon.
Part V: Days 21-25: Coming Soon.

Background

For some context about me to help you understand how I'm approaching this and if this approach might work for you, too:

I'm a developer (currently working as a Developer Advocate) with just over a decade of professional experience and I've been programming as a hobby for a little over 20 years.
In the past I've played around with all sorts of languages (roughly in order: HTML, CSS, Visual Basic, Java, ActionScript, PHP, Ruby, Objective-C, Swift, JavaScript, Bash, TypeScript, Solidity, and Python), but my primary focus has been JavaScript/Typescript.
I've liked a few things about a lot of languages, but haven't found one that resonates with me like TypeScript has.
I don't remember much about most of the languages I've explored in the past because I always ended up returning to something more comfortable.

Much like suddenly switching from QWERTY to Colemark or VS Code to Vim, I've rarely felt that the investment in learning an entirely new language, toolchain, and ecosystem is worth the time and effort.

So, why am I interested in learning Rust then? It seems to be the next thing for Web Assembly and has an interesting programming model that I think will really challenge my understanding of programming and programming ability.

So, why should you care? You probably shouldn't, but if you're interested in how to use coding challenges as a springboard for learning, getting some insight into how an experienced developer tackles learning a new language, or just want to see that a senior developer also searches for a lot of the same things that a junior developer does then you might find this post interesting.

GitHub Repository

Learning in the open only counts if you actually share it, right?

Repo: https://github.com/ericrallen/advent-of-code/tree/main/2022

Getting Started

As I was searching for the right package to install from Homebrew for this, I learned the first thing that I love about Rust.

Rust's default, recommended installation method, rustup handles this for you so that you don't need to figure out whether you should be using nvm or volta or pyenv or poetry.

This instantly made the languages I have been using for years feel very outdated.

Resources

Here are some resources that I've found particularly enlightening throughout this journey (in roughly the order that I found them in):

Documentation

Rust Cookbook: there are a lot of helpful examples in here

Blog Posts

How to Organize Your Rust Tests: LogRocket always kills it with the content

Videos

Conclusions

Below are some conclusions I've come to during this journey (along with the date that I came to that conclusion just in case my thoughts change over time).

2022-12-02: Rust is pretty neat. I might actually like it.
2022-12-04: Fighting to get the right types (like &str, String, char, &&str, etc.) more than I am actually programming. Hoping this is just like the initial hurdles I encountered switching from JavaScript to TypeScript.
2022-12-05: Like any language, it seems like it is not hard to write mediocre, naive implementations in Rust.
2022-12-06: Feeling a bit more comfortable. Adding in the overhead of keeping track of all the searches, righting down notes, and cirlcing back to the blog has definitely made this more of an undertaking than I thought it would be.
2022-12-07: What a roller coaster of emotion after messing up Day 5 and having to step back and come back to it later and then flying through Day 6. Rust is still pretty neat. I definitely might actually like it.

How I Interview Developers

Sat, 29 Jan 2022 21:15:07 GMT

I'd like to talk about interviewing.

I know what you're thinking:

Another blog post about hiring developers? Don't we have enough of those already?

We probably do, but I've spent a lot of time on both sides of the interview table lately and I get asked about interviewing often enough that I thought I should try to consolidate some of my thoughts and share them here.

Disclaimer: This post only reflects my personal approach to interviewing and does not necessarily reflect the thoughts of any past, present, or future employers.

Why Might You Consider Listening to Me?

If you don't know me (thanks for reading this, internet stranger!), you're probably also wondering why I think I'm qualified to talk about this subject.

Note: If you don't care about any of that and just want to see what questions I ask, you can skip to My Interview Questions.

I have interviewed well over a thousand developers for front end and full stack positions in my last few roles - one role in particular involved over 500 interviews over the course of a year for positions across various front end teams and physical locations - 60 of those were in a single week during a "hiring blitz."

As much time as I've spent interviewing candidates, I've spent even more time reading about interviews; talking about interviews with other developers, recruiters, managers (pretty much anyone who will talk with me about them); and refining my approach. Several of my employers have also had extensive interview training related to behavioral interviewing and inclusive interviewing, though I am by no means an expert in either.

At this point in my career, I feel confident saying that I am a good interviewer. Candidates seem to have a good experience - so much so that I've even received thank you messages from candidates that we didn't end up hiring.

Here's an actual message I received from a candidate we did not hire after an interview in 2018:

Hey! Thanks for the swell interview experience the other day! :)

I share all of this with you not to inflate my own ego, but to hopefully establish some credibility with you and show you that I've been putting in the work when it comes to interviews.

If you still aren't sure about me, that's cool - I get it. I have provided some links to great posts from lots of other people you might want to listen to instead in Further Reading.

Disclaimer: I do have to confess that I wasn't always a good interviewer. In fact, I started out as a pretty bad one who fumbled through dozens of interviews before starting to understand there was a problem and wanting to fix it. If you're one of those unlucky candidates I interviewed early on, I'm sorry - hit me up if you ever want help preparing for another interview, a resume review, or just to tell me how bad I was at it. If I have interviewed you recently and you want to refute my assertions that I'm a good interviewer, feel encouraged to reach out - I genuinely want to hear from you.

The Interview

I prefer to schedule one hour if the candidate has that much time free, but this same interview can be performed in 45ish minutes with some practice on knowing how long you can let a candidate take to answer and how long you can take to respond to questions, but you may have to cut out a few things.

This can also be condensed to 30ish minutes once you've got a really good feel for the timing of everything, but it leaves significantly less time for conversation and for the interviewee to ask questions, and ultimately provides a less optimal experience for everyone involved. Shorter interview windows generally leave the candidate with less time to ask their own questions. I always prefer to schedule a longer interview and end early if we're both out of questions than to schedule a short one and end with either of us having unanswered questions.

While this isn't necessarily always the order or the exact wording of the questions I ask, what I'm outlining below is pretty close to the interview experience that every developer should have with me.

Some roles or candidates involve digging into other topics a little more deeply or a candidate's answer may provide an interesting segue to learn more about them or may answer another question I was going to ask, etc. This means things change in small ways here and there, but the goal is to give everyone a similar experience that helps enable them to feel comfortable and present the best version of themselves. Interviews are already stressful situations (even for experienced interviewees) so there's no need to push anyone towards a panic attack.

Aside: I did actually have a candidate start to have a mild panic attack once - it was during that "hiring blitz" I mentioned earlier. It all turned out okay, but it really solidified for me just how stressful these things can be.

While you can't always avoid it, I try not to take too many notes during the discussion. Just some high-level bits and then I flesh them out after. You really want to engage with the candidate as another human being and that requires listening and actively participating in the conversation. If something feels really important and you want to make sure you capture it, ask the candidate if they are okay pausing for a few seconds so you can write it down correctly and then get back to the conversation.

My Interview Questions

I break a basic interview into roughly 6 parts:

Introduction (1-2 minutes): set expectations
- Make sure it's still a good time and the candidate is free for the scheduled duration. You should also find out if they have a hard stop at the end and let them know if you do - sometimes interview discussions go out of the original timebox and that's okay if it's a good conversation and interviewer and interviewee are equally engaged.
- Basic introduction: just your name, role, and how long you've been with the company; anything more is wasting time - the candidate can ask if they are curious.
- This will be a conversational interview; questions, follow-up questions, and back and forth discussion are all encouraged - due to time constraints, we may need to move on from a topic, but we can circle back or follow up in email.
- There are no right or wrong answers.
- There will be time for their questions near the halfway point and again at the end.
- Don't hesitate to ask for clarification or more explanation.
- Protip: Let them know upfront if you might have to mute a bunch because your dog somehow knows when you're interviewing and sometimes decides to be as annoying as possible during interviews
Interviewer Questions Round 1 (15-30 minutes): This section has some easy getting started questions and then some specific behavioral interview questions.
1. Tell me briefly about a project you've been working on in the last 6-12 months. What tech stack have you been using?
  - There's no need to get into everything a candidate has done throughout their career - you've seen their resume and/or LinkedIn, right? - just get into what they've been doing lately as that's generally the most relevant.
  - Protip: You may need to stop the candidate if they go too long on this one; about 5 minutes should be the upper bound, but 2-3 minutes is ideal.
2. What kind of role are you looking for? Are there any other experiences you'd like to highlight that you think would make you successful in that role?
  - This gives them a chance to describe what they are looking to do in their next role and also gives you a deeper dive into any other experience they have that might be relevant.
3. What technologies are you looking to work with? Are there any you would specifically like to avoid working?
  - Avoiding some tech is totally okay. Sometimes a specific language, framework, etc. just isn't our thing. I avoid Java and Ember because I just don't really like or fully grok them.
4. Tell me about a project where you feel like you really succeeded. What about your contribution to that project made it so successful?
  - Let them tell you about that time they totally crushed it. This is a chance to ask more questions and dig deeper into what they did, how they did it, and what they feel they are bringing to the table.
5. Tell me about a project where you feel like you failed. What happened? What, if anything, would you do differently now?
  - Everyone has struggled on a project at some point. It's okay to fail as long as you learn something from it. (Ask me how I know you always need to back up the production database.) This is a chance for the candidate to be a little vulnerable, show how they take (or shift) responsibility, and how they've learned from past mistakes.
  - Some people won't feel comfortable talking about failure, so if someone gives you a non-commital answer you may need to probe deeper for an actual real-world example. Be sure to let them know that failure is a thing that happens to all of us and they don't have to incriminate themselves for taking down us-east-1, but we want to hear about a situation where they learned from a mistake.
6. Tell me about a conflict you had with a coworker, stakeholder, customer, etc. What happened? How did you resolve it? In hindsight, would you approach it differently?
  - How do they approach conflicts? What do they do when they can't come to an agreement? No one wants conflict at work, but there are lots of times that we might disagree about how to approach solving some problem, how some business request degrades user experience, or how some user request is not possible given our current resources.
  - Protip: This could be a good time to reflect on how your current team approaches conflict and maybe briefly discuss it with the candidate in relation to their answer.
Candidate Questions Round 1 (5-10 minutes): This is a good time to shift gears and let the candidate ask some questions - remember this is as much a chance for them to interview the company as it is for the company to interview them.
- Engage as openly and honestly with the candidate as you can. Try not to ramble and to answer questions concisely. After you've done a lot of interviews, you'll start to refine the answers to certain questions and find that you've got certain responses ready.
- Protip: To avoid rambling, sometimes I start a stopwatch and glance at it every so often while answering a question so I know how long I've been talking. Remember, this is the candidate's time to learn about the company, and the longer you spend answering one question the less time they have to ask other questions.
Interviewer Questions Round 2 (10-15 minutes): This section gets into some more technical interview questions and also allows you a chance to dig deeper into any follow-up questions you want to ask based on anything that's been talked about so far.
1. Tell me about an interesting or particularly challenging problem you solved in the last 3-6 months. What made this problem interesting? How did you approach solving it?
  - This gives the candidate another chance to show off their skillset and talk about it passionately. You can probe deeper into any specifics around this and just sort of talk about it with them a bit.
2. Tell me about a tradeoff you had to make in the last 6-12 months. What were the options? How did you choose between them?
  - A lot of what we do involves managing tradeoffs: performance vs readability, faster delivery vs future maintainability, abstraction vs repetition, etc. This is a chance to dig into how the candidate thinks about these things and how they navigate the often nebulous waters around this kind of decision-making.
3. Follow-Up Questions: if you have anything you want to expand on based on your conversation with the candidate so far, this is the time for that. Want to hear more about how they used AWS for a project? Did they mention navigating a rewrite at a large company and you want to hear more about the planning and execution? Dig in a little.
4. For Senior-ish Roles: Pretend that I'm a junior developer without much context and explain [insert topic here] to me.
  - Some Example Topics (pick something relevant to the candidate's actual day-to-day work and previous experience, and, it should go without saying, but make sure you are comfortable with the topic):
    - Feature Flags
    - Blue/Green Deployments
    - A/B/N Testing
    - CSS Specificity
    - Scope in JavaScript
    - Model-View-Controller (MVC), Model-View-ViewModel (MVVM), or some other pattern relevant to their past work or your codebase
    - Functional Programming, Object-Oriented Programming, or any other programming paradigm that might be relevant to their past work or your codebase
    - Continuous Integration / Continuous Deployment (CI/CD)
    - Serverless Functions (AWS Lambda, Azure Functions, Google Cloud Functions, etc.)
    - Caching
    - Containers
5. For Junior-ish Roles: What language, library, framework, etc. are you looking forward to learning and working with in the near future? What tech is exciting to you right now?
Candidate Questions Round 2 (remaining time minus 30 seconds to a minute)
Wrap Up (30 seconds-1 minute)
1. Inform the candidate of the process from here and about how long they should expect to wait before hearing back. I also always let them know that if there is a bottleneck in the process, it is almost certainly my fault and not the fault of our internal recruiters.
2. Let them know that they can email you (or their recruiting contact) if they think of any more questions.
3. Thank them for their time.
4. Protip: Take a few minutes after the interview to compile your initial thoughts and shoot them over to your recruiting partner. If you need to think on it a little more, save that email as a Draft and set a reminder for a couple of hours - hiring is crazy right now, if you wait too long, you could easily lose that candidate.

Why This Approach

There are several benefits to this approach:

Human-Centered: It treats candidates as humans, and as equal participants in a conversation.
Hard to Game: There isn't really any coaching that can prepare someone for this interview. I've worked with a lot of recruiters and consulting firms over the years and sharing knowledge about interview questions always comes up when you're the interviewee. With these questions, you could do something like publish them on the Internet for everyone to see, and it would have no effect on the efficacy of the interview.
Enjoyable: I might be personally biased on this one, but as the interviewer, I enjoy this kind of conversation a lot more than pop quiz style interviews I've been asked to conduct in the past. As I mentioned already, candidates seem to enjoy this interview process, too.

There are some possible drawbacks, too:

Time-Consuming: If you are in a high-throughput recruiting situation (at one point I was reviewing 30-40 resumes a day for dozens of open positions), you won't have the time to engage with each person at this level and might need to introduce something that creates a quicker filter before this kind of interview. You might also want to work on improving the quality of your filter at the application stage, resume review stage, and any initial recruiter call that might happen after a resume has been reviewed.
Not Directly Technical: You only learn as much about a candidate's technical ability as you are comfortable digging into during the discussion. Some people will maintain that you need to put a candidate through some kind of whiteboard question where they are put on the spot to write code in a context that is entirely unlike their normal work, and they could be right.

Introducing @RSS bot

Sat, 25 May 2019 12:50:06 GMT

We have a lot of developers working in different places at different times at Skookum. People are sharing interesting, useful, and/or important articles at various times throughout the day. Unfortunately a lot of that content is missed by the majority of developers.

Enter @RSS bot, a Slack bot that will generate an RSS feed of links shared in channels it is invited into.

Every time a user shares a link in a channel it is listening to @RSS bot will ask that user if they would like to add the link to the channel's RSS feed, so users have control over what appears in their RSS feed.

Are you tired of missing links shared in your Slack channels?

Get @RSS bot today!

Senior Developers

Sun, 03 Mar 2019 14:19:16 GMT

While I don't care about title inflation or title absurdity, I do care about what the people doling out and receiving some of these titles assume that they mean.

One title modifier, in particular, Senior, is important to me, not because I have it, but because without people who embody its Core Principle I wouldn't be where I am today.

I wouldn't be able to help others get here if that principle hadn't been instilled in me.

Meaningless Titles

In an industry where two people can do the same job, but one is an Engineer while the other is a Ninja, I think it's safe to say that our titles are meaningless.

Which is good. You could spend your whole career chasing ever-loftier titles. That way lies madness. Unfortunately, a lot of companies either use title changes in lieu of pay raises, or tie pay to titles in a way that requires doling out new ones or adding modifies (How many of you are a [Title] II or a [Title] III?) to them every 12-18 months.

When I worked for Bank of America, my title was so long that they stripped almost all of the vowels from it and it also featured a hyphen (-) and a semicolon (;). Add to that the fact that basically every full-time employee who writes code is a "Vice President" and you end up with a silly VP title that means absolutely nothing and is impossible to explain to anyone.

I don't have any solution for this insanity in our industry, and it's not really important to me that we change it, but I wanted to make sure that we covered how meaningless we've made all of our titles before I explain why Senior is actually important and why the meaninglessness we've created could lead to an industry-wide problem.

It's also worth mentioning that the Engineer title is ridiculous given the generally ephemeral and fragile nature of what we build and the lack of any oversight or credentialing body, but that's a topic for a different rant.

The Senior Core Principle

A Senior Developer (or Engineer, Ninja, Rockstar, etc.) is not just someone who has more experience or one who is the lead on a team or a project.

The Senior title comes with a vitally important responsibility: to make those around you better Developers.

That responsibility is the Core Principle of the Senior and it is one that should span our entire industry. It is rarely listed in job descriptions, but it should be.

What we see an alarming amount of today is Developers being put into Senior positions as the next logical step in their career progression or as some reward for sticking around. While this won't have a huge immediate impact, it will radiate through the following generations of developers and amplify the effect over time.

When a Senior who embodies the Core Principle teaches the next generation of Senior developers, they go on to embody that principle and instill it in the following generation, too. Life is good.

When a Senior who only has the title doesn't instill that principle in the next generation - or, even worse, instills the idea that Seniors are arrogant and unhelpful - then that idea trickles down and more arrogant, unhelpful Senior Developers will be created. Here there be dragons.

If that eventually becomes the norm, how much more toxic would Developer culture become? How hard would it be for someone to transition into the field? How hard would it be for Junior developers to grow into Senior developers?

If you're a Senior right now: What are you doing to make those around you better Developers?

My Senior Philosophy

My approach to embodying this Core Principle involves several things, but the primary directive is trying to make time for other Developers to ask questions, talk through solutions, vent about clients, ask for code reviews, and ask about career advice.

I always caveat that my code reviews and my advice may not always be the best solution, but they are what I would do and then provide the reasoning behind that decision. I've found that it helps people learn when you show your work, and it also invites the other Developer to question your thought process and provide their own insights on things you might be overlooking.

In the service of making myself and other Developers better at what we do, I organized a few initiatives during my time at Skookum and continue to do similar things at every other place I work.

Monthly Coding Challenges: Every month we will tackle a new coding challenge and help keep each other motivated in a dedicated #coding-challenges channel in Slack. Each challenge is different and allows a wide range of Developers to hone their skills.
Monthly Developer Presentations: Every month we will invite one of our developers to present a Web-related topic to the rest of the Development Team. Hopefully, this helps Developers iron out presentations for Meetups and conferences while also giving the rest of us some new perspectives.
Bi-Weekly Video Series: Every 2 weeks we watch a Web-related video and discuss it as a group. This was previously an initiative, but the developer who started it left the company, so a colleague and I resurrected it. This gives us a chance to experience conference talks we would otherwise miss out on and also facilitates conversation between Developers at all levels.

RSS Feed: https://ericrallen.dev/

Advent of Rust: Part II

Table of Contents

Challenges

Getting Started

Conclusions

Day Six

Real Talk

My Solution

Testing

Takeaways

Notes

Searches

Next Steps

Wrapping Up

Advent of Rust: Part I

Table of Contents

Challenges

Getting Started

Conclusions

Day One

Real Talk

Takeaways

Notes

Searches

Next Steps

Day Two

Real Talk

Takeaways

Notes

Searches

Next Steps

Day Three

Real Talk

Takeaways

Notes

Searches

Next Steps

Day Four

Real Talk

Takeaways

Notes

Searches

Next Steps

Day Five

Real Talk

Takeaways

Notes

Searches

Next Steps

Wrapping Up

Advent of Rust

Table of Contents

In This Post

Series

Background

GitHub Repository

Getting Started

Resources

Documentation

Blog Posts

Videos

Conclusions

How I Interview Developers

Why Might You Consider Listening to Me?

The Interview

My Interview Questions

Why This Approach

Further Reading

Introducing @RSS bot

Senior Developers

Meaningless Titles

The Senior Core Principle

My Senior Philosophy