How to crack Simpl developer interview

Reading Time: 3 minutes

TL;DR : I want you to join Simpl to build together awesome stuff. So I am helping you to join us.

I joined Simpl 6 months back and it has been a fun ride. My Simpl recruitment journey was a great experience. Starting with a problem which I was given to think about upfront, to the discussions I had with the team, I spent time solving not only good problems but the right problems. The discussions were detailed, probing and I connected some dots while I was at it. The tone of the conversation was very polite and the co-pilots showed genuine interest in figuring out what I know and what I can solve. I felt this was time well spent irrespective of the outcome.

After spending some time at Simpl, I now understand the reasoning (the why) behind our developer recruitment process. Let me give you a glimpse of the life of a Simpl developer to explain the ‘why’.

Days in the Life of a Simpl Developer

Day T

One of our leading merchant partners started showing failures for some of the requests made to us from customers since we were breaching our performance SLA (500 ms as observed by the partner).

Our business team intimated us and the developer on call was surprised: our monitoring setup immediately alerts us on service or infrastructure issues.

Quick testing on the production app did not reveal any anomaly. An inspection on the monitoring dashboard told that the service is very much healthy and was responding at 99th percentile response time in the order of 10s of ms. The load balancer logs were clean and its overhead was negligible (less than 5 ms). All resource usage looked good. So, why was the SLA breached? What else can come in the way?

Day H

Our business metric for user approvals saw a big unexpected spike. Our developer dug deeper to find out if they are anomalies in user behavior based on the approval mechanisms. And lo and behold, we found behavior which was trying to game our Real-time Approval system! How do we fix this? We needed an opposing force — that was the genesis of the Real-time Fraud Blocker!

Day R

When we integrated with service dashboard product, we needed to periodically transfer a specific set of users (in bulk) along with their latest transactions. The volume was reasonably high and we also needed to de-normalize transaction data for each user so that it can be fed into the dashboard system.

Last 3 transactions of users to be sent

The service owning the data is designed to work with OLTP workloads whereas this need skewed away from that sweet spot. Using the service API directly for this will not cut it. What is the way to do this?

Day I

A consumer does one time linking of Simpl with their favorite merchant. This process needs a secure token to be generated and given to the merchant’s systems. Like any standard platform, we support webhooks to avoid polling. This webhook mechanism cannot go out of our automation suite. But testing egress webhooks automatically in a CD setup can get messy. How do we do it?

Day V

One of the features I worked on is the ability for business users to send out IVR communication. Changes were required in our dashboard application built in RoR. We have a facade microservice which dealt with different third-party communication providers. It is built in Node JS, consumes messages using AMQP. As part of single feature development, I worked with both stacks. I needed to be a true polyglot!

Day E

Newbie joined the engineering team and worked on a feature. This feature was part of an existing service and Newbie completed development along with unit tests by following TDD. During code review (pull request), the reviewer raised a comment on a chunk of code which was not touched but was part of the same file. “Why should I worry about code which I have not changed”, asked Newbie. Another member said, “ We follow the boy scout rule”. And Newbie was reformed.

Given these sort of days are here to navigate, we put together the skills and attitude that’s necessary to make the days interesting and enjoyable.

What we look for in you

This is what we expect from you. And when we say mandatory we really mean it.

Steps for getting you here

Here is an info-graphic (creative genius:1000 points!) on our recruitment process:

Not steps, but the spirit

When we go through this process of bringing you to us, we care about the journey as much as the result — probably more. To us this is an opportunity to interact with another engineer to geek out at multiple levels — solve problems, apply concepts, share opinions (and rant together ;)).

The conversations are about real-world work scenarios and not textbook defined questions. The questions are open-ended to elucidate not just information but also your opinions on pertinent things. We love to draw out the engineer in you so that we can understand your strengths and attitudes on engineering problems deeply.

All that said, the most important thing we want is an enjoyable and memorable experience for you and us.

Looking forward to work with you! Interested?

Leave a Reply

Your email address will not be published. Required fields are marked *