Deciphering my Dead Mother’s Cipher

Posted on January 27, 2023 by martincmartin

My mom passed away in 2020, and in cleaning out her house I found her old diaries. Seventy five years ago, in 1948 at the age of 15, she wrote:

Ah, a puzzle. I like a good puzzle.

Some quick googling revealed it was a pigpen cipher. That’s where you take a 3×3 grid, like a Tic Tac Toe board, put a letter in each square, then use the square or “pen” that a letter is in to represent that letter. Of course, that only works for 9 letters. So you do it again, this time putting a dot in each square. That leaves 8 letters, so now you form an X, put a letter in each “pen” of the X, with or with out a dot.

And using that, I quickly decoded the first name, and got … JKLL LXNPNKON. Fail. She must be using a different way to map letters to pig pens. But what is it?

Well, in earlier entries she had crushes on hockey players and politicians. In fact, at age 14 she wrote “I like to imagine I am P.M. [Prime Minister] torn between 4 loves – 1. Cabinet Minister, 2. brother of first husband, 3. baseball big shot, + 4. French diplomat!” Two people in particular were Ontario Premier George Drew and Toronto Maple Leafs star Bill Ezinicki. And Bill fits the first cipher! Well, mostly. It has the right number of letters, the two Ls use the same symbol, and all three Is in Ezinicki use the same symbol. But the I in Bill uses a different symbol. Still it all fits too well to be a coincidence.

Another oddity is that every symbol has a dot. A standard pigpen cipher has 13 different shapes, then repeats those again with a dot inside to give 26 symbols. But if you only use the ones with the dot, you only have 13 symbols, so each symbol must represent two letters. You can see the L in Bill uses the exact same symbol as the E in Ezinicki.

I is the 9th letter, the last letter in the first pass when filling up the grid. What pattern means the center is filled last? A spiral inwards!

Well … that doesn’t work for B, E or C, the letters in Bill Ezinicki that are in the first nine of the alphabet. Back to square one.

So let’s look at the second name. Who’s wife would Ezinicki be running around with? It’s a dream so it could be anybody, but a reasonable guess is another team mate. The roster for the 1948 Toronto Maple Leafs shows nobody with a nine letter last name. Curses, foiled again.

With only 13 symbols, each symbol encodes multiple letters. So, just because the same symbol appears in two different locations doesn’t mean they’re the same letter. Think of the L and E in Bill Ezinicki. But the opposite is true, we hope: if two different positions use different symbols, they have to be different letters. So in that nine letter last name, the last seven letters all have to be different. And the first two letters have to be different than any of those last 7, save the seventh letter.

So let’s look at a list of common last names. The U.S. Census has a list of surnames occurring more than 100 times anywhere in the United States. It has 151,671 names. If you restrict to nine letter names, that leaves 14,424, which is still a lot. The most common is Rodriguez. And while the last seven letters of that name are all different, the first letter is the same as the fourth, namely R, but they use different symbols.

Making sure different symbols represent different letters leaves 2,160 names, the most common of which is Dominguez. There’s no pattern that I can see in the most common names.

So we need more information. The last letter uses the same symbol as the I in Ezinicki. Of course, it doesn’t have to represent an I, but what if it did? Here are the 10 most common surnames:

GRABOWSKI
SZYMANSKI
JABLONSKI
CZARNECKI
DABROWSKI
STEFANSKI
ZEBROWSKI
GODLEWSKI
TARNOWSKI
CANGELOSI

Now we’re getting somewhere! If it ends in an I — a big if — the last three letters are probably SKI. However, there’s no real pattern in the earlier letters. So once again, we need to look at the problem differently.

Let’s try putting the known letters in pens, and see if we can see any patterns. We won’t add the SKI since that depends on an assumption, but we’ll do it for all of Bill Ezinicki:

Well, the B is in the upper left, the same spot as A in the standard encoding. And it seems most natural for a pattern to start in the upper left with A. If A & B are the two letters mapped to the upper left, that suggests C & D are next, in the upper middle, then E & F in the upper right, and so on.

And that mostly works! The I and L in Bill are in the wrong place, although interestingly, they’re just missing a top line in their symbol. But all the other letters fit. If we use this with the second name, we get:

W A K K Y | S S A M O W S K I
X B L L Z | T T B N P X T L J

Perhaps you can see it by just looking at the above, but if not, some simple filtering of the surname list gives us: Stanowski. Wally Stanowski played for the Leafs the season before, 1947 – 1948.

