Engineering life at Productboard: The interview process and how to prep

If you work in IT, it’s not too hard to find work. But it’s not nearly as easy to choose a job that you will actually like. In this three-article series, I’d like to explain why I decided to join Productboard and how things work inside the company.

Whenever I’m researching a potential new job, I’m always very interested in hearing (or reading about) the personal experiences of people working at the company, which is why I have decided to share my personal experience at Productboard.

Hiring new people in IT is generally a complicated process for both sides. From the company’s perspective, there is no way of knowing if an applicant is as competent as they seem in their CV before inviting them in for an interview (and sometimes even the interview is not enough). From the applicant’s perspective, there is no way of knowing with absolute certainty that the company they are applying to work at is going to be a perfect fit. Much of the hiring process at any company centers around trust, instinct, and a whole lot of research conducted by both sides. My hope is to make your job a bit easier by telling about what I went through when searching for a new job and why I ultimately landed at Productboard. I’m aware priorities differ from person to person, and your job expectations might be different than mine, but perhaps you’ll find some similarities between my experience and your expectations.

Defining requirements when looking for work

Since IT is a booming field and the demand still greatly exceeds the supply, we have a lot to choose from, and we can define for ourselves what kind of job we would actually like. In my case, I had the following requirements:

• I didn’t want to work in a digital agency.
  Agencies and outsourcing companies generally don’t sit well with me on principle. For me, the feeling of ownership is lacking with the product itself. Often, management doesn’t emphasize doing things well, because it takes more effort and money and might not necessarily result in increased returns for the agency. Body-shopping is a similar case, which usually leverages the fact that big companies don’t want to employ contractors directly or at least don’t mind using external companies that employ contractors. On the other hand, digital agencies are interesting at the beginning of one’s career, as you can get exposed to many different technologies, change projects often, and meet a lot of different people.
• I wanted to work at a company with established processes, but not too many.
  At startups, they say the absence of processes is “punk,” but at a certain size, processes become necessary, or else the company can no longer scale. On the other hand, corporations tend to get so hung up on processes that they get very little work done, which is also far from ideal. So the key is to find a balance between the two.
• I wanted to work on an interesting product that I would want to use.
  Once you meet the basic needs in Maslow’s hierarchy of needs, which isn’t hard to do in IT, you start to realize that you have to enjoy what you do. If you don’t like your work, you lose motivation, and it’s difficult to do a good job in the long run. So it’s important to work on things that you enjoy and can fully realize.
• I wanted to work with inspiring people from who I could learn.
  One common cliche is that a person is the average of the five people he spends the most time with. There’s definitely something to that, at least from my perspective. We absorb language, behavior, and thought structure from our surroundings. Considering the fact that we spend a good chunk of our lives at work, it’s important that you get along (as much as possible) with your colleagues. I wanted (and still do) to work with people who are curious, who like to try new approaches, and who don’t just see work as a means to an end. If you don’t like your work or work in a toxic environment, I recommend changing it as soon as possible.

Searching for work

Based on these requirements, I narrowed my search down to several companies with offices in Prague. The key prospects were Memsource, Windy, Pipedrive, and Productboard. These companies were developing products that appealed to me.

Windy and Memsource interested me a lot from a product perspective, but company culture which is important to me looked better at Pipedrive and Productboard.

At Pipedrive I really liked the team’s strong vision, well-established processes, interesting company culture, and above all, a sauna at their Karlin offices, which for someone like me is just irresistible!

I made it through the whole hiring process at Pipedrive, and I liked it. The third round was the most interesting of all. It included an interview with Martti, VP of Engineering, where we discussed personal projects inside and outside of IT. He really is interested in the candidate’s ultimate goal and whether they program out of love or for other reasons. It was one of the most interesting interviews that I had during the whole hiring process. Still, I was completely set on taking the job at Pipedrive. Until that is, I had a call with my friend Martin, Staff Engineer at Productboard.

What does Productboard even do?

I’ll admit, I had no idea about how problematic product management was. I thought that Productboard was some kind of simplified version of Jira where it showed features in a timeline and called it a “roadmap.”

When I spoke with Martin, he quickly corrected my misconception with the following explanation: “Productboard is precisely what you use even before Jira. Many companies don’t even think about it, but it would help them if they did.”

He asked me how I thought product managers decided where to direct attention during development which would most benefit the product itself. I realized then that I had overlooked the request prioritization process that should occur between user feedback and feature creation requests in Jira.

Defining requests for new functionality shouldn’t be built on personal preferences or emotions but on measurable data and feedback. So that’s what Productboard does.

Productboard workflow diagram: On the left are the tools to collect feedback from users, and on the far right are the tools for issue tracking. In between the two is Productboard. It consolidates user requests and makes roadmaps from them that can be publicly shared and then used to collect further feedback.

With the help of Productboard, product managers can quantify things that have the biggest impact on the product and take the least effort. You don’t have to have Steve Jobs’ vision to know what needs to get done and what functionality will have the most added value for the effort invested.

Martin talked to me about Productboard for about two hours. He showed me how the product worked in detail and described the company culture. After that call, I wrote to a few people I know at Productboard to ask them how they liked working there and received extremely positive responses from everyone. I checked the reviews on Glassdoor, and they were also fantastic.

To better understand the product and problem that Productboard is addressing, I listened to all of the podcasts I could find with Productboard’s CEO Hubert and CTO Dan. I also checked out the series People of Productboard and Engineering leadership. I went through articles I found about user experience with products. I figured out who the competitors were, and studied information about hiring from articles written by Productboard’s talent department. I liked Productboard’s strong vision, and I felt a job there could really be interesting.

Productboard’s interview process

I went through several rounds of interviews at Productboard. The first round was with a recruiter Adela where we talked about my expectations and goals. In the second round, I programmed little snippets in JavaScript; in the third, I was asked to work with React components. I spoke with Vojta, Senior Director of Engineering, in the fourth round of the interview process. In addition to these interviews, I was also invited to lunch and met (virtually) with the team to be sure that we got along. (Spoiler alert: we did!)

The interview process isn’t especially easy and it isn’t meant to be. Both sides are trying to mutually understand each other and figure out if they’re going to get along. The company is not just evaluating your technical knowledge but also your English level, emotional intelligence, and whether you’d be an overall team fit. When a company is relatively picky, it can hire people who are on the same wavelength and maintain a strong company culture and feeling of belonging.

I personally like companies that have a multi-round, complicated interview process. They’re more stressful and difficult to prepare for. But my experience is that at companies with a simple interview process, you end up working with people you don’t learn much from as opposed to those companies that place more emphasis on the initial selection of the right candidates.

My advice: Don’t hesitate to go through complex interviews. Look at them as practice rounds. They will boost your confidence and help you better prepare for that one interview you really want to ace.

And the winning choice…

I went with Productboard in the end, in case you couldn’t tell which direction this article was heading. The company best fulfilled my predefined conditions. Productboard isn’t tangled up in an excessive number of processes, it has a lot of interesting potential to it, the team spirit felt right to me, and the product itself is something that I would want to use as a product manager. From my own side projects, I know all too well how difficult it can be to competently decide what will be best for the product and not just for me.

Are you ready to join us? Check out Productboard’s job openings.

Next up in the series, I will be taking a closer look at the ins and outs of Productboard’s onboarding process. You aren’t going to want to miss this behind-the-scenes look at what an engineer can expect during his or her first few weeks at Productboard.