Home
/
Blog
/
Developer Insights
/
How to become a better developer: Top tips from 15 industry leaders

How to become a better developer: Top tips from 15 industry leaders

Author
Rohit C P
Calendar Icon
January 3, 2017
Timer Icon
3 min read
Share

Explore this post with:

Last week when I sharedThe top programming languages that will be mostpopular in 2017, the frequent comment was, what does it take to be a better developer?

I’ve met some amazing developers in real life and through React Native Community, and I decided to ask them, “How do I become a better developer?” Thank you to everyone who took the time to answer these questions with passion!

This is a compilation of answers I received from them. Some of these quotes are not limited to answers from that specific question.

Interviewees / Current Position

  • Aravind Kumaraguru (Engineering Director @Pioneers in Engineering)
  • Brent Vatne (Front-end Developer @Exponent)
  • Charlie Cheever (Co-founder @Exponent)
  • Christopher Chedeau (Front-end Engineer @Facebook)
  • Dan Horrigan (Senior Back-end Developer @Futuri Media)
  • Frank W. Zammetti (Lead Architect @BNY Mellon)
  • Janic Duplessis (Co-founder @App & Flow)
  • Jake Murzy (Co-founder @commitocracy)
  • Jun Ho Hwang (Software Engineer @Coupang)
  • Keon Kim (Machine Learning Maniac @NYU)
  • Munseok Oh (Co-founder and CTO @Sketchware)
  • Satyajit Sahoo (UX Lead @ Glucosio & Front-end Engineer @Callstack.io)
  • Sonny Lazuardi Hermawan (Engineer @Sale Stock)
  • Sunggu Hwang (CTO @ScatterLab)
  • Timothy Ko (Software Engineer @Snapchat)


Q&A

Aravind Kumaraguru

Aravind is an undergrad at UC Berkeley pursuing a degree in Electrical Engineering and Computer Science and is Engineering Director for the nonprofit organization Pioneers in Engineering.

Q: How do you think I can become a better developer?

A: Obviously, never stay complacent with what you know – this field changes ridiculously fast, and you need to keep up with it. Follow along with the news in the tech industry, perhaps read up on some source code for a Python module that you recently used.

A friend of mine had some free time over winter break, so he decided to teach himself Django and build a webapp that he could interact with over SMS. It’s sort of a toy project, but he really enjoyed learning the different development paradigms. For context, he specializes in embedded systems and robotics, so this is nowhere near his comfort zone.

But pushing yourself to try different things will make you much stronger as an engineer. I personally wish I had done more web stuff before this year – in my organization (PiE), we’re developing a new iteration of a robotics kit to be used by high school students. While I have a good grasp of the low-level and systems stuff, I’m at a loss when it comes managing our UI design. Never had an interest in doing that type of stuff full-time, but having even a surface-level knowledge can be immensely helpful

Q: Do you have any projects you did to push yourself out of your comfort zone?

A: I built an automated door opener last summer, which operated a mechanical lever to open a door when an RFID card was scanned. The project used a really powerful motor and a mess of sensors to track the state of the arm, which proved to be quite difficult to coordinate. I learned real quick that I would need to do a bunch of offline testing before running my code on the device, which was very different from what I was used to up till then.

In terms of academics, I just finished CS 189, which was a massive crash course in data science, optimization, and probability theory. The programming I did in that class was also very different from what I’m used to, even though it was all in Python.


Brent Vatne

Brent is Front-end web/mobile developer working on Exponent and React Native. He contributes to tons of open-source projects.

Q: I really want to become a better developer; what would you say the first step is?

A: Do stuff you’re excited about and contribute to open source projects:-D

Q: How old are you and how much experience do you have as a programmer?

A: I am 30 years old, and very much 😮

Q: How did you join Exponent? What was the cause?

A: James (ide) and I were the most active contributors to a react-native outside of facebook and so we spoke a lot. He created exponent with Charlie. I ended up doing some consulting work with them and Charlie asked if I’d be interested in working with them full time and year, it was lots of fun so I joined.

Q: I should know objective C and Java thoroughly before I jump into React Native, right?

A: You can learn it as you go if you need to. there’s also tons of pure javascript stuff that need to be done. and documentation. lots of things 🙂


Charlie Cheever

Charlie Cheever is the co-founder of Quora, an online knowledge market. He was formerly an engineer and manager at Facebook, where he oversaw the creation of Facebook Connect and the Facebook Platform. Prior to Facebook, Cheever was employed by Amazon.com in Seattle. He left Facebook to start Quora in June 2009 to work on Exponent.

Q: What’s the motivation of Exponent being free and Open Source?

A: I really want to make something that like a 12-year-old version of me would use. So, someone who doesn’t know tons about programming but can learn new things and doesn’t have a credit card or lots of money, but has time and creativity and a phone and friends. I learned to program making calculator games on TI-85, it’s sad to me that kids can’t make stuff on their phones today.

Q: Why did you leave Quora?

A: I managed the mobile teams there and it was so slow to work on those apps even tho we had good people, I found it so frustrating And after I left I tried to build some mobile stuff and it was so annoying that I decided there needed to be a different way to make stuff. So James and I made something like react Native called Ion. It was strikingly similar actually. But React Native already had android support and 20 people working on it, and we had 2 people. So we decided to make everything else around it that we wanted to make!

Q: What did you do on Facebook?

A: I made the developer platform that all those games like FarmVille were on. Well, not all of it obviously but was one of two main developers. And I worked on the first version of facebook video, then did a lot of random other things. Then was a manager and did log in with Facebook on other sites, and then left to do Quora.

How to monetize your programming skills


Christopher Chedeau

Christopher has been working at Facebook as a Front-end Engineer for about 5 years. Previously, he worked at Curse Network.

Q: What do you do on Facebook?

A: I was on the photos team when I started, then I discovered React and started adopting and promoting it both internally and externally. I was there at the beginning of reacting native and pushed it through until 3 months ago. I just recently switched to the Nuclide team. I’m still #3 contributor on React Native.😛

Q: Do you have any prior work experience?

A: I was working for Curse (doing website for blizzard games) during my college to pay for it. It was fun to see the company go from 5 people in a guild to a 100 people company.

Q: What’s your day to day like on Facebook? The current project you’re working on?

A: I’m currently working on the Nuclide team, Facebook’s IDE built on top of Atom. I would say my time is spent half coding, half cheerleading all the cool stuff people are doing inside of FB.

Q: How do you think one can become a better developer?

A: I think that there are multiple levels.

The first level is mastering all the concepts. For example yesterday I had to write a function that removes certain keys from a big nested object. Because I’ve done this task so many times in the past, I was able to implement it in one go without even thinking and it worked the first time. For this one, exercises are really good. You want to code the same kind of things many many times to train your muscle memory.

The second level is how do you build things in a way that are not going to break in the future. Ideally, once you build something, you can move to the next thing and it’ll keep working without you there. This is challenging when there’s a ton of developers touching the codebase and product directions changing often.

Finally, the third level is how do you prevent a whole class of problems from even existing in the first place. A good example is with manual dom mutations, it’s very easy to trigger some code that interacts with a dom node that has been removed from the dom. React came in and made this problem go away. You have to go out of your way to do so, and even if you want to do those things, you have the tools to make it work: lifecycle events.

Q: Is there something you wish you’d known or learned earlier as a programmer?

A: Probably the most important thing is: tradeoffs, tradeoffs, tradeoffs. They are everywhere.

If you are working on some random throwaway feature that no one is going to use, who cares if the code is maintainable, you need it to work and now one mistake I see a lot is that people over-engineer the easy things but are not willing to make their architecture less clean from a CS perspective even though it actually provides the user experience you need.

At the end of the day, we write all this code for the users, we should first understand what the user experience should be and then do whatever it takes to get it. If the user just needs to display some content and needs to be able to edit it easily, just install WordPress, pick a good looking theme and call it a day

– Btw, pro-tip, if you want to be successful, always think about the value you are providing. If you are earning $100k a year, this means that the company should be making $200k because you’re here


Dan Horrigan

Dan is a Senior Back-end developer @Futuri Media. He has 20 years of programming experience in many different languages. He’s been contributing to React Native early/mid-2015.

Q: What’s your background as a programmer?

