Starling Software K.K Language:

Interview Process

This guide to Starling Software’s interview process will both help you know what to expect and prepare appropriately. The process is flexible; if for some reason something here doesn’t work for you, just contact us and let us know what you think would be an appropriate alternative.

The interview process runs in graduated steps, the initial ones designed only to weed out the least suitable candidates, and the later ones intended more to look for positive signs that we want to hire. Our hope is that this will save you, as well as us, time and effort.

1. Investigation by Potential Applicant

If you’re interested in applying to Starling, the first thing to do is read over our web site carefully. First look at what we do and what we build, for which positions we’re hiring, and decide if you’re interested in working here and the position suits you. Next, read this page carefully, and make sure you submit everything we ask for in section 2 below.

We receive a surprising number of resumes from people who quite obviously have not bothered to look at our web site and have no idea what we do, what positions are open, or what to include in the initial application. These generally get ignored.

2. Resume, Cover Letter, and Programmer Competency Matrix

Short and/or informal resumes are fine; they’re not a big part of our decision process. Lists of acronyms and product names are less useful than a detailed technical description of projects on which you have worked. Please include the salary range you’re looking for here or in the cover letter.

Your cover letter should tell us why you want to work at Starling, why you feel you can benefit us, what you’re aiming to do in your career over the next year and five years, and how you think we can help you with that.

Along with these, we require that all candidates must include an evaluation of yourself from the programmer competency matrix. (Kudos to Sijin Joseph for the original version of this.)

We suggest using a format for your answers similar to this:

AreaScoreComment
data structures2 
algorithms1.5 
source code version control4  I wrote Darcs.
IDE-1  I hate IDEs.
API0 
codebase knowledge?  I don’t understand this question.

Here, as with the resume, don’t get too worked up about the answers; we use this only as a rough guide, and certainly won’t disqualify you because you come out with a one instead of a two on some particular row.

Submissions in plain-text, PDF or PostScript formats are welcome; Microsoft Word format is also acceptable, but we’re not particularly fond of it, and it’s likely to make your resume less readable depending on which program we use to view it.

For details on where to send your submission, please see our application-address page.

3. Code Samples

We will ask you to submit two small programs, described below. These can be submitted with your resume and cover letter, or after we’ve reviewed and responded to them. You should also feel free to submit other code (or pointers to it, if it can be downloaded) if you have something you’d particularly like us to see.

4. Initial Interview

If your resume and cover letter seem interesting to us, and your code samples are adequate, we’ll have you come in to our office for an in-person interview. This is a discussion interview only (you’re not expected to write any code during it), and generally takes anywhere from 45 minutes to two hours. We’ll expect you to be able to talk in some detail on a technical topic interesting to you on which you are fairly knowledgeable, so please come prepared to do this. We also welcome questions from you about Starling and what we do here.

5. References

If you pass the initial interview, and you decide to proceed, we’ll ask for at least two references. At least one of them should be someone who has direct experience working with you on technical projects and has technical knowledge at your level or higher. We will contact these references before moving on to the next stage.

6. Programming Interview

The final, and longest stage of the interview involves coming in to our office for a minimum of a half day and work with us on one or more of our current projects. (You will be required to sign an NDA for this.) This is done in a pair-programming format, and we will expect you to drive for at least part of the time. Since one of the things on which you will be evaluated is your skill using your programming environment, we encourage you to bring in your own notebook computer, if you have one, so that you’re working with a comfortable configuration. If you cannot to bring in a computer, we’re happy to provide a Linux workstation (running a recent version of Ubuntu) and give you whatever time you need to get your environment set up to your satisfaction.

If you bring in your own computer, as well as your preferred editor and so on, you’ll also need to have installed:

Sample Programs

Haskell

Information on Haskell can be found at haskell.org. We’ll be testing your program using GHC.

The file input.txt contains lists of words, one per line, in two categories, NUMBERS and ANIMALS. A line containing just a category name indicates that the words on the following lines, until the next category name, belong to that category. Read this file as input (on stdin) and print out a) a sorted list of the unique animal names encountered, and b) a list of the number words encountered, along with the count of each. Feel free to chose your output format; a show of a Haskell data structure is fine.

Ruby

Information on Ruby can be found at ruby-lang.org. We’ll be using the standard interpreter, version 1.8, to test your program.

Write a network server to which we can telnet that reads one-line commands from the input and prints appropriate responses. This server need not allow multiple simultaneous connections, but should wait for a new connection once a client has disconnected. Use the the standard POSIX/Berkeley Sockets API for setting up the sockets.

This server should accept three commands:

  1. R expr” should evaluate expr as a Ruby expression and print the result back to the client. For example,

    R h = Hash.new; h\[:a\] = 'foo'; h

    should print

    {:a=>"foo"}

    to the client.

  2. S expr” should evaluate expr using system and then print the output of that command (stdout) to the client, followed by the return value of the program that was run. For example,

    S ls -!

    should print something like

    "ls: invalid option -- !\nTry 'ls --help' for more information.\n"
    exit value: 2

    back to the client.

  3. H” should print a history of the entire session’s commands and output. If the above two commands were executed in sequence, the H command should result in:

    R h = Hash.new; h\[:a\] = 'foo'; h
    {:a=>"foo"}
    S ls -!
    "ls: invalid option -- !\nTry 'ls --help' for more information.\n"
    exit value: 2

These problems are not intended to be tricky; they are intended to be representative of simple, every-day programming tasks. If something seems odd about a problem while you’re working on it, please feel free to contact us for clarification.