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:
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.