Earth-shattering project ideas. Resumes. Things in between.
A letter like this could have many audiences. The one audience this letter is not for is my employer. They have nothing to do with this stuff. And just to be clear, anything said here is not meant to reflect on them in any way.
Legalese over. Now to the fun stuff.
There are at least four audiences I intend to address. These are:
Be prepared.
If you’re looking for a job doing X, be prepared to demonstrate how proficient you are at doing X. You’d be surprised how many candidates get stuck at this step. In particular, if it’s a programming job, expect to write some code.
If the video-conference interview is at 11:00am two time zones away, then figure out what time that is in your home time zone and be on time.
Be ready to talk, and not just in short-answer form. You’re going to need to communicate in depth on the job, and besides the length of your answers speaks to how well you know your subject. But don’t just fill time: the interviewer has priorities too. This is a conversation, not a diatribe.
Most jobs do not require a native-like language proficiency. If you’re interviewing for a job in a second language, then the interviewer will bend over backward to help you understand and be understood. But you must be able to return the favor. I have had to turn down candidates who looked great on paper but didn’t manage to string four words together during the interview.
We get it: your resume is an advertisement. It got you the interview. Now we need to develop the trust that your resume is aligned with reality.
If your resume says you have seven years of experience doing FOO, then you’d better be prepared to demonstrate considerable skill with FOO, lest ye be relegated to the marketing department on the 11th floor of a 9-story building.
In my world, if the interviewing team infers a stark discrepancy between the experience you claim and the way you perform during the interview, the aforementioned trust starts dissipating quickly. The impact to your chances of a job offer are left as an exercise for the reader.
Therefore, I beg you: Tell me not only what tools (e.g. languages, frameworks) you used, but also how you used them. Did you spend those five years writing random short one-off scripts to automate the tedious bits of manual processes? Or did you have a devoted user base who critically relied on a complete system you designed, developed, and maintained? How did your work impact those around you in the organization, and how did that translate to mission effectiveness?
There are some organizations that expect to train every employee from the ground up. These can be some of the most eminently fulfilling places to work. The United States Military is a perfect example. (Digression: There are some deeper forces at work in this particular example. There are others.) However, most of us technical folks will be expected to bring some measure of prior skills to the interview.
Therefore:
Know your craft and know your tools.
If you interview for a programming position, you’ll be asked to write some code. You need to know a programming language. In my world I frankly don’t care which language you interview with, but I am going to assume you choose the one you know best, or are most comfortable with, or are happiest with, or most agree with the design principles of.
You will probably be sidelined if you seem unaware of, or lack fluency with:
If you can’t remember the basics, pick a different language or brush up before the interview. Excessive reliance on an IDE’s code completion features is also a red flag: it’s not meant to be a crutch.
If you claim two years of experience with relational databases, expect to write some SQL DML and DDL. If you claim five, expect to normalize a poor schema, “solve” some notional performance problems in a couple different ways, and so forth. At ten years, expect to have some extemporaneous conversations on deep topics. At twenty, you’re teaching the class.
Working at all levels of a technology stack means working with a bunch of different kinds of technology. With something somewhere in the stack always changing, you’ll see a much greater rate of change in what you must know to be effective.
It will be an eternal struggle to stay current.
Some other things are also eternal.
Expect to be grilled on the eternal bits.
Do not volunteer personal information relevant to equal-opportunity protected attributes. (These are things like race, creed, religion, national origin, medical status, and more. For a complete list, consult your local HR office.) The interviewers do not want to know; in fact they really want to not-know. It makes them uncomfortable, because the company may not base a decision to hire-or-not on these attributes. On the other hand, depending on the expected maturity level for the job, you may be judged inconsiderate or worse for having put the interviewers in a bind.
Suppose you think you’ve been asked. 99% of the time, this is a miscommunication. Interviewers (and especially technical interviewers) are not HR professionals; they are technical professionals taking time away from their normal jobs. They’ll have some coaching, but they may not realize the potential for a question.
Most often, you’ll have a chance to ask questions at the end. You are judged by the nature of your questions. During this “reverse-interview”, try to glean as much as you can that will help you understand if the job is a good fit for your career and motivations. In particular, do not focus on pecuniary questions before someone has offered you a job.
At this point, DO NOT launch into questions specifically pertaining to EEO protected attributes.
PS: Something closely akin to that made-up example may or may not have happened on my watch.
Have a plan. Work the plan.
Be ever polite: You never want to exclude present company, lest you find yourself excluded from your own.
The Iñigo Montoya method is:
| Element | Movie Example | Interview Example |
|---|---|---|
| Polite greeting | “Hello!” | “Pleased to meet you, Mrs. Throttlebottle.” |
| Brief introduction | “My name is Iñigo Montoya.” | “I am __, and I hail from __ department.” |
| Personal recognition | “You killed my father.” | I was impressed by your paper on gluon-lepton interactions. |
| Manage expectations | “Prepare to die.” | This interview is for the XYZ position, and you’ll be expected to ABC. |
| Invitation | “You will reach the top alive.” | Here’s a scenario… |
| Conflict | “En Garde!” | Write a function… Time and space complexity. Top-down design. |
| Escalation | “I am not left-handed.” | O-O Design. Unit testing. Proof of Correctness. Architecture. Models of Computation. |
| Denouement | “I am not left-handed either.” | Methodology. Maintenance. Garbage collection. Compilers. Group dynamics. Process Calculi. Management. |
| Conclusion | “I can’t have you following me.” | “Any questions for us?” |
Do not let the candidate talk you into unusual acts or granting unusual consideration.
You want to cut that off quickly. Maybe tell him it would disqualify him from consideration. (Maybe he’s already disqualified himself.) And then inform the powers-that-be of what happened.
There’s a strong temptation to adapt your choice of question to the résumé and candidate’s alleged strength. This is unreliable, and it can get you in an awkward pickle. It’s probably fair to ask database questions of a database candidate, but for strength it’s probably safer to start at the bottom and work your way up.
So perhaps you’d like some ideas for posing the technical challenges. Guess what: Most instigate an arms race: As soon as a question gets popular, it gets posted around the internet and all the lemons learn it by rote. So we’re looking for ideas that thwart the trope. Here are a few:
Look at behavior such note-taking and requirements-clarification. (Having the agreed requirements in English on screen probably saved my bacon more than once.)
Ask the candidate to explain her design decisions along the way. Look for signs of top-down design, functional abstraction, mathematical reasoning… But be gentle. This is a stressful enough time for the candidate. Don’t pick nits. Give breathing room: she may have a different, but still valid, approach to solving any given problem. You’re also interested to see how she recovers from any blind alleys; you don’t see that if you bop her on the nose any time she deviates from your preconceptions.
Combine two well-known problems along a functional seam. For example, fizz-buzz is well-known. Fibonacci numbers are well-known. Lucas numbers are slightly less well known, but they derive from a similar concept. fizz-buzz on those two sequences provides an excellent opportunity for functional abstraction. Efficient fizz-buzz on prime numbers is a nice test of alertness, although the implications are left as an exercise for the reader.
Use scenarios creatively. For example, you might have the candidate develop a simplified abstract computer, and then elaborate on one component (e.g. the hard drive, video display, mouse, etc.) This pretty much can’t be done by rote without picking up domain knowledge. By the way, simulating an abstract “filesystem” has the added advantage of opening up scope for interesting data structures. A keyboard is also rich with opportunity for OO design concepts.
Try to avoid “Aha!” problems. These are the ones that hinge on some simple but non-obvious insight. Computational minute-mysteries don’t tell you anything except whether the candidate has heard this one before. Once someone learns that the hanged man was standing on a block of ice, they will never be mystified again. You light the fuse from both ends at once. Squares have an odd number of factors. The fox won’t eat the lettuce. Need I go on?
The best problems should not require too much explanation. Neither should the best candidates, but they will probe the corner cases to be sure of understanding.
The following are fun little challenges but their suitability to an interview is an open question:
The following questions are to be reserved for candidates of only the very highest caliber:
Get organized in advance. Know who will ask what, and in what order. Plan how you will adapt to the unexpected. Coordinate your actions in advance.
They say it’s a numbers game. If you want to get the best numbers, you’re going to have to submit the best candidates.
Excellent pre-screening helps, but obviously tests can be gamed/cheated/coached/crammed. It probably helps to know some of the subject matter. I’ve seen résumés with bold claims that no professional would admit to. I’ve seen claims of long experience with young technology (or job postings that demand as much). I’ve seen “ran a cash register” sold as “maintained mission-critical financial and ERP data system”.
A brief conversation about someone’s actual contributions to their alleged accomplishments can start a conversation: Do they drop buzzwords like Jackson Pollock puts paint on canvas, or can you understand them clearly? Do they slow down to check your understanding? Can they explain some deeper mystery so you can understand it? Do you feel smarter or dumber for having spoken to them?