<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=12616&amp;fmt=gif">

Latest Posts

Boomeranging Back to Developer from Product Owner

By
May 10, 2018

Codility technical assessments are a great way to make your tech hiring process not only more effective and efficient, but also more objective. The Codility platform automatically grades the code candidates submit for correctness, performance, and scalability. This way, when hiring teams decide which candidates to advance in the recruiting process, they are looking at job-related work samples instead of subjective measures.

Hiring teams should use skills-based, objective measures when assessing tech candidates because closing doors on applicants who are qualified but don’t have a typical coding background means great potential team members could be overlooked. And in this competitive talent market, there’s no room to miss out on key hires for any reason, especially bias.

The team recruiting team here at Codility uses our own platform in to identify talented coders and has hired some great people. One recent hire, Piotr Wiechno, in particular stood out as someone with an unconventional background for the role he was hired for, so I took some time to sit down and gather his thoughts.

Piotr Wiechno mugshot

Jeff: When did you join and what do you do at Codility?

Piotr: I joined Codility earlier this year in January and work as a front-end engineer. The team I’m a part of works on the application that recruiters use to manage their coding tests, send tests to candidates, and review candidate reports.  

J: I’ve heard you have a bit of a windy career path. Could you talk about that?

P: Sure thing - not long after graduating from uni, I got hired in R&D at Orange Poland, a major telco company, and worked there for around 10 years. When I first started out, I was an engineer doing a lot of coding, but soon the team I was part of started to take on more research-oriented projects, and also started to put more emphasis on user-centric design. With that shift in scope, I gradually transitioned more into a research-heavy project manager / product owner role.

J: What were some of the things you worked on at Orange?

P: Right away, the first thing I worked on was really cool. It was an Interactive Voice Response (IVR) system, like what you interact with when you call into a hotline or something. We were replacing the conventional call-in flow of pressing ‘1’ to do this or pressing ‘2’ to do that with speech recognition, which was very cutting-edge at the time. That remained one of my favorite projects, but basically everything we worked on was interesting, especially research on how people interact with devices—touch interfaces, speech recognition, chat, emotional involvement, all sorts of things. I also have very fond memories of contributing to W3C standardization, which was an opportunity to share some of our work globally and travel to very nice places.

J: What were some of the things you enjoyed about that role at that company?

P: Much of the joy I got from working there was from working with a small team that gelled well together. It was a nice mix of engineers and designers, and I had a great manager—a great coach. Working closely with service and interaction designers was especially valuable, and I learned a lot from them. I was also fortunate to have our research project owned by someone who had a lot of trust in the team and gave us much creative freedom and responsibility. So most of corporate overhead that might otherwise be too heavy, we were shielded from to focus on our work.

J: What were some of your dislikes about the role and company?

P: It was tough to realize that not much of my work went public. Some of the coolest stuff I worked on is confidential and I can’t talk much about it. The IVR project I mentioned was as near to production as I got, and it never saw mass-market deployment, ending at the pilot phase. Some of the research was shared at conferences or patented, but most results remained internal to the company.  

J: So what made you decide to look at a career transition? Was there a particular event?

P: There wasn’t a major event, but rather this growing realization that even if the projects I had a hand in were cool, they didn’t end in something that went into the hands of customers. I didn’t get to see end users playing around in and being happy with my products. For a long time this was offset by the comfort of experimenting with new things that didn’t need to become products straight away. But it came to a point where it was time to switch, and it coincided with the fact that the team I had been very comfortable in was being reorganized, so there was little incentive to stay.

J: Were there any skills you felt you were missing to make that transition happen?

P: Well, I started out as an engineer at Orange, but when I took on more research projects, my role became too managerial. It wasn’t as technical as I would’ve liked, and at times I missed being a full-time developer. I did write some code as a product owner, but I didn’t need to worry about scaling or even code quality that much. I could hack a lot of things and prototype. So I didn’t have a ton of experience working as a developer on production code, using Git with a number of people etc. That’s one of the skills I was missing—hands-on coding experience with a development team on a daily basis.

J: How did you gain those key skills to prepare yourself for interviews?

P: Honestly, this is where Codility came in. Because I was rusty as a developer, I was a bit anxious when interviewing for developer roles. What’s great about Codility is that there are lessons you can take to brush up on skills. When I interviewed at Codility, I had seven days to take the coding test, so I spent that week going through lessons and learning. I was thus able to get into that certain mindset of puzzle-solving and algorithms—these weren’t necessarily skills I had been using over the past few years. It’s definitely not going to teach you programming in seven days, but it’s very helpful if the last time you dealt with algorithms and complexity was when you were a student. Without these lessons, the coding test would’ve most likely been too hard.

J: How did you feel about taking a coding test as a part of your interview process?

P: I think it gave a great objective first assessment of what I can do. I really appreciated the opportunity to prove myself because I hadn’t been a developer for some time, and a lot of other hiring teams looking for a front-end dev probably would’ve disqualified me based on my on-paper background.

J: That’s awesome. So, you’ve been in role for a few months now, do you miss your old role?

P: Not that much. When you work in R&D you have the freedom to pick the things you want to do on a daily basis, but I think I might’ve gotten too complacent over the years. The rhythm of working as a dev is nice. Plus, all the things I enjoyed there like working on a small team with great people, the atmosphere, it’s all here. I knew it was going to be a fun place to work the moment I stepped into the office, and I was excited to go back to my coding roots.

J: What’s your advice for others thinking about making a big career change like you?

P: I took that step earlier than I anticipated. I knew that I wanted to make the switch, but didn’t plan on doing it for another few months. Then again, I knew about Codility for a while and knew how great the culture was, and the opportunity kind of popped up, so the decision was made. It was a leap for sure, and that’s my advice—to take the leap and do it. The cool thing about doing the Codility test during my interviews was that it was a good indicator for me if the career switch was doable or not.

Summary

Hiring teams looking to add great developers to their ranks know that being objective and implementing skills-based measures in their recruiting process is important. But with day-to-day tasks and other priorities at hand, diving into each candidate’s skillset to give every individual a chance isn’t easy. Codility is a quick and easy way to check a candidate’s coding fundamentals so you ensure you aren’t missing qualified candidates that you might otherwise have overseen. We’re excited to see the impact Piotr has on our product’s user interface. Good on him for making the move back to development and acing his Codility interview!

Click below if you're growing and would like to speak with us about your tech hiring process.

Contact Us