Hiring Without Whiteboards

Actually, if they spend more than two hours, the question is why. We are happy to see them get interested in the task and dive deeper, but we just don't want to ask for more, that would be unreasonable in our view. It's fine if the code is broken, or has a couple of bugs. (It's best if it compiles though!)

The goal is as much to learn how they think, solve problems and communicate as it is whether they know how to write software.

I'll give one example: One task is to figure out how long it takes to grab the current time from the operating system. We use a rather obscure OS. A candidate chose this and solved it simply (though it's got a couple of points to mind), but then he got curious and wanted to know whether a virtual machine had a different timing and then what the performance on a different operating system was. He told us that he spent about 8 hours altogether. I felt a bit bad on one hand, but on the other, it's exactly what we like to see: Solid programmers who love programming technology for its own sake.

Adding my own personal experience.

At the end of last year I wanted to change jobs but I was paranoid about my raw algorithm knowledge. I've been a consultant for over 15 years. The last company I worked at for a decade. I've developed software given a specification, worked with teams to design applications, lead teams, presented to management of companies, and even was part owner in a company -- but I never was good at rote memorization.

I know my limitations and I know how to find answers.

So, for 4 months I practiced online programming problems, read interview books, and had my wife quiz me nightly. The nightly quizzes were whiteboard answers and I had to explain the solution enough that my wife understood.

In the end, I was interviewed at 4 companies: Daugherty Consulting, Google, Amazon, and Target. (For Google this was my second interview in two years. The first interview was a shock, I froze during the preliminary interview, and for two years contemplated if I'd ever quit my job.)

Daugherty never had me do whiteboard programming but did ask me some algorithmic questions. These were much easier to answer verbally. In the end I was told I didn't have enough experience in consulting working with large companies. (This was a bit of a shock but whatever.)

With Google, I never got past the first round. I felt very good with my solution coding in a Google Doc, but, they had wanted me to implement the Python bisect_left function. Instead I just used it to solve the problem.

At Amazon I made it onsite, but again, I failed to whiteboard a hashing function to their satisfaction. They told me it could have been overlooked if my architecture skills were stronger. They did complement me highly on my communication skills, which I appreciated. (I had worked for two weeks rewriting my accomplishments journal using the STAR[1] format.)

Target (where I work now), was completely different. I was given a choice of real-world-like problems to solve and a couple weeks to code. Two were pretty heavily algorithm/math-focused but the third was right up my alley -- implement a microservice backed by a data source and a different (potentially flaky) service. I took my time, wrote code I'm proud of, deployed it on Google Cloud, and explained my solution in detail to a Principal Engineer. There were still personality and experience questions (and I think also some algorithm questions) but nothing like my other experiences. It felt much more grounded in reality. Are you a solid developer, good communicator, and good fit for the company. In the end I didn't get the exact position I applied for but I'm still extremely happy.

My takeaways:

1. Maintaining an accomplishments journal as more beneficial than I could ever imagine. I write down everything I'm proud of - when I'm proud of it even if it seems minor. I can always delete it later. Also, the STAR format is actually really good.

2. Don't stagnate in learning. Technology and methodologies are changing all the time. I don't follow every fad or code in my spare time but I feel strongly taking some time periodically to maintain a level of expertise is a good investment.

3. Knowing my strengths and weaknesses really helped me focus while preparing for my interviews.

4. Learning from interviews and maintaining confidence was big for me. I took notes immediately after each interview of what I wanted to work on. I asked for as much feedback as I could get. These notes made it back to my journals and are things I'll refresh time-to-time because I know nothing is a given. Who knows what I'll want in another 15 years.

[1] https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...

I interviewed with one of the companies on that list a few years back (noredink). They gave a timed hackerrank style coding question as round one (so I guess technically not a whiteboard). I passed that, then I had an interview with an actual person.

He asked me vague question, like what is architecture, I started to reply with what design tradeoffs I made on the app I was working on. He literally laughed at me, and said that is not architecture. I was shocked that someone would laugh at a candidate but said ok, what does architecture mean to you? He responded, I ask the questions here not you. I immediately ended the interview. Worst interview I have ever had. Every time I see that company brought up, I think back to that experience.

Fair enough, that does address the point about hiring seniors.

But if universities can't currently usefully certify people for fundamental development ability, after having them on campus for years, i don't see how they'd be able to accredit seniors for the more complex skills they need.

We already have this extended trial period in tech, it’s called an internship, and responsible companies pay interns. Some internships come through university co-op programs, some through organizations that set this up for people following non-traditional career paths, and some companies “roll their own.”

But these positions are overwhelmingly for people breaking into the field. They have much to gain, and very little to lose by working for a company for three months with an uncertain expectation of a full-time job.

Now consider hiring an experienced worker who is out of a job. If Alice offers them a contract with the company having an option to turn it into full-time, while Bob offers them full-time work with the understanding that a major screw-up would lead to dismissal during a probationary period, Bob’s offer is much lower risk.

Finally, consider an experienced worker with a job. For a non-hypothetical example, they’re working at a famous name, with options, and a YC startup that has grown to 200 employEes recruits them.

It’s going to be very difficult to get them to walk away from guaranteed employment that feeds their children, for a temporary gig with no equity participation And the understanding that it’s an extended job interview.

—-

The above focuses on the candidate’s risk/reward calculation. What about the company?

Well, the least experienced person has the greatest uncertainty. They might be very smart, but unable to work well with people. How would we know without giving them temporary work with people?

The most experienced person has the least overall uncertainty. They “brought the receipts.” Without arguing about how they should be interviewed/tested, if they aren’t a completely toxic person, if they have a non-fatal weakness that pops up, it can probably be managed to be fixed, or accommodated.

The employer’s risk goes down as the candidate’s experience goes up. Sure, it would be a bed of roses if the company could hire senior people on a one-year contract and see how all the intangibles work out, but that usually isn’t necessary, and it’s not going to happen often enough to operationalize that as part of the process.

—-

TL;DR:

There is no one-size-fits-all approach that fits all levels of experience, and also scales to large numbers of hires, and also is repeatable.

But the kernel of what you suggest works well for the sweet-spot of high-uncertainty and low risk to the candidate.