Building a product experience from day 1 at HackerRank

Role: Design Director


screenshots from different parts of the HackerRank product

I joined HackerRank before it existed. Its parent company, Interviewstreet, had a strong product but lacked the engagement to grow a community and capture the market. A few months into my tenure, our CEO presented the idea of HackerRank, a community for programmers and companies that want to connect with them.

Over three years, I helped conceptualize and validate the product, built and maintained our design system and pattern library, and helped grow the product to over a million uses. I touched every part of the product development process (even pushing a few lines of Ruby to production) and left a far stronger and capable product designer than I arrived.

Understanding our users

Hiring was broken. Companies were facing a programmer shortage amidst high demand, and programmers, especially those located outside of Silicon Valley, struggled to stand out and be discovered for these positions. Companies looking for tech talent wasted hundreds of hours interviewing and assessing programming candidates who couldn’t perform at the level required by the job. Smaller companies had a harder time attracting top talent (even if they were solving really cool problems).

I’m not a programmer, and I’ve never hired programmers, so I needed to understand who these people were whose problems my design would solve. I started internally. I wanted to know what the developers on our team found most engaging, and what they didn’t like, about existing programming sites. I read countless threads on Quora and HackerNews and Reddit to get anecdotal information. I spoke to as many different types of programmers as I could.

Ultimately, I distinguished 4 different types of users, exhibited by these personas:

  • Middle-aged woman in a suit, wearing glasses and facing forward with a neutral expression


    HR recruiter for Fortune 500 corporation. She is short on time and wastes hundreds of hours recruiting and screening programmers, but most are under-qualified.

  • Younger man wearing a hoodie and glasses, facing forward and smiling


    Senior Engineer and Team Lead. He is responsible for writing programming tests for potential applicants and checking their code. He also enjoys coding competitively for fun.

  • younger man wearing a hoodie with a bag slung across his body, facing forward and smiling


    Highly-ranked programmer employed in Asia (and loves his job). He participates in Hackathons for fun and is proud of his high ranking. He continues to push himself to get better.

  • young woman smiling at the camera with her arms crossed


    Junior Computer Sciences major at a U.S. college looking for an internship or a job. She is comfortable with mid-level challenges in one or two languages but wants to reach expert status.

Product Discovery

I was lucky to work with a team with diverse skills but a united vision and enthusiasm for HackerRank. Product discovery was an ongoing process. Armed with the flexible, living style guide I built, it was easy to be agile and explore concepts quickly to determine their value.

I often designed in code. This made it easier to communicate key interactions and get live feedback. It also sped up the product development process. When confronted with a new problem to solve, I could quickly sketch out a concept, get buy in from stakeholders, wire up the front-end, and work with a developer to bring the markup to life, and push our solution to production to see if it changed our metrics or solved usability issues.

wireframes scattered in a pile showing sketches of a website with text noting interactions and information
A collection of early wireframes used to explore product direction and interaction flows, 2012

Our team was great at staying attached to a problem instead of a solution. Through a combination of user testing and validating through metrics and feedback, many of our major engagement flows went through several stages of improvement before reaching a successful state.

One example of how we practiced this was in the development of our code editor. People were frustrated by the lack of options in our code editor and it was confusing how to change editor mode.

window with a code editor interface showing the C language and buttons to submit or compile the written code
Original code editor, lacking options that people expected from a useful code editor

After some user and usability testing to understand what people expected from the code editor, we released our changes. Users could easily modify options that you would find in a standard code editor, including changing editor mode, allow auto-complete, etc.

view of a code editor like the one before but with prominant 'Current Version' written across the top and other versioning-related interface components
New spiffy code editor, including options that were undiscoverable and lots of bloat that no one needed. Whoops.

The problem is I went way too far in the other direction. We added so many options that we had to nest them in a menu (that was poorly label). We also added version control, which lots of people asked for and sounded cool but ended up just confusing people.

rejected image of the HackerRank code editor showing a saved note in a past version
Really, what was I thinking?

Turns out the solution people needed was some basic functionality, and an easy way to upload code from their default code editor. All of the super, fancy stuff like code versioning was handled by the products that already did it best. We integrated with the experience people already enjoyed, giving them full control over their code solutions (and a more intuitive interface).

updated design of the HackerRank code editor
By refocusing on the problem, we got rid of the bloat while maintaining functionality 💪

Building Blocks

I owned the organization and structure of HackerRank’s CSS/SCSS codebase and patterns. While our goal was to reach the MVP (minimal viable product) as quickly as possible, writing CSS for a large application requires constant attention to scalability, optimality, and coherency.

I started by designing an exhaustive styleguide, then structured our pattern library using reusable variables and mixins to keep things simple. My OOCSS approach was similar to the atomic framework, using flexible modules defined by their parts and not their location.


  • Aim to use classes for styling purposes, reserve IDs for javascript.
  • Use semantic classnames. .challenge_primary is more scalable than .big-content-header.
  • When in doubt, use a longer class name, for clarity.
  • Keep things as short as possible without adding confusion (borrowed directly from Github).

App Screenshots

image of the manage interface image of an email from the conversations interaction image of the HackerRank leaderboard image of a HackerRank group