Also, as I was researching this post, I found a variant of the pigpen cipher where the location of the dot distinguishes the two letters: left for the first, right for the second. And if you look at, say, the ST at the start of Stanowski, you’ll see the first dot on the left, second on right.

It’s fun exploring my Mom’s old diaries, which span over 30 years of her life, up to when I was 9 years old. She never used a cipher again, but I’m glad I got to figure out the dreams of a 15 year old girl in 1948. I’m sure she never pictured her son using a computer to crack it. The existence of the first computer, ENIAC, was only revealed two years earlier in 1946. And it would be over four more decades until the World Wide Web was opened to the public, and another decade until Wikipedia and search engines made it possible to find old Maple Leafs rosters and learn about Pigpen ciphers.

Advertisement
Posted in Uncategorized | Leave a comment

My Favourite Interview Question To Assess Design

Posted on July 28, 2015 by martincmartin

When interviewing higher level software engineers, it’s good to assess not just ability to write code, but also to design systems. To accomplish that, I used to ask people to design something, such as an elevator control system.  However, that leaves some gaps.  For example, if you ask them to design a distributed storage system, they may decide to use a two phase commit.  But do they remember why?  How do simpler schemes fail?  Also, when designing with a group of engineers, are they able to give useful feedback to other people?

So instead, I give them naive designs, and ask them to list the designs’ pros and cons of each.  For example:

I want you to help the team design a distributed storage system.  I’ll play the role of the team, suggesting designs, and I’d like you to give feedback on the pros and cons of the designs.

Let’s design a distributed file system. Companies like Facebook and Google don’t use centralized storage, instead they have lots of computers each with commodity disks, and if one fails, they can continue serving requests without losing data.  They have an API that makes the disks look like a single block device with a single, unified address space.

So let’s say the team comes to you with this design:

def write(int address, byte data[4096]):
     Store the data on the computer where the
     write takes place.

def read(int address):
    Lookup the address on the computer where
    the read was issued.
    If we find it, return the data.
    Otherwise, broadcast a message to all
    computers, "please send me the data for
    this address".
    If any computer has it, return that data.
    If no computers have it, return "not found."

 

I then draw a diagram with four computers, and work through an example where one of the computers writes a block, then another computer reads it.

It’s interesting to see what people list as pros and cons. Many talk about the high cost of broadcasting to all nodes. Few catch the potential data inconsistency. The simplicity is a pro, but lack of redundancy is a con.

When they point out that there’s no redundancy, I suggest writing to two machines independently. If both succeed, then we return “success,” otherwise, we return “fail.” Can they spot the problems? Can they point out pros like that disks will be fill up evenly, or will they focus only on cons?

I find that asking people to critique designs gives me a better idea of how they understand a system. Do they just throw around buzz words and boxes, or can they think through the details? Do they have a sense for where race conditions might hide? (Hint: multiple computers touching the same data; things finishing in a non-intuitive order; nodes failing.) Can they actually work through those examples to find the problem? Can they understand that every design has pluses and minuses, or only focus on the parts they don’t like?

And I can also use it as a background for asking: Do you facilitate discussions and encourage team members to come up with their ideas? Or do you see generating designs and architectures as your job alone?

Posted in Uncategorized | Leave a comment

A Few Things I’ve Learned About Agile

Posted on July 15, 2015 by martincmartin

Many years ago I worked on code that integrated tightly with 3rd party software. The APIs were not always documented, and when they were, the documentation sometimes had omissions or was just plain wrong. In a situation like this, what to do?

Management’s idea was to involve experts, people who were already familiar with the 3rd party software, in fact some had worked for the company that made it had a hand in creating it. However, the software was vast and nobody could understand more than a fraction of it. Once again, QA could only test the basics during development, thorough testing would have to wait until just before release. And that’s when we’d discover that our current design wouldn’t work and would need significant revision.

Lesson learned: When there are lots of things you can’t know, iterative development is the key to validating designs and getting a predictable schedule as soon as possible. It’s more important to get something working and testable first, then refine it, than it is to build it “production quality” from the start.

At another job, the team would divide up each project into independent components, and have each person work on a different component. We’d intend to do design reviews, and sometimes even do them. Then, after a few weeks, when it was time for a code review, someone would often point out a simpler way to achieve the same goal, or where more defensive programming was needed throughout the work. Only now it was a lot more work to change it. In other words, each part is exposed to the entire genius and foibles of the individual programmer who worked on it.

So we kept saying we needed more reviews and tried various things to encourage that. The problem is, when developers had a choice of working on their own code or going over someone else’s, they usually chose their own. That’s the task that was on the backlog that everybody else was tracking. Interrupting a co-worker to say “can you show me what’s changed since the last time I stopped by?” felt unusual.

