Subconscious Compute has been hiring since 2018 and has found some wonderful talent🎉 (Meet the Subsonscious Team). We now have a continuous influx of interest from skilled individuals. As a first-time CTO, I believe I did a good job in hiring. This is a personal feeling, as I have nothing to compare it against. Nonetheless, I did make some costly mistakes. We continue to make small adjustments to our recruitment process. This post gives insight into our recruitment process for those hoping to join our team.

First, I want to talk about the rules and values that guide our interview process. We’re a product company and we work very close to “the metal” and the kernel. Kind of stuff that nerds may love. Are you a nerd?👀 We appreciate colleagues who make bad jokes about work! Like LWN, hacker news, XKCD, Dilbert and dinosaur comics. You get the idea!

We are based in Bangalore which is renowned for its service industry. The talent pool that cater to service industry is of little use to us. We mainly require people with depth. We are looking for people with one or two exceptional skills, even if it is not related to our area of expertise; individuals with a longer-than-average attention span and the ability to stay focused on their craft for more than a few hours. To filter out such candidates, we do the following during the interview.

• Do a DFS instead of a BFS. Start with a simple problem and dig deeper. Ask questions to assess the candidate’s skill level and see if they can view the world in a grain of sand. Don’t worry, we definitely stop when the candidate starts feeling uncomfortable.

• Don’t ask questions about topics you already know well. Ask questions about areas you’re not an expert in, but have enough knowledge to spot any incorrect answers. This has two advantages:

  • You’ll get someone more knowledgeable than you on that subject.
  • You’ll know if you can learn something by talking with the candidate in the office.

  You can also teach them what you’re good at; there’s no need to spend time on topics you already know. Plus, you won’t fall into the "curse of knowledge" trap during the interview.

• Carelessness in communication is indicative of carelessness in thinking. We no longer consider resumes with signs of poor communication. This isn’t about language proficiency, but rather about writing that is unclear and disjoint. Crafting good code demands the same level of mental rigor as composing a well-written email.

• If a candidate’s project does not have a readable README file, there is no point in looking at the code. We love examining a candidate’s work history on GitHub or GitLab. Even if it is a work-in-progress project, the quality of the README file is a great indicator of the project’s quality. A well-crafted README is a sign that the candidate is emotionally invested in the project, rather than just having something on GitHub because it is expected.

• Skills with data structures and algorithms do not guarantee system-level thinking. Candidates who are good at solving leetcode-style problems may not have the software engineering skills we look for. We don’t prioritize coding exercises; instead, we want to ensure fluency in one programming language. After that is achieved, we shift our focus to system-level thinking. We define ourselves by the problems we solve, not the languages we use.

  We do have a special affinity for Rust🦀!

We often encounter people who are enthusiastic about the tech we use, like kernel, system programming, Haskell or Rust. They enjoyed it in college and want to do it again, which is great! However, we have noticed something strange a few times. They often ask for a higher salary than they currently make even if their skill level is sub-par at this moment. I think it to be excessive. If you’re passionate about something and have been wanting to pursue it, you should be brave enough to begin from the scratch. Your pay should not exceed that of others with the same experience. Remember, You can’t have it both ways!

These people remind me of the following Dilbert comic strip.

Interview Timelines

We strive to keep our interview process brief and to the point. We don’t care too much about skills or abilities that won’t be utilized in the next twelve months. Knowing how to invert a binary tree is impressive, but not pertinent to us. Typically, two meetings are enough, but occasionally we may require more for a pivotal role.

The interview process is meant to optimize the following.

• The candidate learns as much as possible about the nature of the problems they’ll have in their job. Our interview questions are essential unsolved problems we are facing at the work and we don’t have the answer yet. So we want you to give it a shot. The candidate is not expected to solve them but come up with some insights and ask the right questions.
• We try to see how well a candidate listens. Can we learn something from them? Will they be great at brain-storming?
• We try to find out how much a candidate cares about their work. We ask them about their tools and processes and why they like them. This tells us a lot about them. A person who is passionate about their work will invest in tools.

Advice for freshers

We have some advice for freshers because we deal with their resumes the most.

• Make a resume that is easy to read and not too long. We recommend using Reactive Resume | A free and open source resume builder. Upload it as a PDF.
• Adding a cover letter can increase your chance of getting the job. But it’s okay if you don’t have time for it.
• Show us your public projects on GitHub or GitLab. We can judge your skills from your commit history. This makes the interview process shorter.
• Review your work carefully and fix any typos. Make sure to include your most recent projects. Written communication is different from speaking. Be clear and mindful of your words.
• Follow the process. When asked, book a slot on the calendar quickly. Don’t expect us to do it for you. Respect everyone’s time!

Last but not least, here is our Job Board! If you’ve read this post, you might be interested in reading about Engineering at Subconscious Compute.