MINASWAN_Interviewing.md

The Minaswan::Interview

Session Format: Talk

Abstract

White-boarding is not nice. An unpaid take home project is not nice. We decided to apply the Ruby community motto "Matz is nice and so we are nice," to our enterprise technical interview process. Come learn what changes we made, how we enlisted support of other rubyists and non-rubyists alike, and how you can too.

Details

The current state of interviewing is not nice

• Current state of interviewing at many startups
  • Whiteboarding
    • Pros: Whiteboarding is a low-effort interview on the part of the interviewer. It can also provide data on how a particular candidate compares to other candidates vis-a-vis their ability to answer this particular whiteboarding question. Which is to say, not very good data.
    • Cons: Whiteboarding is not representative of typical developer work. It tends to favor those with traditional computer science backgrounds and those who have studied "Cracking the Code Interview." It can be traumatic for some interviewers especially when administered by an unskillful interviewer.
  • Take home tests that require several hours of unpaid work
    • Pros: May allow the candidate to shine given time and space to think. Also relatively low effort to review projects submissions once the initial hurdle of creating the take home project is complete.
    • Cons: Favors candidates without outside-of-work responsibilities such as family. Creates a level of inertia in the hiring process that some qualified candidates will not overcome - e.g. they don't want the job that badly. Projects are often not at all similar to the day to day of software development.

What is MINASWAN Interviewing?

• Minaswan technical interviewing is divided into to two modules that comprise a 60-90 minute remote interview. There are short HR and engineering manager pre-screens before this interview. And there is one final step around culture add and leadership after. But this is the only technical screen in the process.
• Code comprehension module:
  • Goal: Assess the candidates proficiency at reading other people's code.
  • How-to: Present the candidate with highly simplified code from your domain. Ask them what the code is for, what is good about the code, and what could be improved. This is not a bug finding exercise. There are no tricks or gotchas. Show them code that is as representative of the style of production code your team ships as possible. As simple as you think it should be, make it simpler. Otherwise, building context for the candidate will soak up a lot of time while not providing the interviewer with sufficient actionable data.
  • What we do: Share example of our code comprehension module.
• Code composition module:
  • Goal: Assess the candidates proficiency at writing code.
  • How-to: Present the candidate with a straightforward coding task. Explain the goal of the exercise is not to complete the activity as fast as possible, but rather demonstrate their approach to these types of problems. The activity should require as much algorithmic complexity as is expected of the work of a developer at the company. Again there should be no tricks and no gotchas. This should absolutely not be a test in do you know this esoteric algorithm / data structure (unless that is part of the fundamental work of building software on your team, which it likely is not).
    • Typically software developers do not have to write a recursive function in their day to day. So this type of question is typically not actually a good measure.
    • Code composition involves the candidate sharing their IDE or text editor or better yet, working with a collaborative coding tool.
  • What we do: We give the candidate some json data from our domain and ask them to perform a calculationn on that data. There are no tricks. There is a way to do it with one loop and there is a way to do it with more than one loop.
• Design a rubric that assesses each component for what your team actually cares about in a colleague.
  • Share our sample rubric, how we created it, how we use it, and now we norm on it.

Enlisting support

• Remote work brought on by the pandemic are forcing leaders to rethink hiring processes, which traditionally relied on face to face meetings
• Using the expansion of remote work during the pandemic to enlist support in rethinking the hiring process
  • Arguments to be made to the CTO about why it makes sense to rethink hiring processes now:
    • Layoffs have shaken loose some strong candidates.
    • Code schools and universities continue to train eager new software developers.
    • The state of the world may inspire some experienced software developers to find work more aligned with their interests and values.
  • Arguments to HR
    • The current processes are slow and inefficient. Getting applicants to complete take home challenges can be difficult. Prolonged processes make it is easy to lose candidates to other recruiters and companies along the way.

Pitch

The Minaswan::Interview is a talk about treating other people the way that we would all like to be treated. It points out the deficiencies of typical technical hiring procceses. It elucdiates how we were able to use our new remote work environment along with some compelling arguments to reshape our team's hiring in the image of this community. This story will offer lessons relevant to a wide variety of Rubyconf participants. From CTO's setting the technology direction of their organization to individual contributors about to do their first interview, this talk will describe a Minaswan approach to interviewing and how any team might adopt these practices.

I am excited to give this talk for a few reasons. For starters, I have first hand experience interviewing and getting both hired and rejected. I've also led several hundred interviews over the last three years and am eager to share the insights I've gained from this experience. Finally I think I have the presentation skills to share this experience in an engaging and informative manner given my background as a teacher and leader in k12 public education and experience at previous public speaking events.

I love the idea in the Ruby community that "Matz is nice so we are nice" because it is far too unique of a perspective today. Being nice to each other is more important now than ever and I believe my team has landed on a hiring process that is reflective of this value and also effective at helping us find great teammates. I am eager to share this with my Rubyconf sisters and brothers so that hopefully I can help them MINASWAN their own hiring processes.