The one thing that worked — and worked well — was for people to trade off tasks that lasted around a day. That way, I need to understand the code you wrote yesterday since I’m modifying it today. Plus, your change probably touched code that I’ve worked on and have opinions on. And discussing those opinions is exactly what we needed.

Lesson learned: It’s important to have multiple developers thinking about the details, and it’s really hard to thoroughly consider the details of something you’re not working on.  So explicitly resist developers urge to work on independent parts of a system.  Instead, assign people interdependent tasks that each take around a day.

 

None of this replaces good coding practices such as always checking return values (even if with just an assert), automated tests, readable code, etc. In fact, it’s designed to encourage those, to encourage people to share such best practices early and often.

Posted in Uncategorized | Leave a comment

Higher order functions are (sometimes) more natural

Posted on June 1, 2015 by martincmartin

I had a debate with some friends at work the other day, about whether the higher-order function map just adds needless complexity to a language. They considered it a kind of “advanced” function, which surprised me. They said that by not having a variable that holds the current item, it was too concise and cryptic. So I did an experiment.

Daddy: I have a number i, it starts at 1, increases each time and stops and three, and for each i, take Oreo i and eat it.

5 year old: Oreo i? Oreos?

He walked away puzzled. A few days later, I tried again:

Daddy: For each Oreo o, eat o.

5 year old: ??

Again he just walked away without understanding what I’d said.

Daddy: Eat the Oreos.

5 year old: Sure! Yay!

In natural language, at least, we often don’t introduce a term to stand for the thing we’re talking about. Introducing it can just make your expression round about and clunky, giving you lots of noun and verb phrases to decode. Strunk’s Elements of Style says “Vigorous writing is concise.” The same can apply in programming.

Posted in Uncategorized | Leave a comment

Writing To A Binary Stream In C/C++: Harder Than It Should Be

Posted on February 2, 2015 by martincmartin

Suppose you want to write some code to communicate using a binary protocol. You would think C (or C++) was a natural language for this. After all, low level data manipulation is one of it’s strengths. But it’s surprisingly hard to get this right — and surprisingly easy to write code that works now, but might stop working in the future.

Here’s a simplified version of the header:

struct request_header {
    uint8_t magic;  // Always 0x80
    uint8_t opcode; // e.g. get, set, add, etc.
    uint16_t key_length;
    uint32_t body_length;
};

How do you format a packet to send? Here’s the most straightforward way:

void write_get_header(uint8_t *buffer, uint16_t key_length)
{
    request_header *header = reinterpret_cast(buffer);
    header->magic = 0x80;
    header->opcode = 0x00; // GET
    header->key_length = key_length;
    header->body_length = key_length;
}

This is exactly what memcached itself does. The problem is, it’s not guaranteed to do what we want, because it uses undefined behavior. The reinterpret_cast is valid (if buffer happens to be aligned to the alignment of request_header, more on this later), but dereferencing the pointer leads to undefined behavior. Note that casting the other direction — casting an existing request_header to uint8_t * — lets you dereference, which is handy when you’re reading from the wire. But when formatting data to send, you’re out of luck.

On x86 with common compilers (g++, clang++, I assume MSVC) this compiles, runs, and does the right thing. So what’s the problem? If you change optimization settings, or upgrade you compiler, it could stop working, because according to the C++ language spec, the compiler is allowed to generate code that does just about anything, including going into an infinite loop or reformatting your hard drive. And this stuff can actually happen. There are contests for Craziest Compiler Output due to Undefined Behavior, some of the source files look quite reasonable, yet don’t do what you expect. Here’s a good introduction, and What Every C Programmer Should Know About Undefined Behavior.

If the compiler won’t warn you, even with -Wall -Wextra, and the code runs just fine, how can you detect undefined behavior? In general there’s no reliable way. Valgrind finds some of it, but because it only works on the compiled output, it won’t find this. Clang has an “undefined behavior sanitizer,” which doesn’t catch the reinterpret_cast, although it does catch the unaligned writes (see below).

But low level data manipulation like this are strengths for C and C++. So there must be a standard idiom for this, right?

The memcached server itself has this problem when it prepares to send replies. It uses the “union” of the struct with a char array of the same size:

union {
    struct {
        uint8_t magic;  // Always 0x80
        uint8_t opcode; // e.g. get, set, add, etc.
        uint16_t key_length;
        uint32_t body_length;
    } request;
    uint8_t bytes[8];
} request_header;

The idea is to take your uint8_t *, cast it to a request_header *, then write to it through the field. That’s supported in C99, but unfortunately not in C++.

