Hacker School admitted me to its Winter 2013 batch last January. I don't think I've written here about my experience on the interviews yet, and I'll do so now. There was so much to say about the second of them that I failed to compose either a diary entry or any letters to friends containing much of value. So what follows is reconstructed from later notes and my memory.
When I was admitted, the practice was to conduct two interviews. The first was a general conversation begetting I suppose a sense of my personal (not professional) goals in applying to Hacker School and how my personality would mesh with the rest of the ecosystem of the place. The second one, which had to be done with a different person, involved pairing on some piece of code that I had already written — adding a small feature or refactoring.
At core, both of these are evaluations of personality. So I can't offer any advice beyond: be your own true self, and in the pairing interview share your actual thinking about the details of your code. Hacker School is a very effective environment for someone who reflects critically about how their code works and reacts without prickliness to other people's suggestions.
For the pairing interview I submitted a Python progress-bar class that I remembered worked when I stopped work on it half a year before. Thirty minutes before the interview I tried it out, found it was broken, and went into high hysterics trying to figure out what was wrong. That proved to be much better preparation for the interview than all the placid reading of the code that I had done earlier. I fixed the last of the bugs a minute or so before the interview started, and was in a good state of mind to talk confidently about details.
The interviewer asked me to walk her through the code, and as I did I
pointed out places where there I thought I could improve functionality.
I started out on a fairly high level, but the interviewer wanted to know
about details of implementation. My little class relied on the
multiprocessing module to run the progress bar independently of the
task whose progress was being tracked and continually received
information from the task as ctypes values, and we talked a bit about
that. At the very end she asked me how the use of multiprocessing
affected running time, something I had not yet learned how to measure
and consider. (I started doing so immediately after the interview; the
answer is that running time is affected to a disastrous degree, a cost
of something like a thirteen-fold slowdown. The project now lives in a
directory named abandoned_but_do_not_discard.)
She also commented on my style of naming imported modules, for instance:
import struct
import sys
import os
import time as T
import random as R
import multiprocessing as M
import ctypes as C
Any module with a long name or that I refer to often I name with one or at most two capital letters. That saves typing and makes it easy to see quickly and unambiguously when a module is in use. The interviewer remarked that she hadn't seen that done before and wondered where I learned it. I no longer recall where I learned it or whether it was my own shortcut. When I joined the batch I was told it wasn't part of best practice and I stopped using it, but I've started again recently; I think it's effective and clear to anyone reading the code with sufficient care.
My feeling was that the interview went well. But when I heard back from Hacker School at the end of the day I observed that I felt surprised that I had been admitted.
I can't recommend Hacker School enough for someone in a situation like mine. At the institution's request for a testimonial recently I described that situation and Hacker School's effect as follows:
I came to programming after a decades-long career in a totally unrelated and non-quantitative field. After exposure to a couple of programming languages, and after taking some math and theory courses, I was still a very green peach. Hacker School ripened me into the ways of the guild of coders: I learned how to read other people's code, to pair-program, to ask for help in a way that was useful to myself and others; I got used to jargon, along with how and when to use it; I learned various best practices and the names of many, many tools. Above all else, I learned to think of myself as a coder, really and truly, and I find myself now part of a growing family of pleasant, helpful brother- and sister-coders.
There are things I would like to say about what I see as the long-term effects of the presence of this group of "pleasant, helpful brother- and sister-coders" in the field. But I will save that for another day.
[end]