Who needs another rant?

This is really a set of notes and key consideration points for myself, and I'll grow and expand it as I go through the interviewing process.

As someone that hasn't attended interviews (especially from the candidate side) for a long while, getting back into the process produces surprisingly a lot of unexpected negative experience and reveals a number of inefficient practices, which I want to list here along with what I think works better.

There's no shortage of talks and ideas about how to improve the interview process. One of the most useful thoughts, that interview performance does not equal job performance, was recently covered here: https://blog.professorbeekums.com/2021/interview-performance/ - and even though I have my reservations about some parts of it (like 2-hour interviews), its overall message is really thoughtful.

Things to consider (from the candidate side)

• Ask to thoroughly elaborate on the interview process to understand all steps.
• Beware of tasks that take "whatever you think is enough" time or over 4 hours: large scope and lots of work.
• Ask if the assignment requires specific stack or any other prior knowledge.
• If the interview looks or feels surprising or not going well, speak up and potentially stop early: the outcome is unlikely to be positive so it's a waste of time.
• Unless you're early in the interviewing process or haven't done it in a while - then failing is also important as it gives you knowledge and experience for next attempts.
• If the interview is long, ask to break down. If they're back-to-back, ask to schedule on different days.
• If possible, ask to give you feedback after each interview so if one step is blown the others could be avoided. Unless the goal of interviewing is learning.
• Do not close up to the questions you don't like; asking clarifying questions or reasons behind the question might help to relax and form a better answer.

Red flags

• Separate coding and/or system design interviews after elaborate take-home assignment (not related to the assignment).
• More-than-one-hour interviews should be split or break provided.
• Time-constrained coding in front of something is stressful and restricted.
• Several coding interviews instead of one or take-home task.
• Take-home assignment subject/goals are unrelated to company business.
• Any IQ-kind-of-test (called "aptitude test" nowadays) is a huge no-no, as it's a repetitive blunder that doesn't really assess any personal qualities.
• Tests or forms to fill without prior personal communication or clear explanation of hiring process.

Process pitfalls

• Live coding interview of any kind is stressful and many people don't perform well. If questions is purely algorithmic or irrelevant to the company it's also frustrating.
• Take-home assignment without follow-up.
• Looking for an all-round ready-made candidate without considering that engineers learn and adapt quickly.
• Requiring by-the-book knowledge of development and design patterns.
• Very specific system design question with expectations of follow-up questions - questions implying more information or discussion should be open and vague.
• Making engineers do HR's job by asking behavioral questions for the sake of it (often just reading them).
• Asking the candidate to describe their solution while coding or talking to them while they code (breaks focus).

Better options

• Meaningful take-home assignment that are relevant to what team/company does.
• If the team is fixed on live coding, at least coding problems could be relevant to the company domain.
• Technical interview is a review of the assignment plus touching on follow-up subjects like performance, scaling, monitoring, security and so on
• Merge request review with comments as it resembles real life.
• Breaking assignment into several small tasks building on each other or exploring different areas.
• Presenting the candidate with established project and infrastructure to build on, or clearly mention infrastructure is the (potential) part of the assignment.
• Provide excessive set of problems to solve in flex-limited time ("no more than 3-4 hours"), clearly mentioning that solving all is not required, just as many as candidate feels reasonable within given time.
• Another option: let candidate prioritize which problems to solve, mentioning that that's the part of the assignment (so solving all is inherently not the goal)

Little Book Of Calm

• People usually mean well - they want to hire ideal candidates, people who know the most, who could start contributing right away. And it's their right and choice - so as long as I'd wish interviewers would consider that candidate could learn whatever is missing or perform better in non-time-constrained environment, I understand the other side as well. It's OK.
• The interview is a lengthy process - collecting feedback takes time, people are busy, things get forgotten and abandoned for no ill reason. Things happen, and it's OK.
• I will fail to pass interviews, I will pass but still considered not a good fit, my application will not be considered, another candidate will get hired before me, some outcomes will not satisfy me and I'll bail, and many other things will get in the way. That's OK, everyone will find the right place/candidate in the end.

Follow-up

This page is to be updated with more thoughts, findings and ideas.