And even in C, it’s only supported with caveats. The struct can have padding, and the amount of padding is up to the compiler and the target architecture.  This doesn’t lead to undefined behavior, but it does lead to incorrect behavior: putting data in the wrong place.  If you restrict yourself to processors with byte addressing and power-of-two word size you’re probably ok, because of the way the fields are laid out: the total size of all fields before the uint16_t, assuming no padding, are a multiple of 16 bits, and before the uint32_t, 32 bits.

To tell the compiler you don’t want padding, you can use #pragma pack But now you’re not using ISO standard C, meaning your code isn’t portable to other architectures. And if #pragma pack actually changes the layout of your struct, accesses to it are unaligned, pretty much by definition. What’s the problem with that?

Even on x86_64, uint16_t has an alignment of 2, which means it’s address needs to be even. If we start our header at an odd address, because the previous request had an odd-lengthed key, we’ll be writing through an odd address which is — you guessed it — undefined behavior, and on some popular architectures can be hundreds of times slower, or can simply seg fault. And even on x86, a compiler is free to assume that the lower order bit of the pointer is zero and store other data there if it likes.

In practice, on x86 such writes turn into movl assembly instructions, which will do the right thing with un-aligned addresses. But again, we’d rather not have to rely in intimate knowledge of the compiler and processor. We’d like to say what we mean in valid C/C++, so the compiler can exploit all that. C/C++ is designed for low level stuff like creating network messages, right? So what’s the right idiom?

The official way is to use memcpy() and trust the compiler to optimize it away:

void write_get_header_with_memcpy(uint8_t *buffer, uint16_t key_length)
{
    uint8_t magic = 0x80;
    memcpy(buffer, &magic, sizeof(uint8_t));  // Not needed for uint8_t, but I like the consistency.

    uint8_t opcode = 0x00;
    memcpy(buffer+1, &opcode, sizeof(uint8_t));  // Not needed for uint8_t, but I like the consistency.

    uint16_t key_length_network_order = htons(key_length);
    memcpy(buffer+2, &key_length_network_order, sizeof(uint16_t));

    uint32_t body_length_network_order = htonl(key_length);
    memcpy(buffer+4, &body_length_network_order, sizeof(uint32_t));
}

Because memcpy needs an address, we need to create temporaries, so every line turns into two. If we’re not worried about padding problems we can use offsetof(), otherwise we need to compute the offsets ourselves. This is pretty verbose and error prone.

Helper functions can make things a little better, e.g.:

