Have you ever been asked a puzzle question in an interview, such as: "Why are manhole covers round?" or "How many ping pong balls can you fit in a school bus?" Or perhaps you have been asked to write code to reverse a linked list on a whiteboard?
We don't do those kinds of interviews at Pivotal. We know they don't tell us anything about how well a candidate can write production-quality code, or design highly usable interfaces, or if they can manage backlogs effectively.
These kinds of theoretical question interviews also don't give a candidate the chance to see what it's like to work here. We believe interviewing is a two-way street. If you are interviewing with us, you're evaluating us as much as we are evaluating you. And we are all trying to answer the same question: "Do we want to work together?"
How it works
We figure that the best possible way to mutually determine whether or not we want to work together is—to try working together. If we keep you in a conference room answering puzzle questions all day, we will all know what it feels like to work on puzzles together. (Or, more likely, we'll know what it feels like for you to solve a puzzle while being closely observed and judged. Ick.)
Our engineering interview exemplifies this philosophy. If you are an engineering candidate, we'll ask you to arrive in time for breakfast. You'll join a small group and see first hand how we start every day. Then you'll attend standup, work with a team in the morning, a different team in the afternoon, and have a relaxed social lunch in the middle.
Breakfast at Pivotal
When you work with each team, you'll pair with someone, typically working on a story out of the backlog. With luck, if we prepared well for your visit, you won't even notice how much care we took in selecting the story.
But don't be fooled: We take great care to pick a story that can be explained relatively quickly, that isn’t too big, isn't too small, and involves writing actual code. Sometimes that means fishing around lower in the backlog to find something appropriate, and that's fine. If we restricted our interviews exclusively to stories at the top of the backlog, there's too big a risk that the interviewer would have to spend the bulk of the time explaining the context, or that you would end up working on something that would not allow you to show off your programming skills.
You and your interviewer will be collaborating on the work just as if you worked at Pivotal. There is no right or wrong answer. Your interviewer isn't giving you hints to see if you can work a puzzle with a known solution; they're trying to solve the problem with you. For the time that you are interviewing, you're on the same team.
No manufactured puzzles
Our interviews for other roles, like Designers and Product Managers, are a little different but adhere to the same general philosophy of doing real work instead of manufactured puzzles.
When you leave at the end of the day, we hope that you've gotten a sense of what a typical workday feels like here. We hope that you've been able to experience the radical collaboration and fast feedback cycles that are a hallmark of our software development practices. Most of all we hope you've had fun, and that—no matter what the outcome of the interview is—you feel it was time well spent.
We consistently hear from interview candidates that our process is different from anything they've ever experienced and that they like it.
If you'd like to experience our interview process, please check out our careers page.
