PuPPy Interview Preparation Night – A Philosophy in Progress

I recently agreed to co-organize the Puget Sound* Programming in Python (PuPPy) Interview Practice Night. It has had much more attention than I expected and I’ve found that I’ve honed my message considerably; which is a benefit for me and my audience. This is a work in progress and I expect this will move in several different directions as we host an increasing number of events. However, I want to put this out there for groups that want to implement a similar practice paradigm. I’ll skip the discussion of finding locations and advertising. That will be entirely different for each group. Rather I will focus on my philosophy for the evening, starting with the problem as I see it.

A caveat I’d like to add is that this is not entirely my project, though I do get to be one of the two or three hands on the steering wheel. I have the impression that others involved with IPN have similar feelings but I can’t guarantee every event will be run the same way. I can guarantee that the events I host will be run this way and I’ll encourage the other hosts to adopt this philosophy.

The Problem

Most whiteboard interviews seem to follow a pattern: A relatively new to the field developer** applies to a job; Now “Applicant,” this person is told there’s a tech interview scheduled; Applicant freaks out and deep dives into Cracking the Coding Interview; Applicant arrives and is put in front of one or more engineers who ask them to perform a coding exercise that is out of context (these typically lack a use case and are divorced from the tools of the software developer); Applicant’s mouth dries as they stammer and piece together some code on the board; Interviewer says “thanks for your time” and Applicant leaves, having no idea how they performed; Applicant (maybe) receives an email informing them that Company is not moving forward with the interview process.

A Solution

Interview Practice Night hopes to develop the skill of performing a whiteboard interview. I want attendees to practice a nerve-wracking skill in front of relative strangers, but in a low-stakes environment. Ideally after a few attempts at coding in front of strangers, attendees will lose a lot of that performance anxiety. Our foundational texts are McDowell’s Cracking the Coding Interview as well as Elements of Programming Interviews in Python. Problems that attendees have encountered in technical interviews or on a code-challenge website are also encouraged (so long as the person bringing the problem has a reasonable path to solving their problem).

For the person writing, I encourage thinking out loud, writing out givens and assumptions, and pseudocoding. I understand that frequently the (un)stated goal of tech interviews is to learn how the applicant thinks and communicates about code. I encourage the person writing to work until they’re actually stuck, take a moment to think about their solution and if they can go no further, ask for a hint. I have heard both sides of this argument, but I’m of the opinion that: if I’m stuck on a problem, not moving forward doesn’t work in my favor; asking for help shows both an understanding of my abilities and their limitations; asking for help demonstrates that my ego is not more important than solving this problem; asking for help is what I would actually do in real life; and if asking for help is a mark against my candidacy for a job, that tells me a lot about the culture of the company in question.

For the people who are not writing, I strongly encourage them to act like they are the teammates of the person writing. We live in a world where professional code is written by a team; in real life teammates wouldn’t let the person at the whiteboard drown when they became stuck and they also wouldn’t let their teammate follow a wrong path (assuming the team identifies that the solution is heading in a non-optimal direction). I want the writer to solve the problem on their own if they’re able. But if teammates notice there’s a drop in production (written or spoken) I want the non-writers to ask if the writer wants a hint; or wants to share what’s happening in their internal dialog. If the team sees the writer moving in the wrong direction, I want the team to offer gentle encouragement back to a “correct” path. Much to my pleasant surprise, once a problem is “solved” I’ve witnessed great conversations about optimizing solutions and iterating on solutions to solve related, but different, problems.

Related Interview Skills

Whiteboarding is a useless skill if the applicant never gets to the room with the board and the pen. My future plans include résumé review, behavioral interview practice and remote coding interview practice. All of these initiatives are in parallel with whiteboarding; not everyone at a practice night will be participating in these events at the same time.

Résumé review is what it sounds like. The key here is to avoid a situation of “the blind leading the blind”. I can review your resume. But I haven’t looked at dozens or hundreds of resumes while trying to hire for an open position. Hiring managers and HR professionals can work with attendees to revise résumés, in particular looking for spelling and grammar errors that will turn off a potential employers. Ideally our professional volunteers will help “punch up” the document to make the verbiage more attractive to potential employers. In some cases, something as simple as rearranging the bullet points in a section can make it more enjoyable to read.

Behavioral interviewing is yet another skill that people don’t have a lot of opportunity to practice, outside of “throwaway” interviews (which is not an ideal situation for either side of the table). My vision for this is to have the interviewer ask STAR/”tell me about a time when” type of questions. The ‘interview” should last about ten minutes, with about five minutes for feedback. The interviewee will get practice with their storytelling, honing the details and narrative. The stories should only have the details needed to tell the story without meandering, but also avoiding “stories” that don’t offer any details (the dreaded monosyllabic answer to the open-ended question). In addition to narrative feedback, the interviewee should expect to learn about tics and distracting mannerisms ( “um…”, “…like…”, “… you know? …. you know?” as well as face touching, not making eye contact, etc.)