void write_uint16_t(uint8_t *buffer, uint16_t value)
{
    int16_t value_network_order = htons(value);
    memcpy(buffer, &value_network_order, sizeof(uint16_t);
}

And you can introduce constants for the offsets, to make things a little more readable. But it’s still harder to read than the struct version.

You could also write the entire header in a local variable, then memcpy() the entire thing to the buffer, and hope the compiler optimizes out the copy. I tried this, and in simple example code, it worked! But in production code, with argument checks and returning the address of the next byte to write to, neither gcc nor clang were able to optimize away the memcpy().

So in the end, people mostly use the struct, assume there won’t be any extra padding as long as the total size of all fields before a given one is a multiple of the field’s size, with the union (most often, because it works in C) or the reinterpret_cast, and that writing to unalinged memory won’t cause any problems. This is exactly what memcached itself does.

Posted in Uncategorized | 3 Comments

In Defense Of Implicit Code In C++

Posted on July 6, 2012 by martincmartin

tl;dr: When C programmers start using RAII in C++, they’re less productive at first because they don’t think of return; as cleaning up and returning, just returning. They blame the language, but they just need to adjust their mental habits a little. The problem isn’t C++ (it’s got lots of other problems), it’s just that they’re trying to write C in another language. Then you can keep the resource handling code separate from your main logic, you’ll get it correct a lot sooner, etc.

At work we’re having a debate on what language we should use to implement our software, C or C++. There has been a lot written about why C++ sucks, and it really is a bloated language with a lot of traps for programmers at all levels of experience. But I believe that when it comes to writing good, efficient, system-level code, using the right set of C++ features can make your code better. And Resource Acquisition Is Initialization is one of those.

In RAII, the compiler inserts implicit calls to destructors, so you don’t need to remember them, and therefore can’t forget them. But this can lead to confusion, because now it’s harder to know what a particular line of code does. People with a C background look at a statement like “return;” and think “that returns from the function,” not “it cleans up and returns.”  And until they change that mental habit, RAII is murky, confusing and full of gotchas.

Like many things in life, the implicit thing has advantages and disadvantages. Being explicit has the benefit that every line of code is “self contained.” To know what it does, you only need to look at that line of code. At a previous company, we had some horrible implicit code, where a[n] = b[n] created all sorts of temporaries and did all sort of magic under the hood, because operator[] and operator= were overloaded. That style of code was promoted by those who were quick to perceive the benefits of abstraction, but slow to realize its costs. To understand the performance of that one line — where a and b were rows of a matrix — you had to find and understand 5 different classes. That was just too much for most people, and so a lot of sloppy code was written, which we spent months trying to understand and speed up.

So there’s a cost to implicit, but what problems does it let you avoid? With explicit resource management, there’s a convention that when a function allocates some resource, then later encounters an error, it should free the resource before returning. With C, you can’t tell the compiler that explicitly, so you have to do the work of putting in the free() call in all error paths. This means you might forget to put it somewhere, or if someone adds a new error handler they might forget to call free(), or if they reorder the code they might overlook a call to free() they should have added, etc. So while explicit makes it easy to see what a line of code does, it doesn’t make it easy to see if there’s anything missing.

It also means the code that implements separate concerns are mixed together, making it harder to get any one of them correct. The logic for allocating and freeing is mixed in with the main work of the function, as well as error checking. If you’re looking at the code and thinking about the typical, non-error case, it’s easy to overlook a problem with error detection or resource management. So when I’m writing or reading the code, I find it hard to understand all aspects of the code in a single pass. Instead, after I’ve read the code once, I need to do a separate pass of “now did they remember to call free() everywhere?” With practice, you can keep a stack in your head of all the things allocated up to this line of code, and a mental checklist of all the error conditions you might want to check. But that’s a set of mental habits that we need to develop, and before we develop them, we get a lot of leaks and missed error checking.

An alternative is to specify all the steps in one place, e.g. a class definition, then have the compiler insert them for you. That’s what happens with std::unqiue_ptr, or a class to lock and free a Mutex. So it means that when variables go out of scope, things happen that aren’t explicitly listed in that line of code, so return ; can perform arbitrary computation, as can }. That means you need to change the way you look at such statements, because new code conventions develop. But just because those code conventions are new, and different from what you’re used to, doesn’t mean they’re bad. Any tool takes a little getting used to, and until you do, there will be confusion and gotchas. I’d say the mental habits of the “implicit” approach are different — and easier for people to learn. Which is why I like the implicit approach in moderation.

So it’s true you have to learn something about the order of constructors and destructors to get std::unique_ptr right. But it’s actually pretty easy, because it’s designed to do the obvious thing as much as possible.

Posted in Brain Rental | 1 Comment

Finding A Job You’ll Love: Negotiating An Offer

Posted on January 20, 2010 by martincmartin

So you did well in an interview and they’ve made you an offer. And now you just have to decide which offer to accept. Right?

Well, not quite. You can always go back to your top choice and ask for more. And now, when they’ve decided that they want you but before you’ve accepted, is the best time. Once you’re employed, you’ll have very little leverage. So, even though your value to the company goes up dramatically in the first couple years, as you learn more of the details of their code and systems, you won’t get much of a raise.

So you’d better negotiate now. Most companies will ask how much you’re currently making and offer you a small increment on top of that. They’ll even ask you what your “salary expectations” are, meaning they’ll ask you for the smallest increment that you’ll accept! I’ve heard it said that you should respond “I hope to be paid fairly” and otherwise refuse to give them a number. Maybe you can explain to them that you feel the process is unfair, and that you won’t give them a number any more than they would if you asked “What’s the most you’re willing to pay me?”