A: I started learning to program (with QBasic) when I was 11 and was hooked. I learned everything I could, as fast as I could. I learned a few languages like Visual Basic and started to dabble with C and C++. Then I found web development and dove in head first. First, learning HTML and CSS, then adding simple CGI scripts written in Perl, and eventually Classic ASP.

My first paying project was when I was 14: A website for the company my dad worked for, with a customer portal to let them see their job progress. This was all in ASP. After that, I started learning PHP, and have been using that as my language of choice ever since. However, I picked up a lot of experience with other languages along the way: JS, Python, Ruby (on Rails), Java, C#, Go, Objective-C.

Q: What are some projects you’re currently working on?

A: I work for Future Media (http://futurimedia.com). We provide SaaS solutions for Broadcast Radio and TV companies. We provide white label mobile applications, social engagement and discovery, audio streaming and podcast solutions, etc. I haven’t had much free time lately to contribute to many OSS projects, but hope to change that soon!

Currently, I am a Senior Back-End Web Developer, but I am transitioning into being the Director of Technical Operations.

Q: Is there something you wish you’d learned or knew earlier as a developer?

A: I wished I would have realized earlier in my career that it is OK to be wrong, and that failure is just a chance to learn.

Q: What’s the first step to becoming a good developer?

A: Come up with a small-ish project that you think would be cool, or would make your life easier, and just jump right in. Too many people try to learn without a goal other than “I want to learn to code.” Without a goal, you are just reading docs or copy/pasting from tutorials…you can’t learn that way.

To become a better developer, you need to do one simple thing: Never. Stop. Learning. Read other people’s code, figure out how that one app does that really cool thing you saw, read blogs, etc. No matter how good you are, or think you are, there is always someone better, and always more to learn.

Q: Is there a certain project you’re currently interested in? Next on your learning list?

A: I have been using, and occasionally contributing to, React Native since early/mid-2015, and continue to be interested in it.

Next, on my learning list is learning Erlang/Elixir. We build heavily distributed systems where I work and think we would really benefit from a language like that.


Frank W. Zammetti

Frank is a lead architect for BNY Mellon by day and the author of eight books on various programming topics for Apress by night

Q: How do I become a better developer?

A: I get asked this question quite a bit both at work from junior developers and from readers of my books. I always give the same answer: make games!

It sounds like a joke answer, but it most definitely is not! Games have a unique ability to touch on so many software engineering topics that you can’t help but learn things from the experience. Whether it’s choosing proper data structures and algorithms, or writing optimized code (without getting lost in micro-optimizations – at least too soon), or various forms of AI, it’s all stuff that is more broadly applicable outside of games. You frequently deal with network coding, obviously audio and visual coding (which tends to open your mind to mathematical concepts you otherwise might not be), efficient I/O and of course overall architecture, which has to be clean and efficient in games (and for many games, extensible). All those topics and more are things that come into play (hehe) when making games.

It also teaches you debugging and defensive programming techniques extremely well because one thing people don’t accept in games is errors. It’s kind of ironic actually: people will deal with some degree of imperfection in their banking website but show a single glitch in a game and they hate it! You have no choice but to write solid code in a game and you figure out what works and what doesn’t, how to recover from unexpected conditions, how to spot edge cases, all of that. It all comes into play and those are skills that developers need generally and which I find are most frequently lacking in many developers.

It doesn’t matter one bit if the game you produce is any good, or whether anyone else ever even plays it. It doesn’t matter if it’s web-based (even if your day job is), or mobile, doesn’t matter what technologies you use. The type of insight and problem-solving skills you build and tune when creating games will serve you well no matter what your day job is, even in ways that are far from obvious.

I’ve been programming games for the better part of 35 years now. No, none of them have been best-sellers or won awards or anything like that. In fact, it’s a safe bet that most people wouldn’t have even heard of my games, even the one’s still available today. None of that matters because the experience of building them is far and away the most rewarding part of it. Perhaps the best thing about programming games is that they are, by their nature, fun! You’re creating something that’s intended to be enjoyable so the process of creating it should absolutely be just as enjoyable. How many things can you do that are really fun while still being challenging and simultaneously help build the skills needed for a long career?

So yeah, make games, that’s my simple two-word answer!

Q: Is there something you wish you’d known or learned earlier as a programmer?

A: Hmm, tough question actually. I guess if there was one thing (and I’ll cheat and combine two things here because they’re related) I would say that early on I didn’t understand two very important phrases: “As simple as possible, but no simpler” and “Don’t let the perfect be the enemy of the good”.

I have a natural perfectionist mentality, so I spend a lot of time pondering architecture, API design, etc. I once spent 33 hours straight working on a Commodore 64 demo because ONE lousy pixel was out of place and my perfectionist brain just couldn’t live with it! Sometimes, I have to force myself to say “okay, it’s good enough, you’ve planned enough, now get to work and actually BUILD stuff and refactor it later if needed”, or I have to force myself to say “okay, it basically does what it’s supposed to, it doesn’t need to be absolutely flawless because nobody but me is even going to notice”. Especially when you’ve got deadlines and people relying on you, you have to make sure you’re working towards concrete goals and not constantly getting stuck trying to achieve perfection because you rarely are going to, at least initially anyway, no matter how hard you plan or try – and the dirty little secret in IT is that perfection rarely matters anyway! Good enough is frequently, err, good enough 🙂

And, your design/development approach should always strive to be as absolutely simple as possible. Of course, what constitutes “simple” is debatable and doesn’t necessarily even always have the same meaning from project to project, but for me some key metrics are how many dependencies I have (web development today is a NIGHTMARE in this regard – less is GENERALLY better) and how many layers of abstraction there are. Developers, especially in the Java world, like to abstract everything and they do so under the assumption that it’s more flexible. But if there’s one thing I’ve learned over the years it’s that the way to write flexible code is to write simple code. It’s better than abstractions and extension points and that sort of stuff because it’s just far easier to understand the consequences of your changes.

As a corollary, a terse code is NOT simpler code! Simple code is code that anyone can quickly understand, even less capable developers, and even yourself years after. Terse and “clever” code tends to be the exact opposite. Often times, the more verbose code is actually simpler because there are fewer assumptions and often less knowledge needed to understand it, less “code hoping” you have to do to follow things. Related to this is that writing less code isn’t AUTOMATICALLY better. No, you shouldn’t re-invent the wheel, but you also shouldn’t be AFRAID to invent a marginally better the wheel when it makes sense. Knowing the difference is hard of course and comes from experience, but if you think it’s ALWAYS better to write less code then you’re going to make your life harder in the long run.

Of course, don’t over-simplify code either. Too simple and suddenly extending it almost MUST mean a refactor. You never want to completely refactor because you HAVE to in order to build an app over time. There’s a balance that’s difficult to strike but it should always be the goal.

Oh yeah, and I wish I knew how to express myself in fewer words… but actually, I’m still obviously working on that one 🙂


Janic Duplessis

Janic is the co-founder of App & Flow, a react-native contributor, and open-source contributor.

Q: Any tips to becoming a better developer?

A: Don’t think there’s anything in particular, you just have keep learning and getting out of your comfort zone. Like trying a new language or framework from time to time. At least that’s what I do but I’m pretty sure there are some other good ways haha 🙂

Q: How can I start contributing to React Native?

A: The best is to start with something small like a bug fix or adding a small feature like an extra prop on a component. Most contributors know either iOS or Android and a bit of JS. There are also some JS devs that work on things like the package and clip. We keep some issues with a Good First Task label that should be a good place to start


Jake Murzy

Jake is an Open-source Archaeologist. He writes buzzword compliant code. Co-founder at @commitocracy.

Q: Hey Jake, any tips to becoming a better programmer? 🙂

A: Number one thing you should do is to learn your tools before you learn the language you work in because it will lead to faster feedback loops and you will get to experience more in less time. So install a linter and it will catch most of your errors as you type. It statically analyzes your code and recommends best practices to follow. You should always follow best practices until you gain enough experience to start questioning them.


Jun Ho Hwang

Jun is a software engineer at Coupang, which is the $5 Billion Startup Filling Amazon’s Void In South Korea. He is a very friendly developer who loves to connect.

Q: How do you become a better developer?

A: The word ‘better’ can be described in various ways–especially in the field of programming. A good developer could be someone who is exceptionally talented in development, someone who is amazing at communicating, or someone who understands Business very well. I personally think a “good” developer is someone who is in the middle–a person who can solve his or her business problem with their development skills, and communicate with others about the issue. Ultimately, to achieve this, it requires a lot of practice, and I recommend you to create your own service. Looking and thinking from the perspective of the user and improving the service to fulfill their needs really helps you grow as a better developer.

Q: Is there something you wish you’d known or learned earlier as a developer?

A: I really wish I started my own service earlier on. The hardest thing to grasp before developing is realizing how you can apply what you learned. Many developers are afraid to start a “service” because it sounds difficult; however, pondering about what to make and where to start, and then connecting those points of thought help you grow as a better developer.

Q: What do you do at Coupang? What are you currently working on?

A: Coupling provides a rocket-delivery-service, and I am working on developing a system called “Coupling Car,” which is related to insurance and monetary management. Furthermore, I’m thinking about adding transportation control system and the ability to analyze data from the log.


Keon Kim

Keon is a student at NYU who is really passionate about Machine Learning. He is a very active GitHub member who tries to contribute to open source projects related to machine learning.

Q: What are your interests? What kind of projects have you worked on?

A: I’ve been working on machine learning projects these days. I am one of the project members of DeepCoding Project, a project with a goal of translating written English to the source code. I’ve been contributing to a C++ machine learning framework called my pack(https://github.com/mlpack/mlpack), which is equivalent to skit-learn in Python.

I’ve also done some fun side projects: DeepStock (https://github.com/keonkim/deepstock) project is an attempt to predict the stock market trends by analyzing daily news headlines. CodeGAN (https://github.com/keonkim/CodeGAN) is a source code generator that uses one of the new deep learning methods called SeqGAN.

Q: How do you become a better developer?

A: I think it is really important to understand the basics. By basics, I mean math, data structures, and algorithms. Deep learning is really hot right now, and I see people jumping into learning it without basic knowledge in computer science and mathematics. And of course, most of them give up as soon as mathematical notations appear in the tutorial. I know this because I was one of them and it took me really long time to understand some concepts that students with a strong fundamentals could understand in a fraction of the time I spent. New languages, libraries, and frameworks are introduced literally every day these days, and you need the fundamentals in order to keep up with them.


Munseok Oh

Munseok is a Full-stack developer and CTO at Sketchware. He previously worked at System Integration for ~7 years.

Q: How do I become a better developer?

A: When I was very young and cocky, I evaluated other developers based on their coding style. There were certain criteria they had to pass in order for me to judge them as a good developer. But now, I really don’t think that way. Now, I believe that every developer is progressive, which means he or she is becoming a better developer every day. It doesn’t really matter if the style is bad or code is good–as long as the program runs, I think it’s great! Whether the program has room for growth or has bugs, I think the motivation to develop is what really matters. Developers usually are never satisfied with their skills. They are always eager to become better–probably why you’re doing this. It’s really hard to justify “good developer”. People like you will become better than me in no time. I still don’t think I am a good developer.

Q: What was the most difficult thing when you were developing Sketchware?

A: Developing Sketchware wasn’t too difficult because we had a good blueprint for the item. The direction was very clear for us to follow, so developing it was a breeze. However, there was a line we had to maintain for Sketchware–this line had two conditions:

  1. Sketchware must be an easy tool for anyone to create applications.
  2. Whatever the user takes away from Sketchware can be applied in their future career

Since we wanted Sketchware to be an efficient tool that can help users learn programming concepts, I am very considerate and think a lot when it comes to adding new features in the application.

Q: As a developer, is there something you wish you knew or fixed earlier?

A: I really wish I jumped into the Start-up world earlier. When it comes to developing, you need to be passionate and really enjoy what you do. Even if you pull 3 all-nighters, ponder all day long about a new algorithm, or stress about a new bug, everything will be okay if you’re enjoying it. It really goes back to the question #1–I get my energy from the joy I have when I develop, and that joy eventually makes you a better developer. When life hits you, most developers lose the passion for developing if you think of it as work. I used to be like that. But now, I’m really not worried–since developing brings joy to me now. Even if we run out of funds or our company burns down, it’s really okay since I am making the most out of what I am doing.


Satyajit Sahoo

Satyajit is the UX Lead at Glucosio, and Front-end Engineer at Callstack.io. He is an amazing open-source contributor; he is one of the top 5 contributors in React Native

Q: What is your background as a programmer?

A: I don’t really come from a programming background. I did my graduation in Forestry. I left post-graduation after getting a job offer and never looked back.

Q: What’s your day like on day to day basis?

A: It’s pretty boring. I wake up, order some breakfast online or go out, then start office work. In evening I go out to a bar or take a long walk if there’s enough time left. At night I mostly watch TV series or hack on side-projects.

Q: Motivation behind contributing to open source projects?

A: I’ve been involved in Open Source for a long time. When I was doing my graduation I got into Linux and got introduced to the world of Open Source. I loved it how we could learn so much from other projects. It fascinated me that developers were selfless to let us see and use the there code for free (mostly). I did a lot of Open Source projects in form of themes and apps during my college days, and it always made me happy when people forked them and changed to meet their needs, and send pull requests to fix things.

As a developer, I contribute to Open Source projects most of the time because I need a feature, or it improves something on a project I love. I think it’s better if we work together to fix stuff that is important to us rather than just filing issues.

Q: How do I become a better developer?

A: I think it’s important that we are open to new things. There’s a lot to learn, and we cannot learn if we stay in our bubble. Try new things, even if you think you can’t do it, even it looks complex on the surface. I have failed to do things so many times, but eventually succeed. In the process, I understand the problem and the solution, and then it becomes really simple.


Sonny Lazuardi Hermawan

Sonny is a JavaScript Full Stack Engineer, a React & React Native player, and an Open source enthusiast. He currently works as an Engineer at Sale Stock.

Q: How do you become a better developer?

A: I think always eager to learn is the key. Try everything, make mistakes, and learn from that mistakes. I agree that code review from partners and senior engineers will make our code better. Try publishing your own open source projects, meet other great developers and learn from them.

Q: What’s your motivation behind creating open source projects?

A: I just want the people to know about our idea, and try implementing it so that others can use our project. I’m really inspired by people that work on open source projects that used by many devs such as Dan Abramov that created redux.


Sunggu Hwang

Sunggu worked at Daum Communications for 4 years. Then, he left Daum to work at Scatter Lab as the CTO. This is his 5th year at Scatter Lab.

Q: How do you become a better developer?

A: Hmm… Becoming a good developer… Every developer has his or her own personality when it comes to programming. As an analogy, think about blacksmiths! Not all blacksmiths are alike–some enjoy crafting the best sword, while some might enjoy testing out the sword more than crafting it. I am a thinker–who plans and organizes thoughts before I carry out an action. I think a good developer knows how to write concise and clean code; you should practice this habit. Even though the trend for programming is always changing, and many people use different languages, write a piece of code that anyone can understand without comments.

Q: What do you think is the next BIG thing?

A: I’ve observed the evolution of programming languages, and I think it’s becoming more abstract every generation–procedural programming, imperative programming, functional programming… I think in the future, maybe in about 20 to 30 years, we will live in the time where the computer writes the code for us, and we just put them together like legos.

Q: What should I focus on studying?

A: I think deep learning is a must. Try different tutorials and learn it with passion. Math, algorithms–anything will help you in the long run.


Timothy Ko

Timothy is a software engineer at Snapchat. He previously worked at many places such as Riot Games, Square, etc.

Q: What do you do at Snapchat?

A: I’m a software engineer on the monetization team, so I work on anything related to making money. Some example projects are Snapchat Discover, a news platform within the iOS and Android apps; Ad Manager, a control panel used by sales and ad operations to flight ads; Ads API, which allows third-party partners to integrate their own ad platforms into Snapchat. Also, I was a past intern at Snapchat so I occasionally give talks and Q&As to upcoming interns. I’m also heavily invested in hiring and conduct a lot of interviews there.

Q: What do you do on a day-to-day basis?

A: What I’ve mentioned previously. Also, even after I pass on the work to other people, sometimes I have to go back and help support it or be part of the technical discussions on future changes. When new people join the team, usually I’m the one to ramp people up on how the code base looks like the kinds of frameworks we use, how a typical engineer workflow looks like, etc.

Q: What languages/framework do you guys mostly use?

A: For server code, it’s usually Java and for UI we use React Redux. Most teams work in google app engine, which is why we use Java, but some teams switch it up a little bit due to some app engine limitations. And of course, the product teams work in objective C for iOS and Java for Android.

Q: How do you think I can become a better developer?

A: I think the best thing to do is to do as many things as possible. I did seven internships while in school so I already had two years of work experience before I graduated. Work experience is super important because coding in a hackathon, doing personal projects, and doing school assignments are totally different than working with enterprise software and apps with real users. But you have to start somewhere, so that’s where going to school, doing personal projects, and competing in hackathons comes in. And while at work, I think the best way to succeed is to ask lots of questions and learn by doing. You can read and study all you want, but you might not understand what’s going on until you actually do it. Another thing is code reviews — you can do so much knowledge transfer by having a more senior engineer tear your code apart and tell you how to make it better. Also, if you ever come up with a proposal on how to solve a problem, getting a tech lead to bombard you with hard questions forces you to make sure you have every little detail covered.


*The article was originally posted by Sung Park on Github*

Subscribe to The HackerEarth Blog

Get expert tips, hacks, and how-tos from the world of tech recruiting to stay on top of your hiring!

Author
Rohit C P
Calendar Icon
January 3, 2017
Timer Icon
3 min read
Share

Hire top tech talent with our recruitment platform

Access Free Demo
Related reads

Discover more articles

Gain insights to optimize your developer recruitment process.

AI Interview Tools: Keep Humans Where They Matter

How to use AI interview tools without losing human judgment

Automate the parts of screening that humans do badly anyway — consistency, scheduling, identity verification, and rubric application — and protect the parts humans still do better: context, judgment, and read-the-room calls. That is the practical division behind every AI hiring rollout worth running.

If you're a recruiter or hiring manager evaluating AI interview tools — software that conducts, scores, or supports structured candidate interviews using machine learning — the question is rarely whether to adopt them. It's where to draw the line. The mistake we see most often is binary thinking. Teams either bolt an AI interviewer onto the top of their funnel and call it done, or they refuse to use AI-assisted screening at all because "hiring is human." Both positions miss the point.

This guide explains where AI interview tools create value, where human involvement remains essential, and how hiring teams can implement automated interviewing without sacrificing hiring quality.

What are AI interview tools?

AI interview tools are platforms that automate specific parts of the hiring process. Depending on the use case, they can:

  • Conduct structured interviews
  • Ask standardized questions
  • Score responses against predefined rubrics
  • Verify candidate identity
  • Detect suspicious assessment behavior
  • Schedule interviews automatically

Note: some vendors in the broader market also offer note-taking, transcription, and post-interview summary features under the label "AI interview assistants." These are general market capabilities and are not part of every platform, including HackerEarth's. Buyers should verify which features any specific product supports.

What these tools share is the ability to introduce consistency into hiring processes that are often highly variable.

Types of AI interview tools and where each fits

Organizations typically use AI interview tools in several ways. AI screening interviews are used for early-stage candidate evaluation and high-volume hiring — for example, screening 500+ applicants for entry-level software engineering or customer support roles before committing recruiter time. AI technical interviews evaluate technical skills using structured coding exercises and predefined scoring criteria, common for mid-level engineering hiring at companies like Atlassian, Stripe, or similar volume technical employers. AI proctoring tools focus on fraud prevention and identity verification during remote assessments — increasingly important as remote-first hiring becomes standard. AI candidate evaluation platforms help recruiters compare, rank, and shortlist candidates based on structured frameworks, typically integrated into an ATS like Greenhouse or Workday.

Most hiring teams use a combination of these rather than relying on a single solution. HackerEarth's technical assessments and OnScreen interview platform cover screening, technical evaluation, and proctoring in one workflow.

Why AI hiring tools matter for recruiters today

The biggest challenge in hiring is not attracting applicants. It is generating reliable hiring signals.

Human interviewers are naturally inconsistent. Different interviewers ask different questions, evaluate candidates differently, and often rely on intuition rather than structured evidence. For a recruiter managing 40+ open requisitions, that variability means two equally qualified candidates can receive opposite recommendations depending on who interviewed them.

A working paper from the National Bureau of Economic Research by Bo Cowgill (Columbia Business School, 2018), "Bias and Productivity in Humans and Algorithms," analyzed over 300,000 hiring decisions and found that managers who overrode algorithmic resume-screening recommendations frequently produced worse downstream hires than the algorithms themselves. The relevance to a recruiter's daily workflow: when hiring managers reject candidates that structured screening surfaces, the override is often the source of the noise — not the algorithm.

Similarly, research in Noise: A Flaw in Human Judgment by Daniel Kahneman, Olivier Sibony, and Cass Sunstein (Little, Brown Spark, 2021) documents that unstructured interviews produce inconsistent candidate evaluations across interviewers evaluating the same candidate (see Chapter 24, "Structure in Hiring"). AI interview tools address this by enforcing structure on the parts of screening where structure works.

Step 1: Identify which hiring activities benefit from automation

Not every hiring activity should be automated. The first step is identifying which parts of hiring are operational and which require judgment.

Activities that work well with AI

AI interview tools perform best when evaluation criteria are structured and repeatable. These include initial technical screening, structured behavioral interviews, identity verification, coding assessment proctoring, interview scheduling, first-pass rubric scoring, and candidate ranking against predefined criteria.

The value comes from consistency. Every candidate receives the same experience and is evaluated using the same standards.

Activities that should remain human-led

Some hiring decisions depend heavily on context. These include team-fit conversations, senior leadership hiring, system design discussions, judgment-based evaluations, borderline candidate reviews, offer negotiations, and final hiring decisions.

These areas require interpretation, nuance, and organizational understanding that AI systems cannot reliably replicate.

Step 2: Understand where AI interview tools fail

The biggest risks emerge when organizations automate decisions that should remain human.

Cultural and team-fit assessment

Successful collaboration depends on interpersonal dynamics. An AI system cannot determine whether a candidate will thrive within a particular team environment or work effectively alongside future colleagues.

Senior and staff-level evaluation

At senior levels, the most important signals involve judgment under ambiguity. Organizations hire staff engineers and leaders for decisions that do not fit predefined rubrics. AI interview tools are optimized for structure, while senior hiring often depends on evaluating how candidates operate without it.

Edge-case context

Strong candidates do not always provide conventional answers. Experienced interviewers can recognize when a candidate has approached a problem differently but correctly. AI systems often struggle to distinguish between incorrect answers and unconventional thinking.

Legally consequential decisions

Hiring regulations increasingly require transparency and oversight for AI-assisted hiring. Examples include:

  • New York City Local Law 144 — requires employers using automated employment decision tools to conduct an annual independent bias audit, publish a summary of results, and notify candidates at least 10 business days before use.
  • The EU AI Act — classifies AI systems used for recruitment and candidate screening as "high-risk," requiring providers and deployers to meet obligations including risk management, data governance, transparency to candidates, human oversight, and conformity assessment before deployment.
  • Emerging AI governance frameworks in Illinois (AI Video Interview Act), Maryland, and Colorado.

Any AI-assisted hiring process should include documented human oversight and auditability. Read more in our hiring compliance overview.

Step 3: Create a practical division of labor

Step 1 covered the what — which activities suit AI versus humans. This step covers the how — building that split into a workflow your team can run on Monday morning.

Set explicit thresholds. For example: candidates scoring above the 70th percentile on a structured technical assessment advance to a human technical interview; candidates between the 50th and 70th percentile receive recruiter review before any rejection; candidates below the 50th percentile are auto-rejected only after a bias audit confirms the rubric is not screening out protected groups disproportionately. Sample rubric weights for a mid-level backend role might look like: code correctness 40%, code quality 25%, problem decomposition 20%, communication 15%.

Track completion rate as a leading indicator. Industry benchmarks for asynchronous AI interviews typically fall between 60–75% completion; if yours drops below 60%, candidate experience or instructions need work before you scale.

Guiding principle: AI should expand and standardize the funnel. Humans should make the decisions that close it.

An AI tool that lets a marginal candidate (say, a 65th-percentile score) reach a human interview costs a small amount of interviewer time. An AI tool that rejects a strong candidate creates a missed hire that may never be recovered.

Step 4: Calibrate AI against historical hiring data

Many organizations deploy AI interview tools without validating whether the system would have identified successful employees from the past.

Before implementation:

  • Run historical candidates through the AI evaluation process.
  • Compare AI recommendations against actual hiring outcomes.
  • Analyze discrepancies.
  • Refine scoring rubrics before launch.

If the AI system would have rejected several successful hires, the problem is usually the rubric, not the candidates.

Step 5: Keep humans in the loop

The best AI hiring programs maintain human oversight throughout the process.

Review borderline rejections

Candidates within 5–10 percentile points of the cutoff should receive human review. A short recruiter review can prevent high-potential candidates from being filtered out unnecessarily.

Monitor rubric drift

Hiring requirements evolve over time. Human oversight helps identify when AI evaluation systems begin drifting away from actual indicators of hiring success — for example, if 12-month retention among AI-recommended hires drops below the retention rate of human-screened hires, the rubric needs recalibration.

Maintain escalation paths

Candidates should always have a path to human interaction when needed. Transparency improves candidate experience and strengthens trust in the hiring process.

Step 6: Measure outcomes instead of activity

Many organizations focus on operational metrics such as interviews completed, candidates screened, and time saved. These metrics do not measure hiring quality.

Measure what matters

  • 12-month retention — tracks whether employees remain with the company and succeed over time.
  • Performance reviews — measures whether hires deliver expected business impact.
  • Hiring manager satisfaction — provides direct feedback on candidate quality.
  • Time-to-hire — measures hiring efficiency without sacrificing quality.
  • Candidate completion rates — help identify friction points and candidate experience issues.

Track these against pre-AI baselines so you can identify whether AI-assisted screening is contributing to better hires or just faster ones.

Step 7: Manage candidate experience carefully

Candidate reactions to AI interviews vary significantly.

What candidates often like

  • Flexible scheduling
  • Faster response times
  • On-demand interview completion
  • Reduced scheduling friction

Common concerns

  • Lack of human interaction
  • Difficulty building rapport
  • Concerns about fairness
  • Uncertainty about how responses are evaluated

Organizations should clearly communicate how AI is being used, what is being evaluated, how decisions are made, and when humans are involved. Transparency is increasingly both an operational norm and a regulatory expectation.

Common mistakes when implementing AI interview tools

Most implementation failures follow predictable patterns:

  • Replacing humans too early in the hiring process
  • Using AI as the sole basis for rejection decisions
  • Failing to validate scoring rubrics
  • Measuring efficiency instead of hiring quality
  • Ignoring candidate experience metrics
  • Neglecting bias audits and compliance reviews

Organizations that avoid these mistakes typically achieve stronger hiring outcomes and higher candidate trust.

Where HackerEarth OnScreen fits

The compliance, calibration, and human-in-the-loop requirements above raise an operational question: which platform actually combines structured AI screening with the proctoring and identity verification that bias audits and remote hiring require? HackerEarth OnScreen combines in-depth interviewing, integrated proctoring, and KYC-grade identity verification — a combination no single product has previously offered in this category. The AI handles the structured-screening layer (rubric-based scoring against role-specific criteria your team defines, identity verification, and proctoring signal) so human interviewers focus their time on the later-stage judgment calls Step 1 identified as off-limits to automation.

Frequently asked questions

Are AI interview tools more biased than human interviewers?

AI interview tools apply evaluation criteria more consistently than human interviewers, but they can encode bias if trained on biased historical data. Annual bias audits, as required by NYC Local Law 144, and ongoing human review of borderline rejections are how organizations keep that risk in check.

When should organizations avoid AI interviews?

Organizations should avoid AI interviews for executive search, C-suite hiring, highly specialized roles where the rubric cannot be defined in advance, and any interview stage where judgment under ambiguity is the primary signal being measured.

How can organizations determine whether an AI interview tool is successful?

The clearest measure of success is whether AI-screened hires retain and perform at least as well as human-screened hires over 12 months. Pair that with hiring manager satisfaction surveys and completion-rate benchmarks to get a full picture.

Do candidates dislike AI interviews?

Candidate reaction depends on transparency and optionality. Some candidates appreciate flexibility and convenience, while others prefer human interaction; offering an opt-in human touchpoint and clearly explaining how the AI evaluation works closes most of the experience gap.

What compliance considerations apply to AI interview tools?

Organizations using AI interview tools must maintain bias audit documentation, candidate disclosures, audit trails, and documented human oversight to meet regulations including NYC Local Law 144, the EU AI Act, and Illinois's AI Video Interview Act.

Key takeaways

  • The Cowgill (NBER, 2018) finding — that human overrides of algorithmic screening produced worse hires across 300,000 decisions — is the single strongest argument for keeping AI in the early funnel and humans in the late funnel.
  • NYC Local Law 144 requires an annual independent bias audit and 10-business-day candidate notification; the EU AI Act classifies hiring AI as high-risk and requires human oversight by law.
  • Calibrate AI tools by running 12–24 months of historical hires through the system before launch; if it would have rejected your top performers, fix the rubric.
  • Set percentile-based escalation thresholds (e.g., review every candidate within 5–10 points of the cutoff) so borderline cases always reach human eyes.
  • Measure 12-month retention and hiring manager satisfaction against pre-AI baselines — not interviews completed.
Human Overrides vs. Algorithm: Hire Quality Outcomes
Source: Cowgill, NBER Working Paper No. 21709, 2018 (downstream hire quality index, illustrative scale based on article claims)

See it in action

Schedule a demo of HackerEarth OnScreen to map which stages of your current hiring workflow can move to AI screening, which must stay human-led, and how to set percentile thresholds and bias audits aligned with NYC Local Law 144 and the EU AI Act before you scale.

When AI Interviews Work and When They Don't: An Honest Breakdown by Role Type and Seniority

When AI Interviews Work and When They Don't: An Honest Breakdown by Role Type and Seniority

AI interviews work well for structured, rubric-driven screening of high-volume and mid-skill technical roles. They fail predictably when evaluation depends on judgment, context, collaboration, or organizational fit.

The honest answer to "when AI interviews work and when they don't" is simple: AI follows the rubric. If the rubric captures what matters for the role, AI interviews generate useful signal. If the role depends on context, judgment, or nuanced decision-making, AI interviews miss what matters most.

This guide is for recruiters, hiring managers, and talent acquisition leaders evaluating where AI interviews belong in the hiring process. It covers what AI interviews are, where they work best, where they fall short, how effectiveness changes by seniority level, and how to integrate them into a modern hiring workflow.

What Is an AI Interview?

An AI interview is a structured screening process conducted through software that asks standardized questions, evaluates responses against predefined criteria, and produces a consistent candidate assessment.

Most AI interview platforms include:

  • Automated questioning
  • Structured scoring rubrics
  • Video or voice interactions
  • Identity verification
  • Proctoring and integrity checks
  • Candidate ranking and reporting

The defining characteristic of AI interviews is consistency.

Unlike human interviewers, who may evaluate candidates differently depending on experience, fatigue, or bias, AI applies the same evaluation framework to every candidate.

The trade-off is straightforward:

  • Greater consistency
  • Less contextual judgment

AI interviews are not bias-free. Like any evaluation system, outcomes depend on training data, scoring logic, and rubric design. The goal is not eliminating bias entirely but reducing variability and improving consistency.

When AI Interviews Work

High-Volume Technical Screening

This is the strongest use case for AI interviews.

When organizations need to evaluate hundreds or thousands of candidates, consistency becomes more important than depth.

AI interviews can apply identical evaluation criteria across large applicant pools while significantly reducing recruiter workload.

Organizations conducting large-scale engineering recruitment often use AI interviews to maintain calibration across thousands of applications.

Campus and Early-Career Hiring

Campus hiring creates ideal conditions for AI screening:

  • Large candidate volumes
  • Clearly defined skill requirements
  • Standardized evaluation criteria
  • Structured hiring workflows

For organizations hiring hundreds or thousands of graduates annually, human-only screening is often impractical.

Mid-Level Individual Contributor Roles

AI interviews perform well for roles where expectations are well understood and measurable.

Examples include:

  • Backend Engineers
  • Frontend Developers
  • Data Analysts
  • QA Engineers
  • DevOps Engineers

For these positions, structured evaluation often produces reliable screening outcomes before human interviews begin.

Hiring Pipelines Impacted by Scheduling Delays

Interview scheduling remains one of the biggest causes of candidate drop-off.

AI interviews allow candidates to complete screening immediately rather than waiting days for recruiter availability.

For global hiring teams operating across multiple time zones, reduced scheduling friction can significantly improve candidate experience and pipeline speed.

When AI Interviews Don't Work

Senior and Staff-Level Engineering Roles

At senior levels, technical competence is only part of the evaluation.

Organizations need to assess:

  • Decision-making under uncertainty
  • System design trade-offs
  • Stakeholder management
  • Technical leadership
  • Long-term architectural thinking

These capabilities are difficult to evaluate through a fixed rubric.

AI interviews can validate technical fundamentals but should not replace senior-level technical discussions.

Leadership and Executive Hiring

Leadership hiring depends heavily on:

  • Strategic thinking
  • Organizational fit
  • Vision
  • Influence
  • Team-building ability

These qualities are highly contextual and difficult to standardize.

AI interviews should generally not serve as a primary evaluation mechanism for director, VP, or executive roles.

Culture-Driven Hiring

Some hiring decisions are fundamentally conversational.

Examples include:

  • Founding engineers
  • Startup leadership hires
  • Early-stage team members
  • Strategic partnership roles

In these situations, relationship-building and mutual assessment matter more than standardized scoring.

Live Collaboration Assessments

If collaboration is central to the role, collaboration should be part of the interview process.

Examples include:

  • Pair programming
  • Design reviews
  • Team problem-solving sessions
  • Cross-functional workshops

AI interviews can assess baseline competency, but live interaction remains essential.

Highly Contextual Non-Technical Roles

AI interviews struggle when success depends on:

  • Relationship management
  • Negotiation
  • Executive presence
  • Network-building
  • Client judgment

Roles such as enterprise sales, partnerships, executive recruiting, and senior customer success generally benefit more from human-led evaluation.

AI Interview Effectiveness by Seniority Level

The pattern across technical hiring is remarkably consistent.

Entry-Level and Fresher Hiring

AI interviews work extremely well.

Characteristics:

  • High applicant volume
  • Stable evaluation criteria
  • Structured skill requirements

Recommended approach:

AI Interview → Human Validation → Offer

Mid-Level Individual Contributors (L3–L4)

AI interviews work effectively as a first-round screen.

Recommended approach:

Assessment → AI Interview → Human Technical Interview

Senior Individual Contributors (L5)

AI interviews provide useful signal but should not determine hiring outcomes.

Recommended approach:

Assessment → AI Interview → Senior Panel Interview

Staff and Principal Engineers (L6+)

AI interviews offer limited value.

Evaluation should focus on:

  • Architecture
  • Decision-making
  • Leadership
  • Influence

Recommended approach:

Structured Human Panel Interviews

Managers and Directors

Behavioral interviews, leadership evaluations, and reference checks provide stronger signal than AI screening.

VP and Executive Roles

AI interviews are generally not recommended.

What This Means for the Hiring Process

The most common mistake organizations make is treating AI interviews as an all-or-nothing decision.

AI interviews are most effective when positioned as a stage within the hiring funnel rather than a replacement for human evaluation.

For many technical hiring programs, the ideal sequence is:

Skills Assessment → AI Interview → Human Technical Interview → Final Panel

In this model:

  • Assessments validate technical skills
  • AI interviews provide structured screening
  • Human interviews evaluate judgment and collaboration
  • Final panels determine overall fit

This approach combines scalability with human decision-making.

Frequently Asked Questions

Are AI Interviews Fair?

AI interviews generally provide more consistent evaluations than human screeners because every candidate receives the same questions and scoring criteria.

However, fairness depends heavily on:

  • Question design
  • Rubric quality
  • Calibration processes

How Do AI Interviews Handle Candidates Using AI Tools?

Modern platforms combine:

  • Identity verification
  • Proctoring
  • Screen monitoring
  • Dynamic follow-up questions

While no system is perfect, these measures significantly increase assessment integrity.

Can AI Interviews Replace Human Interviewers?

No.

AI interviews can replace or augment first-round screening for many technical roles.

They cannot replace human judgment for senior, leadership, or highly collaborative positions.

What Is the Biggest Risk?

False negatives.

Candidates with unconventional backgrounds or problem-solving approaches may not fit expected scoring patterns despite having strong potential.

Organizations should periodically audit rejected candidates to ensure the screening process remains effective.

How Long Should an AI Interview Be?

For technical screening, 30–45 minutes is typically optimal.

Interviews longer than 60 minutes often increase candidate drop-off without improving signal quality.

When Should Organizations Avoid AI Interviews Entirely?

Avoid AI interviews for:

  • Staff and Principal Engineers
  • Leadership Roles
  • Executive Hiring
  • Culture-Critical Positions
  • Low-volume hiring where personalized evaluation is feasible

Key Takeaways

  • AI interviews perform best for high-volume, structured technical hiring.
  • Campus hiring and mid-level technical roles are ideal use cases.
  • Senior, leadership, and culture-driven roles require human judgment.
  • The practical transition point is typically around the L5 level.
  • AI interviews should complement human decision-making, not replace it.
  • The primary value comes from consistent screening and reduced recruiter workload.

Next Steps

If you're evaluating where AI interviews fit within your hiring process, start by identifying which roles depend primarily on measurable skills and which depend on judgment, collaboration, and leadership.

The strongest hiring funnels combine assessments, AI screening, and human interviews in a sequence that matches the role being hired.

Pre-Employment Coding Tests: Recruiter's Guide 2026

Pre-Employment Coding Tests: Recruiter's Guide 2026

The U.S. Department of Labor estimates a bad hire costs at least 30% of the employee's first-year salary. For a $130,000 senior engineer, that is $39,000 before you account for lost productivity, team disruption, and the weeks spent restarting the search. Most of that risk traces back to a broken screening process: resumes that inflate skills, unstructured interviews that measure confidence over competence, and hiring decisions made on instinct.

Pre-employment coding tests solve this directly. A well-designed pre-employment coding test gives every candidate the same objective problem, evaluates the result against consistent criteria, and produces a defensible, data-backed signal before anyone has spent an hour of interview time.

This guide is for recruiters, hiring managers, and engineering leads building or refining a technical hiring process. It covers what coding tests are, how to choose the right format, how to design assessments that actually predict job performance, how to protect integrity, how to evaluate results fairly, and how to avoid the mistakes that turn a good testing program into a candidate drop-off machine. Note: this is a practical implementation guide focused on screening workflow; it does not exhaustively cover EEOC legal review, accessibility accommodations under the ADA, or multi-region data privacy compliance (GDPR, India DPDP, etc.). Consult qualified counsel for those areas.

What is a pre-employment coding test?

A pre-employment coding test is a standardized assessment given to job candidates before the live interview stage to objectively measure programming skills, problem-solving ability, and code quality. Candidates receive coding challenges on an assessment platform, write code in a real or simulated IDE, and results are scored automatically or reviewed by engineers against consistent criteria.

What every format shares is that it creates a concrete, reproducible record of what a candidate can actually do, rather than what they claim on a resume.

Types of coding tests used in hiring

The five main formats each serve different evaluation goals. Algorithmic coding challenges test data structure and problem-solving fluency under timed conditions. Project-based take-home assignments evaluate real-world code quality, architecture thinking, and documentation. Multiple-choice tests screen foundational language knowledge at high volume. Live coding interviews let interviewers observe how a candidate thinks in real time. Pair programming assessments evaluate collaboration alongside technical ability. Each format is covered in full in Step 2.

When pre-employment coding tests are not the right tool

Pre-employment coding tests are powerful for high-volume technical screening, but they are not universally appropriate. For highly specialized research roles (e.g., applied ML researchers, compiler engineers, cryptography specialists), a standardized challenge rarely captures the depth of the work, and a portfolio review plus deep technical conversation is typically a stronger signal. Internal transfers with documented performance histories generally should not be re-screened with the same assessment used for external candidates. Niche language experts or open-source maintainers with verifiable public portfolios may also be better evaluated on the artifacts they have already shipped. Scoping when not to test is part of designing a defensible hiring process.

Why pre-employment coding tests are critical for technical hiring

The problem is not a shortage of applicants: it is a shortage of reliable signal. Engineering roles take an average of 62 days to fill globally, according to Workable's 2024 benchmarking data, and roughly 70% of tech recruiters say they consistently receive unqualified applicants for every technical role they post, according to industry reporting from DevSkiller. Without a structured pre-hire coding challenge, teams discover skills gaps during live interviews, which is the most expensive point in the funnel to find out a candidate cannot do the job.

The research supports this directly. Schmidt and Hunter's 1998 meta-analysis, and the updated analysis by Schmidt, Oh, and Shaffer (2016), found that work sample tests have a validity coefficient of .33 to .54 for predicting on-the-job performance, substantially higher than education (.10) or years of experience (.18). A coding aptitude test is, by design, a work sample test. According to TestGorilla's 2025 State of Skills-Based Hiring report, roughly 85% of employers now use some form of skills-based hiring, up from 73% in 2023. The question is not whether to use coding tests. It is how to use them effectively.

Predictive Validity of Hiring Selection Methods
Source: Schmidt, Oh & Shaffer (2016); Schmidt & Hunter (1998)

Step 1: Define the role requirements and testable skills

The most common reason a pre-employment coding test fails to predict job performance is that it tests the wrong things, and that is entirely preventable if you start with a job analysis rather than a question library.

Work backward from what the engineer will do in their first 90 days. Identify must-have skills, where a gap disqualifies the candidate regardless of everything else, and distinguish them from nice-to-have skills that can be learned on the job. Map skills to test formats based on what each format can actually measure: algorithm design for backend roles, DOM manipulation for frontend engineers, API integration scenarios for full-stack developers. System design belongs in the live interview, not a pre-employment skills testing stage.

A skills matrix structures this before you build anything:

SkillPriorityTest FormatDifficulty LevelPython data structuresMust-haveAlgorithmic coding challengeMidREST API designMust-haveProject-based taskMid-seniorSQL query optimizationMust-haveCoding challengeMidGit workflowNice-to-haveMCQFoundationalSystem architectureNice-to-haveLive interviewSenior

The matrix forces alignment between engineering and recruiting before the test is built. It is also your first line of legal defense: tests traceable to specific job tasks are far easier to defend under EEOC scrutiny than tests assembled from a generic question bank.

Step 2: How to choose the right type of coding assessment

A pre-employment coding test that works well for junior backend hiring will actively mislead you when evaluating a senior full-stack candidate, and this is one of the most common and preventable process mistakes in technical hiring.

Multiple-choice questions (MCQs)

MCQs are useful as a first-pass filter for high-volume junior pipelines, but answering a multiple-choice question about recursion is not the same as writing a recursive function. Use them to screen out candidates who lack basic fluency before they invest time on a coding problem. Never use them as a standalone technical skills evaluation.

Algorithmic coding challenges

Algorithm tests are the most common format for backend and infrastructure roles, and the most misused. The well-documented limitation is that LeetCode-style challenges favor candidates who have practiced competitive programming, and senior engineers with real-world experience frequently underperform relative to their actual capability. Use algorithmic tests as one signal, not the deciding one.

Project-based and take-home assignments

Take-home assignments produce the richest signal of any pre-hire coding challenge format because reviewers can see how a candidate structures a solution, handles edge cases, and documents their thinking. The tradeoff is that candidates with competing offers will not complete an assignment that feels open-ended or excessive. Keep scope tight, share the evaluation criteria upfront, and cap the expected time at two to four hours.

Live coding interviews

Live coding is best reserved for final-round evaluation, where observing thought process and debugging behavior in real time is worth the scheduling cost. Some strong engineers simply perform poorly when watched, so use this as a late-stage filter, not an early screen.

Pair programming assessments

Pair programming works well for collaboration-heavy teams and senior roles where working style matters as much as raw output. Scheduling complexity limits scalability, which makes it practical mainly for final-round or specialized role evaluation.

Assessment type comparison

Assessment TypeScalabilityRealismCandidate ExperienceEvaluation EffortBest ForMCQHighLowLow frictionLowHigh-volume, foundational screeningAlgorithmic ChallengeHighMediumMixedLow (automated)Backend, infrastructure, junior-to-mid rolesProject / Take-HomeLow-mediumHighHigh frictionMedium-highMid-to-senior, code quality focusLive CodingLowHighVariableHighFinal-round, process observationPair ProgrammingLowVery HighPositiveHighSenior, team-fit evaluation

Step 3: Select a coding assessment platform

Platform selection has downstream consequences for every hire you make, and a weak choice here creates friction at exactly the points where hiring speed matters most.

When evaluating coding assessment platforms, focus on criteria that are independent of any specific vendor: does the question library cover the languages and frameworks you actually hire for, or will your team spend weeks authoring custom content? Does the platform integrate natively with your ATS (Greenhouse, Lever, Workday, iCIMS), or will recruiters re-key candidate data? What signals does the proctoring system surface, and can you interpret them quickly when reviewing flagged sessions? Can you customize scoring rubrics for proprietary questions, or are you locked into the vendor's defaults? Does the reporting let hiring managers compare candidates against a cohort, or only against a static score? Capterra's 2024 candidate research, summarized in their job seeker survey coverage, found that around 58% of candidates used AI tools to complete assessments — making proctoring signal quality a load-bearing criterion, not a checkbox.

Different platforms make different tradeoffs here. Codility is widely cited for clean candidate-facing UX and a strong focus on engineering-team workflows. HackerRank has one of the deepest public question libraries and a large developer community footprint, which helps with content variety. TestGorilla's strength is breadth: multi-skill assessments that extend beyond pure coding into cognitive, personality, and role-fit testing, which suits generalist hiring.

HackerEarth, positioned as a skills intelligence platform, takes a different approach on integrity signal: rather than surfacing raw proctoring logs and asking recruiters to interpret them, the platform consolidates plagiarism, environment, and behavioral signals into a single per-candidate integrity output that recruiters can act on without forensic review — a tradeoff competitor platforms often leave to the reviewer. HackerEarth covers 40+ programming languages, supports 1,000+ skills across role types, and offers role-specific templates for frontend, backend, data science, and DevOps so hiring managers do not start from a blank slate. ATS integrations with Greenhouse, Lever, iCIMS, and Workday route results into the candidate record automatically. It is used by 500+ global enterprises including Google, Microsoft, Elastic, Flipkart, and Brillio.

Step 4: Design a fair, effective, and job-relevant pre-employment coding test

Platform selection is the infrastructure decision. Test design is the content decision, and most well-resourced technical hiring programs still underperform here.

Set the right duration

Forty-five to 90 minutes is the optimal range for a timed online pre-employment coding test. Below 45 minutes, complex challenges cannot be evaluated meaningfully. Beyond 90 minutes, completion rates drop sharply among senior candidates with competing offers. Take-home projects are the exception: two to four hours is acceptable when scope is explicitly defined and candidates know what "done" looks like.

Calibrate difficulty to the role

Testing a senior engineer on problems they solved in year one is the equivalent of asking a seasoned chef to boil water to prove they can cook. Define difficulty bands before building the test: Junior (0-2 years) needs language fundamentals and basic data structures; Mid-level (3-5 years) needs applied problem-solving and API integration; Senior (6+ years) needs system design judgment, code review, and performance optimization.

Mix question types strategically

One to two MCQs combined with one to two coding challenges produces a more accurate signal than either format alone. MCQs identify candidates who lack basic fluency before they invest time on a harder problem; coding challenges surface gaps that MCQ performance does not predict.

Reduce bias in test design

This is the area where most competitor guides stop short, and it is the most consequential one for both fairness and legal compliance. Avoid questions that require knowledge of specific cultural contexts, idioms, or domains that favor particular educational backgrounds. The test should measure coding ability, not cultural familiarity.

The EEOC's May 2023 technical guidance makes explicit that adverse impact and job-relatedness requirements under Title VII apply to algorithmic and AI-assisted selection tools. Any test producing a disproportionate pass or fail rate for a protected group must be demonstrably job-related and consistent with business necessity, or it creates legal liability.

Practical steps: document the link between each question and a specific job task before publishing the test; apply the four-fifths rule (if a protected group's pass rate falls below 80% of the highest-performing group's pass rate, investigate); and do not use LeetCode performance as a proxy for software engineering ability. Research, including work summarized in the ACM's review of technical interview practices, suggests the correlation between competitive-programming performance and real-world engineering effectiveness is weaker than commonly assumed. These tests can also systematically disadvantage candidates from non-traditional backgrounds who are strong practical engineers.

Step 5: Implement anti-cheating and proctoring measures

Skipping proctoring is not a neutral decision heading into 2026: it is a decision to accept that a meaningful portion of your results cannot be trusted. Capterra's 2024 candidate research reported that around 58% of candidates used AI tools to complete assessments, and the Identity Theft Resource Center's 2024 trends report documented that application fraud rose more than 118% between 2023 and 2024.

Effective remote proctoring for online assessments layers multiple signals: plagiarism detection that compares submissions against known published solutions and other candidates in the cohort, browser lockdown to block access to AI tools and search engines, webcam monitoring using computer vision rather than manual review, randomized question pools so candidates cannot share answers, and IP tracking to flag submissions from the same device.

The balance with candidate trust is real. Communicate proctoring measures in the assessment invitation, explain why they exist, and calibrate oversight to the role's sensitivity. Senior engineers view intrusive monitoring as a signal about organizational culture, and the employer brand damage from that reaction is harder to undo than the integrity risk you were trying to prevent.

Step 6: Evaluate results and make data-driven hiring decisions

A test score is not a hiring decision, and teams that treat it as one will make the same mistakes as teams that never ran the test at all.

Automated scoring vs. manual review

Automated scoring removes the variance that comes from different engineers reviewing the same submission with different standards. Rubric-applied evaluation is more consistent across candidates than human-led screens and does not vary by interviewer mood or fatigue, where variable naming style and code structure conventions can unconsciously influence how a reviewer rates competence. For mid-to-senior roles, combine automated scoring for correctness and efficiency with targeted manual review of code architecture and readability.

Build a scoring rubric

Every candidate should be evaluated against the same weighted criteria. A sample rubric:

CriterionWeightWhat to EvaluateCorrectness40%Does the code produce the right output across all test cases, including edge cases?Efficiency25%Is the time and space complexity appropriate? Are obvious optimizations made?Code Quality20%Is the code readable? Are naming conventions consistent? Is the logic well-structured?Edge Case Handling15%Does the candidate account for null inputs, boundary conditions, and unexpected states?

Set benchmarks and pass thresholds

An arbitrary cutoff like "everyone above 70% passes" is not a benchmark, it is a guess. Use percentile-based cutoffs calibrated to your actual candidate pool: the top 30% of submissions for a role type is a more defensible threshold than a static score. HackerEarth's reporting supports cohort-level comparisons so pass thresholds can reflect real performance distributions rather than guesses.

Avoid common evaluation pitfalls

Speed is not skill. A candidate who solves a problem in 30 minutes is not necessarily better than one who takes 60; penalize only when completion time indicates the candidate could not arrive at a solution, not because they were slower than average. A valid but unconventional solution is also not a failure: if the code is correct, efficient, and readable, the approach the candidate used tells you something positive about how they think.

Step 7: Communicate clearly with candidates before, during, and after

The developers you most want to hire have options, and a confusing or silent assessment process is enough to lose them to a competitor who treats communication as part of the job.

Provide timely, constructive feedback

Talent Board's CandE Benchmark Research consistently shows that candidates who receive feedback (even a rejection) rate the employer more favorably than those who receive nothing. In a market where roughly 61% of job seekers report being ghosted after an interview, per Greenhouse's 2024 candidate experience research, any communication at all is a differentiator. A note indicating the general area where a candidate did not meet the bar protects the employer brand and keeps the door open for future applications.

Set clear expectations for the interview stage

Tell shortlisted candidates what the live interview will cover before they arrive. The assessment invitation itself should include the expected duration, what to have ready, a description of what skills are being tested, the proctoring measures in use, the submission deadline, and a contact for technical issues.

Step 8: Integrate pre-employment coding tests into your hiring workflow

A pre-employment coding test produces its full value only when it sits in the right place in the funnel, and that place is stage two, after the resume screen and before any engineer's time is committed.

A typical technical hiring funnel with coding tests placed correctly:

ATS integration makes this practical at scale. Platforms that connect natively with Greenhouse, Lever, and Workday trigger assessment invitations automatically, route results back into the candidate record, and apply pass/fail logic without manual recruiter intervention. The long-term refinement loop matters as much as the initial setup: track which questions correlate with strong 90-day performance reviews and retire the ones that do not predict what you need them to predict. For deeper guidance on building this end-to-end, see HackerEarth's resources on skills-based hiring and technical interview design.

Common mistakes that undermine your coding assessments

Most assessment programs fail not because the platform was wrong but because of predictable process errors that go unexamined.

Testing skills that are irrelevant to the actual job. Every question should trace back to the skills matrix from Step 1. A puzzle that has nothing to do with the day-to-day work filters for interview prep performance, not job readiness, and strong candidates who recognize the disconnect opt out.

Making the test too long. Senior developers with multiple offers will not complete a three-hour screen before they have had any meaningful interaction with the company. Completion rates drop sharply past 90 minutes, and over-length tests produce more drop-off, not more signal.

Using a one-size-fits-all assessment for all roles and levels. A test calibrated for a mid-level backend engineer is wrong for a junior frontend hire and wrong again for a senior DevOps lead. Each role requires its own skills matrix and difficulty calibration.

Relying solely on automated scores without context. A candidate who scores 68% on a well-designed test may be significantly more capable than one who scores 75% on a poorly designed one. Scores are inputs to a decision, not the decision itself.

Not validating the test for adverse impact or job-relatedness. Failing to document the link between test content and job requirements, or failing to monitor pass rate disparities across demographic groups, creates Title VII liability under the EEOC's Uniform Guidelines on Employee Selection Procedures. This is the most consistently overlooked area in pre-employment testing programs.

Failing to iterate on test design. A coding test that was well-designed 18 months ago may now have its questions circulating on developer forums. Track the correlation between assessment scores and 90-day performance reviews; the questions that are no longer predicting performance are the ones to retire.

Frequently asked questions about pre-employment coding tests

Is a pre-employment coding test the same as a LeetCode-style interview?

No, and conflating the two is one of the most common reasons hiring programs underperform. A LeetCode-style problem is one narrow input — competitive-algorithm fluency under time pressure. A well-designed pre-employment coding test is broader: it can include work-sample tasks, debugging exercises, API integration scenarios, or framework-specific problems that resemble the actual job. The "test" is the design philosophy, not a specific question format, and the most effective programs deliberately move away from pure algorithm puzzles for non-algorithm-heavy roles.

How long should a pre-employment coding test take?

Forty-five to 90 minutes is the optimal range for a timed coding challenge; take-home projects should be capped at two to four hours with clearly defined scope. Senior candidates in particular will abandon anything that feels like an unreasonable time investment before a first interaction with the company.

Are coding tests a reliable predictor of job performance?

Work sample tests have a validity coefficient of .33 to .54 for predicting on-the-job performance according to Schmidt and Hunter's 1998 meta-analysis (and the 2016 update by Schmidt, Oh, and Shaffer), which is substantially better than education (.10) or years of expert

Top Products

Explore HackerEarth’s top products for Hiring & Innovation

Discover powerful tools designed to streamline hiring, assess talent efficiently, and run seamless hackathons. Explore HackerEarth’s top products that help businesses innovate and grow.
Frame
Hackathons
Engage global developers through innovation
Arrow
Frame 2
Assessments
AI-driven advanced coding assessments
Arrow
Frame 3
FaceCode
Real-time code editor for effective coding interviews
Arrow
Frame 4
L & D
Tailored learning paths for continuous assessments
Arrow
Get A Free Demo