My dream for this project is to set up remote coding interviews. For many these are the worst scenario. The interview is conducted over the phone, which not only has the as-of-yet unsolved telephony issues but calls lack the non-verbal communication cues that we rely on. In addition, many people don’t have experience coding in a web-based IDE much less a shared web-based IDE. I would like to have the interviewer set up in one space with the interviewee in a separate space. The coding problem doesn’t have to be complex, this is a good use case for fizzbuzz or Fibonacci. The interviewee needs to practice with the interpreter/REPL and they should receive similar feedback as they would from a behavioral interview.

If you are in the Puget Sound region and would like to join us, please find the Interview Practice Night group through the PuPPy Meetup group, below.

Puget Sound Programming Python (PuPPy)

Seattle, WA
7,199 Pythonistas

Welcome! We are a fun and friendly user group dedicated to proliferating a diverse and talented Python community in the Puget Sound region. We are devoted to exploring Python-…

Next Meetup

Interview Practice Night

Monday, Feb 25, 2019, 6:15 PM
19 Attending

Check out this Meetup Group →

Please bring this to your group and try it out. It can be your coding bootcamp, your CS cohort, the informal coding group you’re a part of. If you find this useful, please let me know. If you tried this and found a different method that worked really well for your group, let me know. Good luck out there.

“*” PuPPy understands there needs to be some poetic license taken with the acronym.
“**” It is my observation that mid- and senior-level developers do not face this same challenge. Often whiteboards, if they’re used at all, are used to write out ideas collaboratively during interviews that feel like chat sessions.

PuPPy Interview Preparation Night – A Philosophy in Progress


I showed instaCropper to my social media clients, and they were impressed. One of them suggested that I increase the size of the canvas, rather than crop the images to squares. The tradeoff is that increasing the canvas makes the original image relatively smaller. The advantage is that I can bulk process photos in about a third of the time it took me to process them with instaCropper.

InstaSquared starts by ensuring the file in question is a photo by checking for EXIF data; if there is no EXIF the user is informed that the file is being skipped. Once it’s established that the file is a photo, it finds the longer side and uses that dimension to make a new canvas. There is some math to figure out offsets and the original photo is pasted onto the center of the new canvas.

instaSquared was designed to process bulk images that are sent to me by show photographers. With that in mind I eliminated all of the user decisions that were available in instaCropper. Now all files have “squared_” prefixed onto the original file name and the new file is saved to a “squared” directory in the parent directory.

If you try it out, please let me know what you think.

Original photo from my trip to Oahu
InstaSquared version of the above (resized by WordPress)


I started managing social media for a local theatre group. We’re trying to improve engagement on FaceBook (in our group and in each event), Twitter and Instagram. The process was eating in to the time I allotted for this project, so in addition to setting up an account at Sendible to automate post scheduling, I created the instaCropper tool.

The problem with Insta’ (the ‘Gram) is that the images for upload must be perfectly square (except for story photos which can be something like 1.9:1). The next issue is that performers universally don’t ask their photographers to provide the equivalent of passport photos just so some social media dude can make Instagram posts. Certainly cropping a single photo perfectly square isn’t particularly time consuming…

But I write code! Why would I do this manually? Ten performers plus two producers times three photos for each of those, plus photos of three back-of-house people, plus show prep photos equals more time that I want to spend drawing perfect squares.

Starting with the Pillow library, I was able to write a script that will take in a single image or a directory for processing multiple images. Each image is opened in preview to confirm that image is correct. If the orientation is wrong I can rotate or flip the image as needed. Should there be more background than I want I can set the crop origin. The crop is confirmed via a preview image. Once it’s what I want I can save it with a custom filename and in a separate directory from the original photo – all from the command line.

Processing a single image used to take at least 70 seconds. It now takes about 11 seconds and there is no chance that I will accidentally overwrite the original photo (that happened more than once, fortunately I was working on local copies from a google drive folder). If you use the tool, please let me know. If you think of reasonable additions, feel free to create a github issue.


Let’s Talk Template Literals

It’s interesting that there are so many ways to STDOUT text to the screen. Let’s look at a few of them in JavaScript (ES6) and Python (3.6)

Concatenation: This works in both JavaScript (console.log) and Python (print). “The first half of the sentence ” + “is joined to the second with a plus sign between the halves.” Also works with variables. “Hello, ” + user.name + ” and welcome to our shopping site.” Do pay attention to where spaces are.

Embedded expressions: Javascript allows developer to include simple expressions as well.

console.log( "Hello, " + user.name + ". Your total is: " + (purchase.subTotal + purchase.tax + purchase.delivery) + ".")

Hello, Kristopher. Your total is $123.45.

String formatting: Python 3.6 allows developers to include variables mid-string as follows:

print('We are the {} who say "{}!"'.format('knights', 'Ni')) 

We are the knights who say "Ni!"

