The process was initiated through an employee referral. The initial phone screen was quite thorough and really helped me evaluate what the company was doing and its progress in terms of its product and objectives. The recruiter was very down-to-earth.

After the phone screen, the HubSpot coding assessment was set up. You simply follow a link to begin. Get familiar with the instructions. It's helpful to have a skeleton application ready beforehand. I won't divulge too much on the content, as I believe it is a fair assessment of developer skills, and the HubSpot team put a good bit of thought into it.

I decided it would be prudent to do this on a Saturday morning, as the code targets an API using a key. There's no requirement to have anyone on the HubSpot side at this stage, and it allows for a block of time to focus without distractions. At times, I did feel quite pressured by it, as I changed my approach twice in the first hour. Nevertheless, I completed the assessment in roughly 2.5 hours and received a confirmation email straight away. You have as much time as you need to clean the code prior to submitting the package.

An on-site interview was arranged a couple of days later. This was standard procedure. They provided a full breakdown of the schedule for the day. All in all, it ran from 13:45 to 17:00. For anyone who hasn't done extensive on-sites, it's best to arrive a little early, get a feel for the environment, and drink plenty of water. Your brain needs it!

The first round was heavily focused on a relational database schema and walking through queries of average complexity. This was essentially social media connections and how to model them and their relationships. I felt good momentum with this round but fell a little short at the very end with some of the more exotic queries. Most people should get the majority of these questions even with a little experience with MySQL, MSSQL, Sybase, Postgres, etc.

The preferred solution here was to double up records, which initially confused me as I found it to be quite an expensive way to handle this situation. Although I could not get over my own mental hump and fully figure out my own solution without tripping up. Think complexity versus simplicity. Both interviewers were quite helpful, however, and it really felt more like a technical discussion one would have during their normal day-to-day. The very final portion of this round related to indexing tables and how to optimize queries. These would be the bar-raiser questions.

The second round was a high-level system design discussion for a URL shortening service, basically TinyURL, after a nice chat covering a few laid-back situational questions.

I enjoyed this one quite a lot. I actually learned quite a few tips from the interviewer here, and my suggestion to break certain parts of the system down into micro-services was well received. Know concepts such as load balancing, caching, database replication, redundancy, CAP theorem, and a couple of other key concepts relating to well-scaled distributed systems.

This is quite a broad topic, so be careful not to over-rehearse some predefined answers, because one criticism and your whole plan will fall apart. Learn and understand the concepts, and the interviewer will guide the discussion based on your understanding. The key with these types of interviews is to assess how you deconstruct a much larger problem. So, ask lots of questions, get a very clear definition of what the system should do, then define the API and work from there. I contradicted myself a little here when it came to SQL vs. NoSQL.

The third and final round was a one-to-one with the hiring manager. There were a good few situational questions here, like dealing with conflicts, etc. There are plenty of examples of what comes up during these types of interviews.

There wasn't a real conversational flow to the questions in this round, and I didn't feel as relaxed as in the previous rounds. I can't really say for sure how that impacted the final decision, as sometimes it's really more formality, and hiring managers just want to see if you can work with the team, fit in, and ultimately not be a pain in the backside for them.

After that, I was given a tour of the office. It's quite a nice space, and it really has that startup vibe. Overall, I quite enjoyed the experience, and it gave me a very good chance to correct my shortcomings.

For junior-to-mid-level positions, if you really want to work here, practice your A-game and start whiteboarding solutions, as the common trend for these on-sites nowadays is to ask easy questions to ease you in, then intermediate, then more complex, then basically the bar-raising questions that get you the gold stars if you can answer them.

My one critique of the whole process: the role was Java-focused, yet the topic was hardly covered at all, nor any programming concepts for that matter.

If you like what HubSpot is doing, go for it! :)

How would you model friendships and relationships in a database?

How would you design a URL shortening service?

How and why would you use indexing on a table?

What is a foreign key?