This is the second episode of HackerRank Radio, our new podcast for engineering leaders interested in solving developers’ toughest problems today: Hiring the right developers. Hosted by Vivek Ravisankar (CEO & Cofounder, HackerRank). You can subscribe to us on iTunes and Google Play.
Today, we're excited to announce the publication of the first annual 2018 Developer Skills Report! For the first time ever, we surveyed our community of 3.2 million developers to get a pulse on the state of developer skills today. Over 39,000 developers shared their thoughts on what new skills they're learning, how they evaluate employers, which languages and frameworks are their favorites, and much more.
Read the full report here.
To commemorate the survey, HackerRank's CEO & Cofounder Vivek Ravisankar sat down with veteran VP of engineer Jawahar Malhotra to unpack some of the findings. Jawahar’s scaled up teams for all of Yahoo India, Open Gov, and Tealeaf. In fact, he’s been at the core of the Web's evolution since his work at Netscape in the mid 90s.
Listen to the 30-min podcast, or read the transcript below.
[powerpress]
HackerRank Radio | Episode #2
Vivek Ravisankar: Welcome to HackerRank video episode #2. I'm Vivek, one of the co-founders and CEO of HackerRank. Today we have a special guest, Jawahar Malhotra, who has scaled engineering teams and various companies starting from Netscape, Yahoo, IBM and currently at HackerRank which is also where I work. Welcome, Jawahar.
Jawahar Malhotra: Thank you Vivek, good morning. Good morning to all of you.
Vivek: Today we launched a survey to our community to understand the developer persona in various dimensions of developers right from when did you learn to code to what are the three things that you looked for before you accept the job offer. We got close to 40,000 developers responding to our survey and have some really interesting insights to share with all of you. You can download this report at research.hackerrank.com, but today we’re going to discuss some of the key insights from this report. Okay. Are you ready Jawahar?
Jawahar: I am ready. Let’s go for it.
Vivek: Okay, maybe before I want to do the intro of you, but I think that it would be best if you give a quick intro and background about yourself and then we can get started.
A little background on VP of Engineering Jawahar Malhotra
Jawahar: Sure, sure, sure. So I've been at HackerRank for about six or seven months. Prior to that I was VP of engineering at a number of companies OpenGov here in Redwood City, prior to that I was at IBM and Tealeaf, and before that I spent about seven years at Yahoo. In the mid ‘90s I was at Netscape as an engineer building some of the technologies for the web mostly on the server-side.
Vivek: Okay. This is a question that we ask all our guests in the podcast and it is very interesting when we launched our survey to find this out as well – that one in four developers started to code before they could drive and I'm curious when did you start to code and do you remember what’s the first application that you built?
Jawahar: So I grew up and up to high school in India, so the first application – this was at a time when we did not have personal computers, so the first thing actually it was in Fortran and it was without actually a real computer. It was really studying a book and trying to write some numerical complication algorithm. I then subsequently went to New York and when I was an undergrad I wrote my first program in Pascal.
Vivek: Do you remember what it was? Was it a calculator? Was it was a hangman?
Jawahar: Actually the first main-like thing I did was others as LaTeX and TeX which is this language for setting and so I built a graphical tool for people to create diagrams and then in it LaTeX and TeX code, so it was a code generator.
Vivek: Wow. We still use LaTeX for our problem statements.
Jawahar: I love LaTeX.
Vivek: Yes, yes, yes. Do you still remember the Pascal and Fortran code?
Jawahar: Kind of, yes.
The explosion of JavaScript
Vivek: Okay. Moving on, we got a lot of different insights and one of the things that you are starting to see is the JavaScript frameworks are just growing like crazy over the last four or five years. And when I was in college maybe, seven years back, I was still coding in native JavaScript and maybe that was Jquery, which allowed you to manipulate dom elements easily. But of late just in the last three or four years there Angular, React, Backbone there’s just a flurry of JavaScript frameworks. Do you think something happened or have you been seeing this happen for a long time? Also, I just wanted to clarify a rumor that you built JavaScript and you when you were at Netscape, so if you could walk us through the evolution of that.
Working with JavaScript creator Brendan Eich
Jawahar: Well, we take care of the rumors. So I did. I did not build JavaScript from scratch. I had the good fortune of working with Brendan Eich who is actually the inventor of JavaScript and the story, I’ll make it very quick was Brendan was busy working on a browser manipulation language. Those were the days 1996 of static web pages and so he was trying to give some control in the browser so you can manipulate what came down from the server and make the browser a little bit more interactive because we had just shifted from heavy, rich desktop apps to a browser other was almost frozen.
So as he was doing that we were working on server-side technology and server-side was also CGI-based. There was no server-side scripting and so we kind of brought those together and said, “Can we take what Brendan is doing on the browser? Bring it into the Netscape web server?” So I took on that task and worked closely with Brendan for about nine months. The big challenge was what he had written was single threaded – because the browser was single threaded, our server was multithreaded and so I have to spend nine months pulling my teeth out and my hair out trying to fix all the raised conditions as I made the JavaScript engine multithreaded. Plus we put a bunch of enhancements into it so database access and stuff, so our first server-side scripting was you could actually render a page with data from a database.
Vivek: Interesting. And did you think that this language will actually take this kind of a shape over the next 10-15 years? Did you imagine that?
Jawahar: No we did not. Because the other interesting bit was we were in close partnership with Sun Microsystems, so Netscape and Sun worked very closely together because we used a lot of sun hardware and so Sun was basically creating Java and the whole vision was Java applets would be the thing that would run on inside the browser and so JavaScript was the site thing and history says that that was completely wrong. Java applets never really took off. JavaScript became the main powerful language to manipulate the interface in the browser.
How did JavaScript get its name?
Vivek: Wait, is that how JavaScript – the name?
Jawahar: Yes. That name also came because of that.
Vivek: Oh, interesting. I didn’t know that.
Jawahar: So we actually aligned our launches and we were calling our stuff LiveScript and Java was coming out, so we aligned everything and we thought that we will call this JavaScript and you guys call that Java and JavaScript was a language to manipulate the applet in the browser. It was the periphery of the applet, but instead it kicked the applet out and became the main thing.
Vivek: Yes. I remember learning Java applets and there were no websites that were doing Java applets, so I pretty much didn’t go anywhere. But then coming back to this, why do you think this sudden increase in the number of frameworks – there seems to be a sudden buzz about JavaScript as a language and framework over the last four years or is it just me who's seeing it?
Jawahar: So I have to tell you an old story before I answer that question. I think it leads to the answer. I just met one of my professors from 30 years ago for lunch three weeks ago and I told him the story about JavaScript and he actually said – back then I used to work on Lambda calculus and programming languages which is the foundation for JavaScript and he was like, “You guys really screwed it up.” Because JavaScript in some ways it's becoming better over time, but it really took what's very pure, Lambda calculus, which is of pure mathematical thing and made it very loose and it's not pure functional.
It's got lots of imperative things going on, state, and it's manipulating the dom, it's kind of lot of crazy stuff going on there. So it's not a good purist computer science stuff, but I think because of that and the big need for people to build using interfaces because the web, I think, has brought a lot of consumer – has brought computing in the hands of everyone and mobile has just accelerated that. And so there's so much need for front-end work and the people who work on front-end they generally – it's constantly changing, the interfaces and the UI, UX, and so the environments need to continuously evolve to keep up with that change and if you contrast that with back-end the back-end doesn't change that much. It’s much slower and so
JavaScript has become the language and then everyone is looking for structure so that you can create maintainable apps, you can create apps with less code because you know when you started, you had to write lots of code and today you can write a little bit, like React makes everything reusable component types. So there's that constant quest for keeping up with the new hardware and the front-end capabilities, but also to put more structure and put more frameworks. And so every framework comes up with some approach and then someone else comes up with, “Well that's bad there and I'm going to do a little better.” So it's proliferation of this happening in the marketplace.
Learning & the cultivating developer happiness
Vivek: Yes. That's very interesting because one of the things that developers mentioned in our survey was one thing that they cared a lot about when they work in a company is the rate at which they can learn new things. And the rate at which new frameworks are coming, people are abstracting out different layers and making it easier for people to build things on top of it.
Jawahar: That's right.
Vivek: And do you sort of resonating with this notion of one of the important things for a developer when they work in companies is how fast they grow or how fast they learn?
Jawahar: I think it's a really important thing. I think developer happiness is equal to how much they're learning and that's a function of how many interesting challenging problems that we as leaders are presenting to them. If they are in an environment where they're getting harder and harder problems and they can feel like they're cracking more and more hard things, they're going to be really happy and you're going to have a very high retention. So it's very true that developers love to continuously grow their knowledge.
Vivek: Yes. And also, one of the trends that again we believe that in the survey was how people move from one framework to another. As you know, I've been a developer it's been a while since I coded, but there is this constant pursuit of, “Oh there is this new shiny thing. Let’s actually go ahead and build this one on top of that. Let's actually change our infrastructure.” How do you balance learning new technologies because you can't constantly keep changing whenever a new thing comes up. But also developers love to learn new things but he can't possibly change things on production. How do you balance that when you're building up an engineering team?
How to balance desire versus focus
Jawahar: Yes. So I've seen this phenomenon multiple times and I've had to control it. I think it happens a lot more with front-end teams than it happens with back-end teams. So I had this situation a few years ago where the front-end team which were amazing people, but they kept changing the storage and state management in the front-end. So for example went from Flummox to Redox to graphQL, to like just kept going on and on and on. And so what I had to do was put some process and structure in place where before they could add anything new into our stack they actually had to go through some approval and architectural design review and approval before adding anything new. There was a little bit of resistance, but I think people eventually got the point that it's okay to prototype new things, but it's not okay to keep adding new libraries into the production code because that can get you into lots of trouble down the road, so putting some process around it kind of finding that balance.
Evaluating the rate of learning in an interview
Vivek: Yes – between developer happiness like you mentioned and ability to do it. Given this is going to be the trend for quite some time, yes there are going to be some new framework, some new things that’s going to keep popping up, how do you evaluate this sort of trait for you to get accustomed to new environments as a developer during the interview process? When you look for? Because you could verify the proficiency of somebody on React, but how do you know for sure that this person will actually be able to get accustomed to a new framework that’s going to come tomorrow during the interview process? What is the foundation or what do you look for when you're interviewing these talents?
Jawahar: So let's take React as an example. There's a lot of concepts that are built into React the way manipulates the dom. Is it MVC? What aspects of MVC does it use? How does it do state management? What is pure functional state manipulation? By probing into those deeper things that go above or beneath the veneer of React, you kind of get better understanding from them. Do they really understand what's really going on behind the scenes? Do they understand how a browser dom gets manipulated? What is dom differencing? What all are these concepts and technologies behind it? If we are confident that they understand all of that, then we are confident that they can actually move to another framework should a new one show up.
Problem-solving skills vs. framework knowledge
Vivek: Yes. One of the things that we found was, which is really interesting, is almost all employers prioritize problem-solving skills first in the interview process. People call these different things – problem-solving, computational thinking, breaking down a large problem into subproblems. How much importance or weight do you get when you're interviewing a candidate for knowing a particular framework was actually understanding problem-solving skills?
Jawahar: I'd say problem-solving is probably 10x over knowing a framework.
Vivek: Interesting.
Jawahar: And I've also been interviewing a bunch of other execs like myself, heads of engineering and that's very consistent. They all kind of echo that. It's really important for the person to be able to solve problems and they don't have to specifically know the framework that we are using. They could know something else, but the fact that they can solve problems and they can think computationally, they can decompose problems means that they will be able to learn something new quickly. I'd say problem-solving and quick-learning, both of those are really important. If you have that combination you can pretty much pick up anything.
Advice for developers who self-teach on YouTube, etc.
Vivek: Yes and given the sort of spread of Internet and when we did the survey, we asked different questions about their background and persona, one of the interesting thing was 74% of people even though they have computer science degrees or some sort of STEM degree, they were self-taught in terms of programming. There's a huge shift in the way people learn to code, how people adapt and also the boot camps and others are also sort of pushing this trend of you can learn to code anywhere.
You don't necessarily need a computer science degree for you to learn how to code and what I've noticed or seen as most of these online courses are things that focus a lot on this, “Okay, learn React in 10 days.” Learn in 10 days, and learn this particular in 10 days and not focused a lot on problem-solving skills where there is some sort of a disconnect in terms of, “Hey, what are you learning in all these self-taught or boot camps and others?” – Which is what do you look for in an interview? What would be your advice for self-taught developers who are just going to learn on their own on how do you balance of understanding the code underneath, the competence of it or is it just knowing the framework or language?
Jawahar: I think everything you said is true. That's been my experience too, but there is a lot of online video-based YouTube, Udemy, Udacity. I think the reason why a lot of that comes up is because it's become so much easier for a person who knows React to record 30 video lessons which are very tactical. They are more about, “Okay, this is how you do step A, step B, step C, and you can get a map built at the end of it. It’s very gratifying, very fulfilling, and they can create a course out of it and then a million people can watch that and actually get the same result. So it's great there's nothing wrong with that.
There's a lot of that happening and it's a good thing that people can actually get to that point very quickly. But if that's all they do and I've seen this happen with React and I myself have done some of these courses with Spark. With creating a book it takes a lot longer to actually get a book organized and there you have to really go deeper into a lot of material, so videos and online courses are great because they cover on the surface. Now if a person who's taking these courses, for example, myself, I already have a computer science foundation, it's okay because I'm only building on that foundation.
If you don't have that foundation and you're just doing these classes, my recommendation would be to find opportunities where they maybe take some classes at a slower pace at maybe a university or an online class, not the superficial one but deeper classes for the foundational pieces that go beneath what you're doing. So really go understand HTTP at a deeper level, go understand caching at a deeper level if you want to be a really good front-end developer. Does that make sense?
Degree or no degree?
Vivek: Got it. Yes, yes absolutely. And in line with that, this is probably a trend that's going to be there for a very long time probably for the decade or more. And I'm just curious as a hiring manager how much importance or weight do you give to traditional computer science degree. For example, if I'm going to interview with you and I don't have a STEM degree or even a computer science degree, but I have good understanding of problem-solving skills and a particular framework, I've built some certain things, am I on equal footing versus somebody who has a foundational CS degree for four years?
Jawahar: Yes you are on equal footing. So the computer science degree is important, but if somebody doesn't have it but they can demonstrate to me that they have a lot of the skills that are needed, at the level of depth, the degree is a nonissue completely without any doubt. The challenge we face is it's very hard for developers who don't have the degree to gain visibility with someone like me. It's very hard for them and that's why I think HackerRank actually is creating a platform for that to happen, for developers to actually be able to surface themselves and showcase.
Now GitHub has actually done that somewhat successfully and I've actually hired people, excellent people, through that mechanism. People who have contributed to open source and brought those people in fact that was in the context of React and I had an engineer we hired. He was really successful and he moved on actually to the Facebook core React team.
Work-Life Balance is increasingly important to developers today
Vivek: Moving back, you've managed and grown engineering teams for the last 25 years from Netscape to Yahoo to IBM and now at HackerRank, what have you seen a change in what developers want? One of the things that we observed from the survey was, which was a little surprising to me at least, was the biggest thing the developers wanted when they moved to Java is work/life balance. Well of course work/life balance is important. I don't deny that. I didn't expect that to be one of the top three or the most important thing. I'm curious to know have things changed over the last 20 years of what developers want when they look for new jobs?
Jawahar: Yes. I mean, I was just traveling over the holidays and at multiple airports I saw huge billboards of AWS.
Vivek: Yes, yes.
Jawahar: You probably have seen them too.
Vivek: Yes, they're going crazy.
Jawahar: That is a complete sea change over 20-25 years ago where developing or writing code or being a software engineer was this very niche thing, now it's very mainstream. Every person on the planet is touching technology every day multiple times. Internet of things and mobile phones, cars, medical devices everywhere and everywhere developers are a key. That's a big difference and so because of that and because of the shortage of developers the whole group of developers have become very powerful.
Vivek: Yes. The salaries are also pretty high in this area.
Jawahar: Yes. And I think that's consistent across the world. So they’ve become very powerful, they're empowered to demand more things. In some ways back 25 years ago, they were kind of in the back office, now they are in the front office, and so that's a big change that I think that's happened.
Vivek: And what about work/life balance? Do you think that is still, like 25 years back or 20 years back when you were in Netscape or Yahoo was that one of the top considerations for developers before they joined the company and how has it changed now or has it been consistent?
Jawahar: Those were startups. Netscape was a startup. There was always a lot of work and that’s life and that's been the case in Silicon Valley consistently. I think I'm hearing this now recently where developers feel empowered enough to demand, but even though they do, most of my teams even in the last 10 years, people work really hard. I think they enjoy working. They enjoy building. I think the good thing with developers is if you give them an interesting problem to work on, and I've done this myself, you’ll work the whole night and it's not because someone's forcing you to do it. It's just because your mind is sort of saying, “I got to solve this.”
Vivek: Yes.
Jawahar: So they're demanding work/life balance and maybe as leaders we should accommodate that need, in spite of that I think a lot of people are going to work really hard.
Vivek: Yes. And you're right, which is – I always ask myself or that I'm biased because we've started HackerRank and we're in the developer space that there is – everything around me like when I go to San Jose Airport, everything around me is AWS, is it because I'm noticing these billboards because I'm part of HackerRank? Have these been there for 10 years or is it because there's a sudden change in the whole developer landscape and probably this is a change that's happening because every company is becoming a software company. It doesn't matter whether you are a retail, financial services, automobile, you're all at the core of it, you're all building software to it.
And how do you think about if that's going to be the world which means originally it was Google, Facebook, Amazon competing, now you're competing with probably everybody out there in every single industry, how do you think about attracting developers and what are some of the things that in terms of a talent brand – I almost think whenever I go and see a lot of customers they have a generic talent brand and then they have a separate thing for here’s who we’re going to attract developers quickly. If you were to, sort of you had infinite resources, money and all of those things, what are some of the things that you would do in terms of a talent brand or a developer brand to attract more developers to your company?
Building a Developer Talent Brand
Jawahar: Yes. I think we touched upon many of these in our conversations so far. Developers like to solve problems. That's why they get into the field. They like to learn as they solve those problems. They like to learn new technologies, new ways of solving problems, new techniques. So I would say if you can offer them those, those are the raw materials, they'll be happy. In addition, they like a culture that is developer friendly. Now we can talk all about what that means, I'd say some work/life balance, open environment, open communication, mentors who they can turn to for help, a culture where there's collaboration, and it's not like, “Okay, that guy you cannot talk to because he's really hard to communicate with” – the senior bodies are hard to communicate with. You want to get rid of that kind of thing and you want to have a culture where it's open communication, collaboration, learning and you learn from each other and you have hard problems to solve and you feed them well. Give them food and drink unlimited and I think that is–
Vivek: Is that a thing that Google drove or was it true before that?
Jawahar: It was not true before.
Vivek: I see. So Google was the driver of the free food thing.
Jawahar: I think Google changed it, yes.
Vivek: Interesting. And do you think people are doing enough in this whole talent brand to advertise themselves as developer friendly because it just gets diluted if you are just going to have a genetic brand across all of the different organizations that you're going to hire versus developer focused. Do you see companies doing develop or a brand specifically?
Jawahar: I see that a lot of times you'll see that in the form of a developer blog and the good ones will actually talk about very meaningful things that they're doing. Another thing developers actually, like, this new generation of developers since the open source world has started and this is a very good thing, a lot of my team members have said, “We don't want to just be consuming. We want to actually give back.” And so, if the company can actually create like one or more open source projects where they're contributing back and are allowing their developers to do that, they love to do that and I think that also becomes an important thing. Like Facebook with React, they're giving back and a lot of people end up wanting to work on that technology. So I think companies who are contributing to open source who are creating a developer blog and publishing information about what they are doing inside sort of sharing with the world, Spotify has some really nice videos about the way they organize process for developers. All of those things attract developers. So a few companies are doing it well, a lot of them are not writing and I think they're not maybe aware of how important that is.
Is there a talent shortage?
Vivek: There is this common theme at least in Silicon Valley that's going around that, “Hey, there is a talent shortage.”
Jawahar: That's right.
Vivek: What are some of the ways that you think we can solve and what are some of the non-traditional ways that you have taken in your career to hire developers?
Jawahar: So I do agree there is a talent shortage. It takes a lot of effort to fill positions and it's become even more common now that people have multiple offers. Even though you like the person and they like you, they may have three other things they like and so you're always competing to close and lot of times you don't close. It is a big problem. Some non-traditional approaches that I've used, one is I’ll look at other locations. Fortunately at HackerRank we already have a great presence in Bangalore. Typically I'll look at other cities where there are universities and educational institutions where people are being trained or I also look for clusters where there are other companies. For example, I think North Carolina where IBM has a big presence has a lot of people there who you can potentially attract. If you set up as a start up, you set up a company, I'm sure the IBM colleagues there will not—you know what I'm saying?
VIvek: Who are the best two programmers [crosstalk] for IBM?
Jawahar: And by the way, this is a very positive thing. IBM has amazing developers. In IBM, there are lots of people there and they are amazing people. So look for clusters where there are companies where they may have people who might be willing to move and try out something new. Bootcamps has been another trend that's been going on for maybe, like, the last five or six years and I've hired from there, have interacted with them, I've helped bootcamps and I've got mixed results. I think for bootcamps to become more sustainable and to become a true source of delivering developer talent they need to go deeper in the material and maybe even have the bootcamps be longer term. A lot of times I think they are more like the online courses. They take a package thing like front-end developer and they try to cram it into two or three months or something.
Vivek: Yes.
The state of bootcamps today as a solution to the talent shortage
Jawahar: And it's very hard to get the full depth that way. So I'd say that's another way to attract. Looking carefully across, people use LinkedIn of obviously but using more locations where developers hang out like GitHub, Stack Overflow and any other security oriented very niche communities across the web, HackerRank is also good community to look at, you'll find people who are interested in a certain topic and so I've used that mechanism as well. We hired somebody for React through GitHub. I've also hired through meet ups like where I went to an android meet up and I hired somebody and trained the person and got an IRS developer out of it. So those are kinds of very sort of niche techniques that you can use to go find people who might be passive and they're not actively looking, but you can pull them out of where they are. What do you think about bootcamps?
Vivek: Like you mentioned, I think it's definitely a big source or a potential source of a new set of developers or talent that's coming. It's definitely heading in the right direction. But I agree with you that bootcamps could take a longer term approach and even when you look at the survey, bootcamps was ranked lowest or in the bottom three or bottom four. And I think the reason is partly because of the way this position are structured, which is you don't know anything about coding, come here and in three months and you can learn how to code and then get $100,000 salary. I mean, by default, that positioning seems odd when you think about it as a BP of engineering as a hiring manager. How can they do that? And I feel if people took a longer term, that this would be my dream bootcamp if I were to structure one which would be, “here are all the different disciplines of computer science, data science, security, front-end, back-end and others” and just go ahead and build out a simple app or whatever for each of these different domains. Just go ahead and look and see which one you're really attracted to. You're really attracted to building an iOS app or you might be really attracted to processing large amounts of data and deriving sites from it, which means you need to take different tracks or different courses.
And when you don't have a traditional background in computer science and you just say, “You know what, come here and learn front-end developing.” It's just hard. You might not even like it. That's how I would structure, which is a phase one, is know what you're passionate about and phase two is, “Okay, once you once you learned what you're passionate about, let's just go super deep and try to make you a master in that.” I think the closest one that I've seen this is a school called 42. It's actually a French school and they've just started in sort of a branch or division here in Fremont. I visited there, so you can just go in and they have a map of here are all the different skills and you just choose one of them and you just continue to learn and you can go as deep as you want after you pass a particular level or a particular stage and also the timing varies.
Some people could do it in three months, some people could do it in nine months because the rate at which people learn are different. And then after you pass a particular level, they help you then connect with companies. It's not a finite time that you have to graduate or you have to pass. If you're rate of learning is high, you can actually go and get connected to another company. But it's super learning on one particular aspect that you are passionate that you like about it, which means you're self-learning capabilities just grow. Again, I'm not sure how many companies hire from 42 and others it's growing pretty well and HackerRank is also a partner with 42. But that's one thing that is closer to what I would think about an idea of bootcamp.
Jawahar: Yes. So your comments about the boot camp are quite interesting. The school sounds very promising. I think adaptive learning is a good way to go. But another thing to keep in mind is as we end up with a large number of non-traditional sources of developers, we're going to have to start thinking about how do we assess them the traditional way of looking at a resume, I mean, like a resume of somebody from a bootcamp it's not going to tell you very much because here we're discounting even university and stuff, which is, is one boot camp better than the other maybe, but it's still not enough. So what you'd really really need is for that person to be able to showcase what they can do – their skill. Ideally, they can have a portfolio of work that they can show you. But in the absence of that, some sort of automated way to assess that if they don't have that already would be a very good way for a hiring manager, for an organization to go at scale and assess lots of these people and only bring in kind of filter out all the people who are not a fit. And I believe HackerRank is trying to do both of those things actually. Assessment is already a very well-known capability, but your vision is to create developer profiles and let people showcase what they are capable of doing.
Vivek: Our vision and HackerRank why we started it and our mission is to match every the developer to the right job with the underlying driver being skill. And I imagine a world in the future where every developer is getting hired, can showcase a skill purely based on skills and not bias to what school did you go to, which company you worked at before and sort of democratize recruiting and make it an even playing field. There are many more interesting insights for all of you. You could go to research.hackerrank and download the developer skills report for 2018. We plan to do this every year.
Rapid Fire
Okay, we'll probably end with a quick rapid fire and it should be straightforward. Vim or Emacs?
Jawahar: I like Emacs.
Vivek: Tabs or spaces?
Jawahar: Tabs.
VIvek: What's the language or framework that you're learning right now?
Jawahar: Scala?
Vivek: Thank you so much for the listeners. If you have any specific questions or topics, tweet to @hackerrank and I will see you in episode 3.
