How we conduct interviews at Pivotal
From the translator: Over the past few days, the topic of using puzzles and solving problems on the board during an interview with programmers has once again become a trend. It all started with the post of Egor Bugayenko Why I did n’t talk to Google Recruiters , then a link to the post appeared on Hacker News and Reddit, and then got a reaction on Twitter. Tweet David Heinemeir Hannson, the creator of Ruby On Rails, launched a whole chain of answers in the style of “Hello, I'm ...” where people expressed what kind of algorithmic problems they are not able to solve, despite their extensive experience and successful projects behind them.
It seemed to me that it would be interesting to learn about an alternative approach to the interview. An approach that does not involve solving complex algorithmic problems at the blackboard or knowing the subtleties 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: the Java Spring Framework application development framework , the cloud-based PaaS platform Pivotal Cloud Foundry , the RabbitMQ messaging system. A division of Pivotal Labs is engaged in the implementation of flexible practices in software development.
')
Have you ever been asked a puzzle question during an interview? For example, “Why are manholes round?” Or “how many ping-pong balls fit on a school bus?”. Or perhaps you were asked to write code on the board that reverses the linked list?
At the interviews in Pivotal, we do not do that. We know that such questions will not say anything about how well a candidate can write production-quality code. Or design user-friendly user interfaces. Or can a candidate manage backlog effectively?
Such theoretical questions in an interview also do not give the candidate a chance to see what it is like to work here. We believe that the interview is a two-way road. We are interviewing you just as you are interviewing 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 see if we want to work together is to try to work together. If we kept you in a conversation, forcing you to answer insidious questions all day — we would know how we can work together on puzzles. Or, more likely, we would know - how do you cope with the solution of puzzles being under scrutiny and constant evaluation. Oops.
Our interview for engineers embodies this philosophy - “try to work together”. If you are a candidate for an engineer position - we ask you to arrive at the office for breakfast. You will join a small team and see with your own eyes how we start every day. Then, you will visit Standup, and after - you will work with your team during the first half of the day. Then with another team - the second half of the day. And you will spend lunch for a relaxed conversation in a friendly company.
When you work with a team, you are programming together with someone. Usually, this includes working on a real backlog task. Most likely, if we are well prepared for your arrival, you will not even notice how carefully selected this task. But do not think that everything is so simple - we really come to the choice of the problem with the greatest attention. The task must be such that it can be quickly explained. Not too big, but not too small. And, of course, should include writing code. Sometimes not the highest priority is chosen as such a task. But there is nothing wrong with that. If we were to take exclusively priority tasks, then we would be at risk of spending most of the time explaining the context. Or risk working on something that will not show your programming skills.
You and the interviewer will work together on the task, as if you are already working in Pivotal. There is no right or wrong answer. Your partner does not give hints to see if you can solve a problem whose solution is already known. Instead, he or she tries to solve the problem by working with you. At the time of the interview, you are one team.
Our interviews for other positions, such as a designer or a product manager, look a bit different. But they adhere to the same philosophy - to do real work, and not to invent puzzles.
When you leave the office at the end of the work day, we hope that you understand what a typical work day looks like here. We hope that you can feel the spirit of interaction and feel the “backlash” from the product and its users. These two factors are key to our software development philosophy. And most of all, regardless of the outcome of the interview, we hope that you are just great and have fun.
We often hear from candidates that our process is different in everything that they have seen 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 involve solving complex algorithmic problems at the blackboard or knowing the subtleties 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: the Java Spring Framework application development framework , the cloud-based PaaS platform Pivotal Cloud Foundry , the RabbitMQ messaging system. A division of Pivotal Labs is engaged in the implementation of flexible practices in software development.
How we conduct interviews at Pivotal
')
Have you ever been asked a puzzle question during an interview? For example, “Why are manholes round?” Or “how many ping-pong balls fit on a school bus?”. Or perhaps you were asked to write code on the board that reverses the linked list?
At the interviews in Pivotal, we do not do that. We know that such questions will not say anything about how well a candidate can write production-quality code. Or design user-friendly user interfaces. Or can a candidate manage backlog effectively?
Such theoretical questions in an interview also do not give the candidate a chance to see what it is like to work here. We believe that the interview is a two-way road. We are interviewing you just as you are interviewing 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 see if we want to work together is to try to work together. If we kept you in a conversation, forcing you to answer insidious questions all day — we would know how we can work together on puzzles. Or, more likely, we would know - how do you cope with the solution of puzzles being under scrutiny and constant evaluation. Oops.
Our interview for engineers embodies this philosophy - “try to work together”. If you are a candidate for an engineer position - we ask you to arrive at the office for breakfast. You will join a small team and see with your own eyes how we start every day. Then, you will visit Standup, and after - you will work with your team during the first half of the day. Then with another team - the second half of the day. And you will spend lunch for a relaxed conversation in a friendly company.
When you work with a team, you are programming together with someone. Usually, this includes working on a real backlog task. Most likely, if we are well prepared for your arrival, you will not even notice how carefully selected this task. But do not think that everything is so simple - we really come to the choice of the problem with the greatest attention. The task must be such that it can be quickly explained. Not too big, but not too small. And, of course, should include writing code. Sometimes not the highest priority is chosen as such a task. But there is nothing wrong with that. If we were to take exclusively priority tasks, then we would be at risk of spending most of the time explaining the context. Or risk working on something that will not show your programming skills.
You and the interviewer will work together on the task, as if you are already working in Pivotal. There is no right or wrong answer. Your partner does not give hints to see if you can solve a problem whose solution is already known. Instead, he or she tries to solve the problem by working with you. At the time of the interview, you are one team.
No invented puzzles
Our interviews for other positions, such as a designer or a product manager, look a bit different. But they adhere to the same philosophy - to do real work, and not to invent puzzles.
When you leave the office at the end of the work day, we hope that you understand what a typical work day looks like here. We hope that you can feel the spirit of interaction and feel the “backlash” from the product and its users. These two factors are key to our software development philosophy. And most of all, regardless of the outcome of the interview, we hope that you are just great and have fun.
We often hear from candidates that our process is different in everything that they have seen before. And they like it.
Source: https://habr.com/ru/post/322758/
All Articles