I’ve never done that, because I’ve been worried that I would come across as difficult to work with, or just generally being obstructive. But as much as possible, I try to follow the principals in Getting to Yes. You should all go out and read that now: You’re guaranteed to have to negotiate something at some point in your life, such as buying a house or a used car. The short version is:

  • Emphasize objective criteria. Look for salary surveys on the web. The tricky part is finding a job description that accurately describes your job, but you should be able to get a range of possibilities. Here’s a tip: most organizations believe they do a thorough job of interviewing people, and thus end up with people who are above average. So once you’ve found the salary range, you should be able to say “I think my background and skills match this position more than most of these people, so I think a fair salary is somewhere in the upper end.”

    Emphasize that you want to be paid fairly, not that you’re on the fence about going there. It’s not about “would I still work for you if you didn’t increase the offer,” it’s “I want to be paid what I’m worth.” In a market based economy, “what I’m worth” is more or less what the market is willing to bear, so…

    Get an offer from another company. This is part of why you can’t just let a recruiter do the whole search for you, they’ll only get an offer from a single company. When another company makes you an offer that’s a little more than what you’re making now, go back to the first company and say “If you offer me a little more than that, I’ll be happy to work for you.”
     

  • Invent options for mutual gain. Salary is the big one that everyone focuses on, but its often hard to get approval for more than a small increase in salary. Look at the benefits that other companies are offering. How many holidays, vacation days and sick days? Will they pay for parking or a subway pass? Do they have a 401(k) match? If you’ll be taking a hit on any of those, compared with either your current job or other companies you’re applying to, bring it up. If the company can’t address them directly (e.g. they can’t institute a 401(k) matching program just for you), you can use them to argue for greater salary.
     

    • And with that, and the info in the rest of the “Finding A Job You’ll Love” series, I hope you’ll be a little better and finding and landing that great job. Good luck, and please let me know if you found it useful!

Posted in Brain Rental | 6 Comments

Finding a Job You’ll Love: The Interview

Posted on January 8, 2010 by martincmartin

It’s best if you can do some prep for the interview. Try to understand what the company’s product is. It’s amazing how cryptic a web site can be, especially if it’s enterprise software in some industry you don’t know. Still, make an attempt, and ask about anything that’s confusing. The fact that you’ve understood some basic things about their product, and that you want to understand more, will set you apart. Of course, it will also help you understand what you’d be doing if you worked there.

Then you should try to read up on the sorts of questions people like to ask. For some reason, people ask algorithms questions far out of proportion to how often they come up in an actual job. Pick up a copy of The Algorithm Design Manual
and read the first section (chapters 1-10) during lunch or in the evening. Even if you only get half way through, you’ll be better prepared than most.

The interview is lopsided: you’ll spend almost all your time answering their questions and only have a little time to ask yours. That’s ok. If you’re still uncertain after the reverse phone screen and the in-person interview, you can always ask to talk to someone on the phone another day.

Keep in mind that they’re trying to figure out whether to hire you. So while it’s good to mention how great this job would be for you, you want to emphasize how great you would be at this job. They don’t really care that you’ve always wanted to learn Lisp and this job would let you do so. They care that you can design & implement software, quickly understand complexity, etc. With that in mind, ask yourself “what are they really trying to get at with this question?” For example, if they ask about a particular job on your resume, feel free to say that another job is probably more relevant and ask them if they’d rather hear about that.

Generally you’ll meet 5-6 people for an hour each, and there are two great questions you should ask everyone. After the initial small talk, ask “What does someone need to be really successful at this position?” Not only will many interviewers think this is a good question for a candidate to ask, but they’ll tell you what they’re looking for. For the rest of the hour, when answering questions, try to answer with stuff related to what they’re looking for. Also, write down the answer. You’ll want to refer to it much later when you’re trying to decide between the different places you interviewed at.

Save the second question for near the end of the hour. “What is the best and worst thing about working at X?” Again, you should write down the answer, because you’ll have 5 or 6 of them from every company you interview at. Both the best and worst thing are important to consider.

Beyond that, here are some good questions to ask:

  • What are the day-to-day tasks I’d have?
     
  • What day-to-day tasks do you typically do? What have you been doing over the past month?

For a manager:
These were covered in the Reverse Phone Screen post.

For the tech lead:

  • How is scheduling done? How are estimates and deadlines created?
     
  • How are tasks divided up among programmers?
     
  • Who does the overall design/architecture?
     
  • Who does the design/architecture of individual contributor’s tasks?
     
  • How much time do leads spend with their programmers?
     
  • Do you do code reviews? How are they done?
     
  • How much do you look over people’s check ins?
     

Good luck, and try to be relaxed and friendly. But most of all, focus on the technical puzzles they give you. If you got into programming because you enjoy that kind of puzzle solving, hopefully the puzzles will at least be interesting.

Posted in Brain Rental | 1 Comment

Finding A Job You’ll Love: The Reverse Phone Screen

Posted on January 7, 2010 by martincmartin

Once you’ve sent out resumes, you’ll hopefully get a few people interested in phone screening you. You’re really best off if you prepare for these and for the in-person interview. Get a relevant textbook and start reading it in the evenings or on your lunch break. People seem to love algorithms questions, so get a copy of The Algorithm Design Manual and read the first few chapters. For my Endeca interview, I started reading Introduction to Information Retrieval. I got through about 5 chapters of it, and one of the interviewers started quizzing me on it. When I answered all the questions without thinking, he said “I’m trying to see how you do on a problem that you don’t already know the answer to, so let’s switch to something else.” Still, I’m sure it reflected well that I knew my Information Retrieval stuff.

