How we interview Pivotal
- Transfer
From a translator: Over the past few days, the topic of using puzzles and solving problems on the board when interviewing programmers has once again become a trend. It all started with a post by Yegor Bugaenko Why I Don't Talk to Google Recruiters , then a link to the post appeared on Hacker News and Reddit, and then received a reaction on Twitter. A tweet from David Heinemeir Hannson, the creator of Ruby On Rails, launched a whole chain of answers in the style of “Hello, I'm ...” where people spoke out about what kind of algorithmic problems they were unable to solve, despite their extensive experience and successful projects.
It seemed to me that it would be interesting to learn about an alternative approach to the interview. An approach that does not include solving complex algorithmic problems at the board or knowledge of the intricacies of a programming language. Below is a translation of an article from the Pivotal official blog . The company's projects are such software products as: Java Spring Framework application development framework , Pivotal Cloud Foundry cloud PaaS platform , RabbitMQ messaging system . And the Pivotal Labs division is committed to implementing agile practices in software development.
Have you ever been asked a puzzle question during an interview? For example, “why are the manholes round?” Or “how many ping-pong balls will fit on the school bus?” Or maybe you were asked to write code on the board that reverses the linked list?
At interviews at Pivotal, we don’t do that. We know that these kinds of questions will not say anything about how well a candidate can write production-quality code. Or design convenient user interfaces. Or can a candidate manage backlog effectively.
Such theoretical questions in the interview also do not give the candidate a chance to see what it feels like to work here. We believe that interviewing is a two-way road. We interview you just like you do interviews with us. And each of us is trying to answer the same question - "Do we want to work together?"
We found out that the best way for both of us to understand if we want to work together is to try to work together. If we held you in a meeting room, forcing us to answer insidious questions all day - we would know how we can “work” on puzzles together. Or, more likely, we would know how you deal with solving puzzles while being closely monitored and constantly evaluated. Oops
Our interview for engineers embodies this philosophy of “trying to work together.” If you are a candidate for an engineer position, we ask you to arrive at the office by breakfast. You will join a small team and see with your own eyes how we start every day. Then, you will visit the standup, and after that you will work with your team in the first half of the day. Then with another team - this afternoon. And spend lunch in a relaxed conversation in a friendly company.
When you work with a team, you are programming in tandem with someone. Usually, this includes working on a real task from the backlog. Most likely, if we are well prepared for your arrival, you will not even notice how carefully this task is chosen. But do not think that everything is so simple - we really approach the choice of a task with the greatest attention. The task should be such that it can be quickly explained. Not too big, but not too small. Well, of course, it should include writing code. Sometimes, such a task is chosen not the highest priority. But there is nothing to worry about. If we took exclusively priority tasks, then we would take the risk of spending most of the time explaining the context. Or the risk of working on something that cannot show your programming skills.
You and the interviewer will work together on the task, as if you were already working at Pivotal. There is no right or wrong answer. Your partner does not give a hint to see if you can solve a problem whose solution is already known. Instead, he or she is trying to solve the problem by working with you. For the duration of the interview, you are one team.
Our interviews for other positions, such as a designer or Product Manager, look a little different. But they adhere to the same philosophy - to engage in real work, and not to come up with puzzles.
When you leave the office at the end of the working day, we hope that you will understand what a typical working day looks like here. We hope that you can feel the spirit of interaction and feel the “back reaction” from the product and its users. These two factors are key to our software development philosophy. And most of all, regardless of the result of the interview, we hope that you are just having a great time and have fun.
We often hear from candidates that our process is different from everything that they saw before. And they like it.
It seemed to me that it would be interesting to learn about an alternative approach to the interview. An approach that does not include solving complex algorithmic problems at the board or knowledge of the intricacies of a programming language. Below is a translation of an article from the Pivotal official blog . The company's projects are such software products as: Java Spring Framework application development framework , Pivotal Cloud Foundry cloud PaaS platform , RabbitMQ messaging system . And the Pivotal Labs division is committed to implementing agile practices in software development.
How we interview Pivotal
Have you ever been asked a puzzle question during an interview? For example, “why are the manholes round?” Or “how many ping-pong balls will fit on the school bus?” Or maybe you were asked to write code on the board that reverses the linked list?
At interviews at Pivotal, we don’t do that. We know that these kinds of questions will not say anything about how well a candidate can write production-quality code. Or design convenient user interfaces. Or can a candidate manage backlog effectively.
Such theoretical questions in the interview also do not give the candidate a chance to see what it feels like to work here. We believe that interviewing is a two-way road. We interview you just like you do interviews with us. And each of us is trying to answer the same question - "Do we want to work together?"
How it works?
We found out that the best way for both of us to understand if we want to work together is to try to work together. If we held you in a meeting room, forcing us to answer insidious questions all day - we would know how we can “work” on puzzles together. Or, more likely, we would know how you deal with solving puzzles while being closely monitored and constantly evaluated. Oops
Our interview for engineers embodies this philosophy of “trying to work together.” If you are a candidate for an engineer position, we ask you to arrive at the office by breakfast. You will join a small team and see with your own eyes how we start every day. Then, you will visit the standup, and after that you will work with your team in the first half of the day. Then with another team - this afternoon. And spend lunch in a relaxed conversation in a friendly company.
When you work with a team, you are programming in tandem with someone. Usually, this includes working on a real task from the backlog. Most likely, if we are well prepared for your arrival, you will not even notice how carefully this task is chosen. But do not think that everything is so simple - we really approach the choice of a task with the greatest attention. The task should be such that it can be quickly explained. Not too big, but not too small. Well, of course, it should include writing code. Sometimes, such a task is chosen not the highest priority. But there is nothing to worry about. If we took exclusively priority tasks, then we would take the risk of spending most of the time explaining the context. Or the risk of working on something that cannot show your programming skills.
You and the interviewer will work together on the task, as if you were already working at Pivotal. There is no right or wrong answer. Your partner does not give a hint to see if you can solve a problem whose solution is already known. Instead, he or she is trying to solve the problem by working with you. For the duration of the interview, you are one team.
No invented puzzles
Our interviews for other positions, such as a designer or Product Manager, look a little different. But they adhere to the same philosophy - to engage in real work, and not to come up with puzzles.
When you leave the office at the end of the working day, we hope that you will understand what a typical working day looks like here. We hope that you can feel the spirit of interaction and feel the “back reaction” from the product and its users. These two factors are key to our software development philosophy. And most of all, regardless of the result of the interview, we hope that you are just having a great time and have fun.
We often hear from candidates that our process is different from everything that they saw before. And they like it.