But if you need to refer to the position of the argument (values passed in to ‘format()’ there’s also:

print('{0} and {1}'.format('spam', 'eggs')) 
spam and eggs


print('{1} and {0}'.format('spam', 'eggs')) 
eggs and spam

As well as keyword arguments, though I find this exceptionally cumbersome and wonder why the developer wouldn’t jut hard-code the values into this sentence. I’m including it because it’s in the Python docs and isn’t noted as being too archaic:

print('This {food} is {adjective}.'.format(food='spam', adjective='absolutely horrible')) 

This spam is absolutely horrible.

My personal preference, added to Python in 3.6 is the f-string

print(f'Welcome, {user.name}! Today's special is {special.name} and is on sale for {special.price}.')

Welcome, Kristopher! Today's special is Singing Rooster Coffee 12oz vacuum bag and is on sale for $10.

This is really easy to debug, in part because it reads very much like the end sentence, without extra punctuation. I also don’t have to type-cast my variables like in Python 2.7 (which required %s, %f and %i when referring to strings, floats and integers). Take a look at the Python docs for more examples and explanations: https://docs.python.org/3/tutorial/inputoutput.html

In JavaScript I’m growing attached to template literals. Like the f-string a template literal reads very much like the final product.

console.log(`Welcome, ${user.name}! Today's special is ${special.name} and is on sale for ${special.price}.`

Welcome, Kristopher! Today's special is tomato soup with grilled cheese sandwich and is on sale for $6.75.

The only catch here is to look for backticks (“ the keys that are left of the “1” on a US keyboard). At first they can look like single quotes, though most IDEs I’ve worked with do a good job of making the angle very obvious. MDN has done a great job with the documentation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

Let’s Talk Template Literals

Ready for Winter?!

We don’t usually lose power at our house beyond a flicker. Which is why it’s odd that we’ve lost power twice in the last eight days. We had a friend over who was amazed by our collection of flashlights and gadgets that we take camping with us, that are obviously ready to double as gear for a night without the lights. Here we go:

These inflatable lanterns are super cool. Not only do they provide a good amount of light to the sides, we often use them as flashlights if we’re just walking around camp. https://amzn.to/2RdRZKv

Speaking of lanterns, this Goal Zero unit is amazing. They put a lot of functionality into it and the battery holds a charge for a long time. We haven’t tested but I suspect we would get well over 12 hours from the single light on Turbo (which is overkill).


Does anyone remember those lantern battery flashlights? They were really heavy and had a beam we were sure could be seen from space. My obsession with bright flashlights continues:

900 Lumens: https://amzn.to/2UWOneS
1300 Lumens: https://amzn.to/2LvFip7

More so when we’re camping or out for an evening walk, we like to have our hands free.

Black Diamond Storm: https://amzn.to/2SfWq4L

Petzl Tikkina: https://amzn.to/2V6qwK3 
The Petzl I have is different from this unit and is also not super bright. But that makes it useful when we’re just around camp or the house during an outage. It -is- possible for a flashlight to be too bright.

Speaking of going for an evening stroll, we like to have a light on the back of our heads as well. One time a driver slowed down to thank us for wearing red flashers (and reflective stripes!). I can’t find the units we use, but these are close: https://amzn.to/2V28Jn3

The last on my list is definitely a “gadget”. I kickstarted these and I’m mixed. Having a flashlight and firestarter combo is a great idea. Unfortunately I couldn’t ever get anything to light using the plasma lighter. Granted I live in Seattle and everything is slightly damp when we go camping, so every lighter has issues. The mini is great for just carrying around and the light is decent. The Sparkr light is really good and the end cap can go over the light to make it sort of a lantern; if nothing else it’s nice to be able to hang it from things.

Mini: https://amzn.to/2BA676W
Sparkr: https://powerpractical.com/pages/sparkr

So that’s how we keep things lit around the house. We do use some candles (because we have them) but all of the above have seen us through long, dark nights whether at home or in the woods. I just got my BioLite headlamp today (as a Yule present) and I’ll probably do a review of it as I get a chance to use it.

Ready for Winter?!

Notes For the Future: Background Images in iOS Safari

I spent about an hour tonight trying to get my new background image to display in the Xcode device simulator. I thought it might be an image size issue, but it apparently has something to do with how the background is attached. Here’s the code I used for my header on mobile breakpoints:

header {
background: url(“../assets/header.svg”) no-repeat center center fixed;
background-attachment: scroll;
background-color: #4f4f4f;
background-position: center;
margin-top: -35px;
-o-background-size: contain;
-moz-background-size: contain;
-webkit-background-size: contain;

Notes For the Future: Background Images in iOS Safari

Notes For the Future: Android SDK Emulator

The Chrome Dev Tools screen size simulator mostly works. But when I open a site on my phone and it isn’t really doing what I expect I start to scratch my head. Fortunately the Android SDK provides a robust device simulator.

The trick, and the reason this is a note to myself for the future, is that “localhost” is at The emulator behaves exactly like my phone (for better or worse).

Notes For the Future: Android SDK Emulator