The phone screen is for them to decide whether or not to bring you in for an in-person interview, and you want to help them with that decision. So you’ll spend most of your time answering their questions. You should ask a few questions of your own, but don’t spend more than 5 or 10 minutes on that.

However, once you hear that you passed the phone screen, you should do a reverse phone screen: before you schedule the in-person interview, ask to talk to the person who will be your manager if you join. Or you could ask for a tech lead, if you those are the sorts of issues that you care more about. For managers, my favourite questions are:

  • What’s your management philosophy? This is so open ended that it can be hit or miss, but with the right person it can be really insightful. Plus it gets them thinking, which will help them answer the later questions. Then ask What’s company X’s management philosophy? as an individual’s style may not represent the culture of the company as a whole. Some good follow up questions are What management books would you recommend? What do you like & don’t like about each one?
     
  • How do you figure out what to promise to the customer and when to promise it? There’s a sad truth about software process: It’s impossible to estimate exactly how long a feature will take to build. Even half way through the project, most organizations are off by up to a factor of 4. So, if they promise a fixed set of features on a fixed date more than a month or two away, you’ll probably end up being stressed and working crazy hours to deliver, and then the deadline will be pushed back anyway.
     
  • Do you use an Agile development process? Why or why not? What specific processes do you use? Whether you like Agile or not, you should know what you’re getting into. Also, it’s amazing how many people say “yes we do [insert buzzword here]” but when you question them on it, they don’t understand it at all. I had the CTO of a 500 person company tell me they didn’t use Scrum because it was a heavyweight process involving Gantt charts.
     
  • When an urgent task is supposed to take two days for a task, and half way through the second day the developer says “I don’t think I can finish it today,” how do you respond? I’ve been in this situation and had my boss just look at me, with a serious look on his face, and say “It has to be done today.” So now it still isn’t going to be done today, but its somehow my fault.
     
  • When a developer is working hard but not getting far, how do you notice? It’s actually quite tricky to know how productive a developer is. Some developers pile on the quick hacks, so it looks like they’re making lots of progress. On closer inspection, their code is full of bugs, and incredibly difficult to understand, debug or extend. If you don’t have design reviews, code reviews, and/or QA from the start, this can slip by until you think you’re almost ready to ship. Other developers keep up on the latest technologies, and are able to say “this is a known problem, let’s use X for it rather than inventing our own version of it.” But more directly, if you don’t have a detailed schedule, then you don’t know whether you’re behind schedule. So dig into it. When do they do QA? Who looks over the check ins? What about people who don’t just code up the first thing that comes to mind, but spend a little time looking for a better way?
     
  • Once you notice, what do you do?
     
  • Here are three developer personalities from a post on Reddit. I think they do a great job of describing personalities I’ve seen. What role, if any, would they have in your company?

    Coder: values velocity. Wants to “produce code” and “get things done.” They are proud of working hard, staying late, generating thousands of lines of code, and of knowing dozens of obscure APIs by heart because they type them in all the time. They’re great on anything that’s a clown fight of interacting APIs, like LAMP stacks or AJAX apps. However, they won’t produce a memory allocator that you’d want to use as anything but a prank.

    Programmer: values correctness. Wants to “solve problems” and “do it right.” They are proud of working efficiently, being caught up enough that they don’t have to stay late, and deleting code. They’re good at algorithmic code like a memory allocator.

    Researcher: values knowledge. Wants to “find problems” and “publish.” They are proud of producing new knowledge, and sharing it. They don’t stay late at all.

    Also, what do their career paths look like?

  • What’s the right level of pressure for your developers? In other words, should projects be slightly under staffed? Should deadlines be aggressive?
     
  • In practice, how many hours a week do people typically work? You can ask this near the end of the interview, although hopefully not as the last thing. Asking it earlier may make it seem like you care more about leaving on time then on getting the job done.
     
  • Can you give me an example of someone under you who has worked to improve their skills? For example learning new software, going to conferences, etc. What’s the right amount of time for someone to spend improving their skills?
     
  • Do you do anything to explicitly identify “best practices”? Do you adopt best practices from outside your company? Can you give me an example of a practice or two you’ve adopted? You want to see if they learn from their mistakes, and the mistakes of others.
     
  • What’s the best and worst thing about working at X? Both the best and worst are worth paying attention to.
     

For a tech lead, see the list of questions in my next post, about the in-person interview.

