This is the fifth episode of HackerRank Radio, our podcast for engineering leaders interested in solving developers’ toughest problems today: Hiring the right developers. Hosted by Vivek Ravisankar (CEO & Co-founder, HackerRank). You can subscribe to us on iTunes and Google Play.
20 years ago prescriptions were administered by just a handwritten note from your doctor to the pharmacy. This antiquated process would often result in a number of issues: losing the prescription sometime between leaving the doctors office and arriving at the pharmacy, illegible prescription note, or issues getting to the pharmacy to deliver the prescription. But today, with all the advancements in technology, we're able to streamline this process by sending the information directly from doctor to pharmacy instantaneously---making the patient experience seamless and stress-free.
This is one of the pillars of software development within the healthcare industry: exceptional patient care. In our latest episode of HackerRank Radio, we sat down with ForeSee CTO Rumpa Giri as she breaks down the challenges of finding the right technical talent for the healthcare industry. She dives into what makes a developer successful in healthcare tech, how she goes about evaluating developer candidates, and the #1 skill she always looks for.
Listen to the episode, or scroll below to skim the transcript.
Transcription
Vivek: Welcome to HackerRank radio, Episode 5. I'm Vivek, CEO and co-founder of HackerRank. Each month we'll talk to top engineering leaders about solving one of the toughest problems today, hiring the right developers. Today I'm excited to welcome Rumpa Giri the CTO of ForeSee medical, a health platform geared towards helping physicians. She's been working in the healthcare industry for over a decade and as you know healthcare is both challenging and it's also super hard to disrupt. So, we're going to talk about how to build a really strong engineering team in the healthcare space. Welcome to the podcast Rumpa. What was intriguing about software and were you like a self-taught developer for the most part, I'm assuming this was when you just graduated. So, would love to know how you got started with this?
Rumpa: After my graduation, I did an MCA in the same university and through the campus placement I got a job at Hughes, we were doing C++ programming and all, but when I came to the states it was not C++ I had to learn other languages. But anyway, by nature I’m curious so it's kind of like you ask one question and then you just keep digging until you figure it out. It's project-based learning I would say mostly, rather than being self-taught. I have to have a question in front that I'm solving, and then you just keep on digging until you figure out that it's all working, as per user expectation.
Vivek: From there when you got started with developing software to now CTO, do you still code and if not do you sort of miss coding. I would love to know how the role changes, because a lot of times developers have this thing of do I need to go in the path of a developer, a senior developer, a principal engineer instead of like a chief architect, or do you want to go down the developer engineering manager, director and CTO. And sometimes you can end up being a CTO or VP of engineering for multiple paths. So how did you choose to go which path you wanted to take?
Rumpa: My transformation happened during HealthFusion. So, at HealthFusion, I was the first engineer. I was a one-man show, but I was the team lead with no team members. We got a few developers together, but all along during my time at HealthFusion, I always coded, in spite of the fact that I was the director of software development for a long time. That folds into how HackerRank comes into picture. I've always tried to recruit really bright engineers who do not need a lot of management. I need to make sure that I completely help them understand the context behind what they're about to do, that they are independent. This helped me, like I have enough time to do hands-on coding and there is no management involved after I define the problem and I let them go and then they'll solve it. But in between I had enough time to explore, and that's whether it's new technologies coming up, so it leaves you enough time to explore. But mostly I think I hired very carefully. That gave me a lot of time and because if you curate your team properly, the execution usually goes as per planned, I won't say we delivered on the day that we promised, if we missed, but at least meets customer's expectations. There were less bugs, less for me to do in terms of band-aids.
Vivek: How did you figure out this particular skill of an engineer during an interview, what you're essentially describing is, hey if I give a problem this person will sort of either come up with the solution or once we bring someone a solution be somewhat independent to go ahead and think through all the use cases and go and implement that. That's pretty hard to figure that out in an interview. Walk me through how your interview process looks like and how you extract this skill?
Rumpa: As engineering team lead I like to be very transparent in terms of expectation and that's part of the feedback loop that I developed watching continuous delivery. Because we transitioned from a three-month delivery cycle to a weekly delivery cycle. That kind of taught me also that that same process has to happen with engineers, because if they don't understand what my expectation is early on, then obviously there will be conflict down the road. Most of the hiring comes up as do we like the candidate, but the criteria of hiring is that first of all, they have to be very humble. And then obviously I'm looking for the curious. I have always worked in startups, so the problem definitions were always fuzzy, we have to do something for the customer and because we're resource constrained, it was always the engineer who is the person wearing multiple hats of I have to dig deeper in redefining the problem, what exactly am I doing?
So that independence has to be there in the engineer. So in between, I think the engineer has to be willing to just go through and like okay that didn't make sense, like you are relentless but you're constantly pushing yourself. And that's where I think HackerRank falls into the picture with when we tell the engineer that there is a test, typical answer is why there is a test? They already shut down that it must be hard, and I can do it. You just trust my resume and go with it, and we will talk. But that kind of makes me uncomfortable that what about or you are not willing to see it to understand is it even hard. It's like all these different factors have to all gel. Even at HealthFusion we were small, but we need a lot of people, and it was not feasible for us to ask all these thinking questions with four of us sitting in a room, one candidate at a time because otherwise we won't be coding at all. We did have a recruiter who cleaned it, but it's one thing to go through your resume and actually be able to see how you think if you are given a problem, and because the majority of our problems they need a lot of thinking.
Once you nail down what is the problem and how I am going to solve it everything else falls together beautifully, but it's the thinking that I feel like has to be right, rather than everywhere is going and I'm just Skypeing and coding and hoping that it will all come together. But through the HackerRank like the code snippet, I could tell what is their pattern of thinking, and not necessarily we're not looking at your scoring 100 on 100, that's not the goal. But even if you did one problem, it gives me a reflection of how did you do it, and what was your thinking pattern in solving. Am I able to read your code? am I able to make it or am I only relying on the 10 test cases they checked? So, we kind of look through everything to make a judgment, okay next we bring them over for a one-on-one.
Here we started doing the code, we give them a simple system to design, but we are just waiting for them to understand, looking for what kind of questions they are asking, just regular flow of conversation. And we do it in a group setting, it's never one on one, and part of it is because I want all of us to be comfortable with that person. So, most of the engineering hiring decisions are a group decision, everybody felt that yes, that person is really good and will contribute to HealthFusion. That comes from the fact that when we hire, our objective is we're going to hire you for a long-term, we are not doing a consulting, at least what I have observed that to my knowledge that takes a long time to build. And hence if we have a good synergy and that domain knowledge builds, I don't want to lose that employee. Languages they can learn 10 times because that's their skill, the domain knowledge is very precious to me. It's important for us to match it from the aspect that this hire is a long-term hire and we are all to be successful together.
Vivek: That definitely makes sense. So, what would you say specifically on the healthcare industry, maybe zooming out and having somewhat of an unbiased perception, pros and cons of an engineer working in a healthcare industry. Obviously, you can't move things and brake fast in a healthcare industry and especially in medical health app. And probably do it like a consumer application. So just curious to know if you were to like have an unbiased view on pros and cons, what would they look like?
Rumpa: One thing that the developer has to be aware of, because it's healthcare, if there is an issue you better be available when somebody's calling. Because you have to have that mindset that you are about to impact patient care. So, think about, you know like we did the EHR, and it has e-prescription, the code is not working, but when you look at the impact there is a mother waiting for the prescription for her son. The engineer has to be aware of the downstream consequences. It's not just I'm getting a call at like 4:00 AM, but it's more about if I don't fix it somebody is not going to be well. Yes, the physician can write a prescription and call the pharmacy and order it over the phone. But look at the impact, the physician woke up, the mom is nervous, worried sick that what's happening, why am I not getting the prescription?
So, they have to be well aware that it's a 24/7 job, but at the same time if through HealthFusion we made sure that most of our releases are during the day, we never did in the middle of the night because there's no customer to give you feedback if it's not working. So, we kind of like after 10 years old that lifecycle we deployed but it has an impact, we've switched to continuous delivery and that was, it brought back our work-life balance. The engineers were much happier because we deployed at 1:00 PM Pacific Standard Time, but still there is room for the doctor's office didn't close yet in the west coast so I can still get feedback and switch verses not switch. The engineer has to be aware of that yes, it's a 24/7 job, but again they shouldn't be concerned because if the system is setup in a way that the feedback loop is quicker, and you can easily be covered, because you won't be called at four in the morning, but you should be committed to, I must help and not treat it as a job.
Vivek: Do you think it's more attractive to developers as in just thinking through it, you just care about your code so much that it should be bug-free. I mean that's what every developer will want to do, but at some level for a lot of different consumer apps, like it's not going to really impact someone's life, but in this case it could. So, do you think it attracts people or this scares people?
Rumpa: It belongs to people self-selecting their lifestyle if they care about that my work has to have an impact I think they will do the self-selection. Then again not like you are not doing that. I'm going there for a job to pay my bills, I do want to make a meaningful impact through my work to someone's life, from looking back and how long I have worked with so many engineers I have hired they stuck with me forever until I joined here, I never questioned.
Vivek: How much of domain knowledge is important to join a company like foresee medical, domain as in healthcare knowledge is important versus how much can I pick up once they join.
Rumpa: I don't think anybody comes from healthcare domain knowledge perspective and that's where I'm trying to focus my energy in educating them on all the contextual domain knowledge of the next problem that we are about to solve, and that's very important to me. You will write code, you know already how to write code, but if you don't understand the problem, you won’t design it right, that interplay with your knowledge of domain and what you learned in school influences your design decisions.
Vivek: What kind of advice would you give for an engineer who is sort of considering, you know I really want to go in the engineering field, but I'm not really sure if I want to take the managerial path, or the sort of principal engineer as chief software architect path, what would be like a framework for an engineer to make a decision like this?
Rumpa: It's a question for self-reflection. What gives me more pleasure, that if you are an engineering manager you are away from coding you still are hands-on and coding, but you are in your heart an engineer, but you have to kind of self-reflect. Do I enjoy growing people, mentoring people, seeing them flourish?
Vivek: Got It. This is one question that we ask all our guests and it does not have to be recent, it can be anytime in the past as well. Talk to us the biggest production bug that you've made?
Rumpa: I have a great one, I remember I had just started at HealthFusion and it was new to me, HealthFusion started but HealthFusion had an engineering but it was all done by a consultant. So, my very first job was to bring everything in-house and start the engineering department here in San Diego. So, we did like all that channeling back all of the data back to our database and everything went well. So now we are doing our own development and we are doing claims processing, so claims guides which tells you like this field is this, this field is this. And I flipped one of the flags of who gets the payment on patient consent. And soon enough all of the physician's offices started calling saying, and the patients was generous enough and kind enough to state why am I getting the payment from insurance company and the doctors were complaining like we are not getting our check. And then we kind of like pieced it together, that I had made a mistake, that was a unique mistake which flipped my association with HealthFusion because it was so embarrassing for me, I worked day and night to make sure that I'm able to correct and resubmit all the claims. I don't know how many hours I spent.
Vivek: That would be like a real disruption to the industry.
Rumpa: Yes, yes, yes. But we were only very small then, so our footprint of customers was very small. But we were able to correct it, and what was beautiful that seeing all that hard work, my supervisor who was the CEO, he got me like a bunch of flowers. I was already embarrassed enough, and he was like you are working too hard. And that kind of changed my perspective, my respect for him in terms of like how forgiving he was to such a blunder that impacted every customer, and he never reprimanded me, and that also lead the culture down the road for HealthFusion, but yes you will make a lot of mistakes, but we must recover. So, we must pick ourselves up, don't dwell on it, learn from it, make sure that you never commit that mistake, whether it's through system architecture, fixes, just being more aware, do something so you do not repeat it. And it became my mantra that you can make a bazillion mistakes, but your intersection has to be zero. It was quite a mistake.
Vivek: That definitely ranks among the top bugs that you've had.
Thank you so much for the listeners, if you have any specific questions or topics, tweet to @hackerrank. Thank you so much.