For Recruiting Teams and Hiring Managers

For the most part, the bar is really high in terms of candidate experience. I did not have a single negative experience during my 12 on-sites. This is with over 60 interactions with engineers, hiring managers, and recruiters.

I didn’t have a single experience where someone was checking their phone passively, or late to the interview by more than a few minutes, or aggressively and obnoxiously grilling me.

Good candidate experience is now table stakes.

The best interview experience I had was at Sift Science, with the hiring manager, where we went through a collaboration designing one of the systems his team supported. What his team covered was highly technical and difficult to explain (part of a large real time ML fraud detection service), but going through the exercise together gave me clarity into the role and I knew I’d have no problems working with this manager.

The best overall process I had was at Dropbox. The questions asked were not formulaic from Leetcode. I was asked questions that took an existing system (like an OS process), and reduced it to a problem using basic algos and data structures. I was also pushed to think through the worst case scenarios in terms of time and space complexity, and change the solution wrt new requirements. Going through these interviews made me a better engineer.

This is actually my favorite type of interview question for coding interviews. In my past job, I asked candidates to implement a basic text based search function. The candidate and I would go through scoring documents based on word counts, to using inverse document frequency. In the process, we’d implement a reverse index, and keep track of top n documents by score. The only data structures needed for this problem were dicts and heaps. I would ask questions based on which areas the candidate had less familiarity with, and ask followups. I would ask the candidate to iterate on their solution and see if it turned into a mess, or be able to handle changes. And the candidate would hopefully leave the interview with more insight into a new problem area, or have a refresher into information retrieval.

An Ask

I needed four months to prepare for this process, full time. Two months for leetcode and algos, two months for systems design. I am an edge case since I don’t have a traditional background, but frankly I find this odd as I am a tested engineer that has delivered on high impact projects in high pressure settings, and have led small size teams.

I think the expectations on systems design is fair, but most people don’t have two months fulltime to study leetcode style questions.

Can you test for coding ability without turning your interview process into leetcode simulations? I think the answer is obviously yes.

One idea is to consider as an alternative to coding interviews offering candidates a take home exercise path. Not everyone has the time for take homes so this should be optional, but if a candidate is less prepared on the algorithms side, this interview can still test for on the job coding ability. Make the take home exercise fairly involved, maybe up to 10 hours of work. And replace coding interviews during onsites with collaborative follow up feature improvements based on this submitted work.

Another idea is to just offer coding interviews that match on the job projects. Build an API, code the front end, parse a file, find the bug. These can be both challenging and relevant to what candidates will actually do in their future roles.