Random thoughts that may help… This is long, so feel free to skim to any part which seems worthwhile.
- mainly in Europe (Germany/Netherlands). (I come from the US, but never did a test there.)
- mainly startup-y product companies
- As @sveri mentioned, try to use your network to meet someone inside the company. Companies are modern secret societies, and applicants are generally trained to say what the employer wants to hear. So the predictable outcome is everyone misleading each other. :)
- Also, I frequently recommend (as @sveri does) “Getting to Yes.” My copy’s loaned out, and I sometimes give presentations on its ideas.
These give you every advantage to hit them out of the ballpark. (Unless you don’t have much spare time or aren’t yet experienced enough.)
After joining a company, I always ask to see previous/future applicants’ solutions. My impressions (YMMV):
- A few deliver something professionally polished. Enough-but-not-too-many tests/docs/etc. Clean design. They know what you’re looking for and deliver it.
- Many almost solve the requirements. But they don’t exactly follow the instructions; solutions lack polish.
- Many basically fail to deliver, though they have something to present. (Sometimes they “took a risk” and used unfamiliar tools. Or had a too-interesting idea for the timeframe.) You can still get the job though! If people like you otherwise or you’re a “junior programmer,” especially if the company’s aggressively hiring. But it weakens your negotiating position.
- A few submissions simply can’t work. (If there’s things like phone screens in place, these are generally filtered out before the applicant spends their time.)
Helps to write down ideas and prioritize by impressiveness vs. effort.
Can help to look at your work cynically afterwards and polish it to preempt criticisms. (Not necessarily via code. You can proactively say, “I intentionally didn’t support X because this is basically a prototype.”)
They often suggest a time-limit, like “don’t spend more than 8 hours.” To save time, you can rip code from old projects, and have a template/skeleton with everything generic set up. Maybe zillions of deps in project.clj; then remove unused ones before delivery to avoid criticism.
Typically, you get to present your solution. “How to Speak” has some helpful ideas (incidentally by an AI prof who wrote a Lisp book). I often skim it before giving a presentation, to get into a good mindset. (The mindset: I’m here to help people discover something intellectually entertaining. Not to sell myself.)
For one presentation, they asked me to evaluate my app with these metrics: performance, maintainability, reliability, security, extensibility. I wrote a lot of notes on what each of these mean, then edited them mercilessly to the best few points on each topic. Often totally OK for your app to have bad security/performance/whatever due to time constraints; all that matters is you’re clearly aware of it, and offer tactics to fix it. (“Use a profiler to discover performance bottlenecks, because guesses notoriously turn out wrong…”)
Interactive demos (like inspecting data or changing things) can spice up boring code review.
“Active listening” is good. Imagine the sort of person you’d want to work with. Don’t you enjoy people who try to understand what you mean & charitably interpret your words?
Applicants sometimes shake nervously. Most interviewers will find that sympathetic. I take it as a symptom of a hazing ritual. (“You survived this quest and are one of us!”) The applicant is scrutinized far more than the team; it’s not like any teammate has to offer themself to a competence test which you judge, or their workplace to a dysfunction test.
When presenting to a group of developers, there’s probably always someone ready to point out if you don’t have tests. :)
I did this a couple times; worked on a little project taken from their daily work. Once I was paired with helpful teammates; the other time I just implemented the requirements and could ask the lead dev questions.
They were:
- Lead dev said: “Install this distributed queue we want to test out and use it from Python.” (Luckily I had Debian under VMWare already running; installing the queue was painful.)
- Paired with two different people (I’ve seen giving presentations at conferences) and:
- “Hmm, I’ve got this problem, let me talk it out with you and hopefully we can come up with more clarity so I can decide which alternative to choose…”
- “Hey could you please to authenticate to our system using whatever tool you like, and test it out? Not sure if it works. No need to know OAuth(2?), I’ll walk you through it.”
For the last one, I was still uncomfortable with pairing, so was keenly aware how much I fumbled with Emacs. (Nowadays, my little fumbles just feel amusing.) I also noticed from pairing that using an IDE turns out to drain some mental power, so the “non-driver” has a mental advantage. But I was paired with a kindly partner, so didn’t feel really bad. Walked me through it all; I could just focus on the mechanics (basically grabbing clj-http, looking at the docs, moving data to the right places).
You get to see their daily workflow and likely some of their work. Not nearly as stressful as other ways of interviewing; perhaps because you’re supposed to have solidarity with coworkers. (Whereas being a gatekeeper is antagonistic: giving tests like a sphinx.)
Once an interviewer suddenly sprang on me something like: “return all permutations of a list.” Performance didn’t matter. I suddenly blanked for maybe a minute. (“What was that fancy way in the Knuth book, with the rotations?” I wondered.)
I apologized saying the sudden transition to a puzzle caused me to blank, and the interviewer obliged by reading a newspaper. Then I kinda hacked out the common way with recursion in a few minutes, which I felt apologetic about. Later, I learned that the next fastest person took like 30 mins. (They had 4 other programmers at that point. Some of them were more advanced than me in many important skills, but I guess I had more experience in small “code golf” things. These puzzles are poor at testing ability.)
Another time, someone asked on the phone, “What does ‘real-time’ mean?” I think the purpose was to discover whether I’ll hit his pet peeves. (They weren’t happy that it usually means “fast” nowadays; preferred something more like “guaranteed time bounds.”)
Can certainly be an advantage if they like your lib. Employers should consider critiques of emphasizing it as a metric though.