This Q&A features our tech team, the backbone of the Roam.ai operation. Read what our CTO Jothi Priyadharshan, and Product Owner Nikhil Kumar have to say about their experience of building Roam from the tech team perspective.
I know what some of you are thinking. How much will I have to read until he makes the "Roam wasn't built in a day" pun? Look, I've watched 4 seasons of Seinfeld so I know a thing or two about comedic timing. But sure, during the interview I considered making the joke, because maybe they would find it funny. Let me quickly visualise for you what was running through my head at the time.
How I'd hope they would react:
.gif)
How they would realistically react:
How I hope people reading it would react:
How I am feeling no matter what:
In the end, Jothi and Nikhil are busy guys so I didn't want to waste their time with puns. That being said, I can summarise their experience in one sentence: Roam wasn't built in a day [insert laughing track and the Seinfeld theme here].
There's your answer, we got the pun in a record-breaking 3 short paragraphs.
I think we’ll get the Q&A going here before this gets worse.
How do you build a tech team?
Joe: When we talk about building a tech team, it starts with who you look for and want in the team. I think our hiring process is unique in this case. We don’t have a person who talks to the potential candidate, schedules an initial call, have them go through a technical round, do some test assignments, and then finally speak to either Manoj or I. I like to take the first call when meeting a potential new employee instead of going through a traditional hiring process. I want to know the person first and get an idea if they’re a fit for the team. In that initial conversation I try to figure out how much they value their career, how motivated they are, and maybe some of their short term goals instead of looking at their skills and experience.
That leads to my next point, the primary thing we look for in a person is ownership. Someone who takes control of their own tasks and wants that responsibility. I personally don’t believe in the concept of people with and without skills because people can learn skills if they’re passionate and motivated to do so. It’s exciting for us to have someone on the team who’s invested, wants to learn, and takes ownership. We’d rather take on someone motivated and inexperienced over someone experienced but less interested in the work itself. When everyone takes responsibility for their work it’s easier to support and help each other along the way.
Nikhil: Same sentiment as Joe, I also look for ownership. It’s important to try your best first and if you get stuck along the way, we’ll help you! Some tasks we have are difficult but as long as there is effort and communication it can be solved.
And so apart from effort, communication within the team and with our clients is important too. When evaluating our team one thing I look for is if the person follows up with ongoing issues or not. Whether that is with the project manager or the client, delays and issues should be communicated with a reason so that there is transparency between us and the client .
Joe and Nikhil: Lastly, curiosity and frequent questions are better for the team rather than someone who says “yes” to everything. In the end, when building a tech team it’s about creating a relationship that benefits both, where the team members are able to have their input, take ownership, and work together. It’s like what Dom Toretto always says, “it’s about family”, we don’t look for ‘employees’, we look for people who want to join our family haha.
How do you build an SDK? What sets an SDK apart from standard tech?
Joe: An SDK is actually a straightforward thing to build for a developer, but it’s about what you do with it. It has to be lightweight and easy to implement because that’s what developers want when they look for an SDK. So, that’s our goal too, building it lightweight. For that you also need good docs because in the integration phase the last thing a developer wants is to constantly contact support for help. Therefore, the experience of using our SDK is the focus here. It should be lightweight, friendly, secure, easy to integrate, and have clear docs.
Nikhil: The reason the experience is important to us is because it builds trust. You want developers to trust that you can provide a quality SDK but there are also other reasons. For instance, when they do need help or have a question and want to connect with us, they need to trust that we’ll be there to respond. Whether that’s through email, github, forums or our blogs, it really doesn’t matter what channel they go through as long as they are able to reach us quickly.
How do you build a location SDK?
Joe: You could always make your app location aware without an SDK. But an SDK provides customizability. Every use-case has its own challenges and specific things they want to implement, and that can take ages to solve by yourself, with endless lines of code. A location SDK with features provide what most people are looking for: custom tracking modes, mock location prevention, accuracy engine, etc. Developing all those features by yourself is a tall order, and like I said, with endless lines of code, while with Roam they can do it with a single line.
Nikhil: Over the last few years we’ve also learnt what kind of features clients would want to develop with Roam. So when building the location SDK we needed to provide those different features that work independently from one another since not everyone wants the same thing. When a client is purely focused on accuracy they care less about battery, and vice versa. So it’s about remembering the client doesn’t want all the features you provide.
Joe: Basically, we’re constantly learning and understanding what clients want. Another example is privacy. We used to have that location data would be sent to our server first, but over the years we added the option to send that data directly to the clients servers instead should they prefer that. It’s details like this that you pick up and add along the way.
What do you want to do with Roam’s SDK going forward?
Nikhil: We’ve developed the accuracy engine, battery efficiency, offline tracking, etc., - all those things are already there. The roadmap now is to perfect those things and also focus on bringing everything local.
Joe: Exactly, bringing everything local is something we’re looking towards. That means being able to use any of the API’s locally and directly from the device*. This is something that clients have talked about with us, and it is our ambition to do so.
*A bit lost? I was too, and I’d love to tell you that I have the famous award winning Hollywood actress Margot Robbie here to explain it to you but I don’t. You’re stuck with me on this one. For the unfamiliar, the SDK stores location data directly on the mobile device, which means you do not need Roam’s servers for it to operate. The API’s do require our servers in order to operate and collect location data. What our tech team wants to do is have the API’s become local as well so clients don’t have to use our servers.
Joe: Added to that, we’re looking at having a core SDK module. So the basic initial thing is the SDK and tracking capability, and like lego bricks you can add the other modules. Let’s say if a company is focused on trips, it’ll have the core SDK with the trips module. Or if a company is focused on geofences, it’ll have the core SDK with the geofence module. This makes it a leaner package as you’ll only have what you want.
Want to read more?
If you’ve enjoyed this Q&A with our tech team, be sure to check out our previous one with the sales team!