On Writing Your Résumé and Hiring Process
There were a number of layoffs in the past month. There were a myriad of LinkedIn posts talking about the layoffs and the market, and there were a few talking or discussing about employment.
I saw a post about someone who was trying to get hired. Some recruiters were kind enough to give the author some tips on improving his/her LinkedIn profile in order to get recruiters attention. Reading through some of the other comments, I noticed that there were some opinions from various individuals that caught my attention.
Quantifiable Metrics
“Use quantifiable metrics to highlight your achievements” (paraphrased by me) was one of the points I noted. I have heard a lot about this and was also advised to do so. However, I felt like most of the quantifiable metrics can be fluffed. Initially, I tried to write something like this in my own résumé, but removed it after reading through the this Hacker News discussion thread.
I was told to show percentages of savings, for example, instead of raw numbers. In my opinion, percentages look nice on paper, but when it comes to discussing it, I am not a good salesman for talking about the raw numbers.
After all, like what the Hacker News discussion thread mentioned - most of the time this is to get through the HR/recruiters screening, and most engineering managers might not care about these. I think I agree with them. I have, however, chose to omit these from my résumé.
“Skills Cloud”
Away from the LinkedIn post for a bit, in the Hacker News discussion thread, someone mentioned about placing a “skills cloud” and being interviewed on it. In the “skills cloud” you wrote that you have done React and Go then you better be able to explain about the language. Heck, I was even interviewed on Java APIs because I mentioned Java in my “skills cloud”. Some candidates also include experience level in the “skills cloud”.
Couldn’t agree more. Not even just in the skills cloud section, don’t put anything on your resume that you’re not ready to talk about in an interview. It’s baffling the amount of candidates that answer questions about their resumes with “Oh it was so long ago I don’t remember” or “Oh it was just a quick 2 week R&D spike that was never shipped”. https://news.ycombinator.com/item?id=34524051
I decided to remove it from my résumé and only mention the things I can speak about during the interview.
Engineering Hiring Process
Take Home Assignments
“Don’t do take home assignments” was a point from the LinkedIn post mentioned above. Some of them deem this as free labour for a company. This seems like a debatable topic on how best to filter engineers when hiring. Certain companies do whiteboard interviews (or LeetCode) whereas some don’t.
I don’t think there’s a right or wrong way of doing things, but doing what’s best for the company or the team.
The people against take home assignments have their own reasoning: you’re spending hours and effort in order to go through into the next stage of the interview. Some argued that one might be a parent who needs to spend time with the kids after work while others counter-argued that take home assignments are more like a real-world scenario on your day to day job. 37Signals shared their take on take home assignments and I quote:
It focused on a sliver of a real problem we’d been dealing with at Basecamp: Support for ban in rack-ratelimit. So it wasn’t some Tower of Hanoi abstract, computer-sciency test that you can look up a million solutions to, and which favor recent grads of CS algorithm courses. No, it was for implementing a feature in the same way you might well be asked to do on the job. There was a clear example of the API we wanted, and then candidates could solve it as they saw fit.
Whilst I agree that one should not spend too much time or doing unpaid work, I think take home assignments have their own place in the hiring process to see if the engineer fits your team based on the assignment tasked.
LeetCode or Whiteboard Interviews
On the other hand, LeetCode or whiteboard interviews as a filter might work for some companies. But perhaps some great engineers aren’t able to do well in these:
Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. Max Howell (@mxcl) https://twitter.com/mxcl/status/608682016205344768
Unless you’re hiring for someone who needs to help optimise or write performant code, copying Google with the interview process might not be the best for your team. I think students often do well in these tests.
Pair Programming
Another approach I have seen and experienced personally is pair programming. Now, this would go strongly against people who are not fond of “free labour” or “spending multiple hours to interview out of my working hours” (mind those companies who have six to seven stages of interviews due to large number of applicants 😔).
Pivotal Labs was one of the companies that did pair programming for interviews, and it fits them well because they pair program frequently during the job! However, even if you do not pair program that frequently in your job, it can be a great assessment to see if the potential hire can gel in nicely with the team.
When I had to hire for interns, giving them take-home assignment which can be completed in a couple of hours in Elm was not feasible – students were already studying in school, and they still had to pick up Elm to do the take-home assignment. I felt that it was unfair for these candidates.
I then switched to pair programming with them to assess their capabilities. I was the driver fixing the code in Elm, and they would be the navigator telling me what to do. Taking just 30 minutes of their time, I was able to assess if they were able to 1) pick things up quickly after I explained concepts to them and 2) able to debug a small issue I planted in the program.
I felt that the pair programming approach was a better solution to look for the right hire since they were solving a scenario which they would encounter on the job. Interviews go two-way so this would also allow the interns to figure out if the programming language and the work they will be doing would be interesting for them.
(This was not written by ChatGPT. I know. It’s the in thing right now.)