The big advantage of the reverse phone screen is that it’s quick. No one will miss you if you’re not at your desk for an hour, so you can do a lot of them. In-person interviews are half a day to a full day, so you have to take some PTO time for them. By doing reverse phone screens, you can consider many more companies than you normally would.

Posted in Brain Rental | 6 Comments

Finding A Job You’ll Love: Locating Opportunities

Posted on January 4, 2010 by martincmartin

I’ve changed jobs a bunch of times over the last few years, and now I’ve found one I’m going to stick with for quite a while. So I thought I’d write up the tricks and tips I’ve learned for anyone in a similar situation.

The first thing to do is figure out what you want. You might think this is easy, or that you already know. But as I took job after job that seemed good then turned out bad, I realized that the stuff I thought was important wasn’t really important, and other things I wasn’t even considering were essential. I’ve noticed that, as people progress through their careers, they often start by focusing only on the technologies (“I want to work on cool stuff!”) and, over time, realize that compatibility with their boss and co-workers as more important.

So for every job you’ve had, write down a detailed list of everything you liked and didn’t like about it. Think back to every project you worked on, and every person you’ve worked with. What did you like about them? What did you dislike? Did you learn something new? When things didn’t work out, did your boss help or just put pressure on you? When you made suggestions, did your boss give you good reasons for not following them? Think about each of your co-workers. When did you enjoy interacting with them, and when was there friction?

I’ve come to realize that “process” is the only “must have” aspect of a job for me. I can’t be happy in a “get a lot of good people and set aggressive deadlines” place. I feel ownership of the project, not just my part but the whole thing. When I’m forced to create spaghetti code that is then full of bugs and takes forever to extend, when I’m forced to work crazy hours but can only produce shippable code very slowly because of the spaghetti, it bugs me. I take the failure personally.

Another thing I’ve learned is that job ads are almost useless. They tell you what technologies you’ll be working on, and they always say the company is great, but nothing about what your day to day work will be like. How much politics and bureaucracy? How much overtime? If you come up with a clever solution to a problem, will people be happy & let you implement it? Or will they give you blank looks and consider you weird?

Whether you prosper under a sane process, cutting edge work, or perks (massages and free snacks!), the job ad won’t tell you. Recruiters might help if you find a really good one that takes the time to understand what you’re looking for. They’re rare, but they’re out there.

So you might be tempted to do a shotgun approach: send your resume to every job that isn’t completely out of the question. But that’s a bad idea. The people reading your resume are sifting through hundreds of them for every open position. The way to stand out is to tailor your resume to them, and that takes time.

So in the end, the way I find positions is:

  • Talk to friends, see if they know of anything. If you don’t need to keep your search a secret, you can post on Linked In/Facebook/Twitter that you’re looking for a job and would like suggestions.
     
  • Look at lists of “best places to work,” such as the Boston Globe’s or the Boston Business Journal’s. Of course, they may have a different definition of “good place” than you do, but that’s ok, we’re just getting a list of candidates. We’ll look at all of them more closely soon.
     
  • Search indeed.com and simplyhired.com for jobs that look interesting. This won’t tell you about their culture, but you’ll filter for that later.
     
  • Work with a really good recruiter.

Before you send out any resumes, try to narrow down the list. Find the company on Linked In and see if you’re connected to anyone who works there. If so, chat with them on the phone. Ask:

What’s the best and worst thing about working at X? How many hours do people actually work per week? How much time is spent bug fixing? Does your boss have a technical background? How do you come up with schedules and release dates? How do you decide what to promise to customers and when?

and anything else that’s important to you. Also look for people who have left the company in the last few years and talk to them.

When sending out the resume, make sure you tailor it to the type of company. I usually have two resumes, one that emphasizes my machine learning/AI background, and another emphasizing my general programming skills. I also tailor each cover letter to the company. You’d be amazed how many cover letters are so generic that they don’t even mention the company’s name. If you mention the requirements from the job ad, you’ll set yourself apart. And you should also “connect the dots,” describing how things from your background relate to the requirements. Hiring managers have to sort through hundreds of resumes, so they’re really skimming each one, and may not see the connections you’ve seen. Your cover letter should be a “cheat sheet.”

When you send out your first resume, a clock starts ticking. If they like you, they’ll want a phone screen, then an in-person interview, then make you an offer, and want you to accept. If you try to delay it while you search for other opportunities, they’ll take that as lack of excitement and it may hurt your chances. So make sure you’ve found your list and narrowed it down as much as possible before you send out resumes or contact a recruiter. Then, send them to all companies on your list at the same time and contact recruiters that day.

Posted in Brain Rental | Leave a comment