Panel with Scott Biggart, Haris Mahmood, Stacey Mulcahy and moderated by Kyle Simpson
Note: the speakers have been paraphrased.
Kyle: The starting point for this discussion is the premise that technical hiring is broken from the top down.
Haris: Early stage screening processes fail when you are just matching buzzwords. However, looking at things like the number of years of experience can be highly relevant when hiring for senior dev roles.
Scott: Screening can be very important at large corporations due simply to the large volume of applications that need to be processed.
Stacey: Screening can be done by doing other things like job fairs.
**Scott: **San Francisco vs New York resumes look dramatically different. In NYC, they less often have the latest tech stack but in exchange have piles of experience with legacy bank systems. You need to look deeply at a resume to get a person’s story.
Haris: Look at a resume for mentions of impact and output. Don’t just stop at the line that says they are a React dev, look further to see what they’ve done this tech. There is a real lack of knowledge at the top level of the hiring process. This is where the buzzword matching comes into play.
Kyle: what is the most glaring problem right now in the hiring process?
**Stacey: **The candidate often doesn’t fully understand the job. Recommends asking before the interview, "what am I going to hate about this job?"
Scott: One challenge is trying not to miss out on the right candidate because maybe they don’t know the particular algorithm you ask them about in an interview. This kind of questioning about things like algorithm knowledge also disproportionately favours recent computer science grads who know the answer, but in reality have zero experience.
Another technique he favours in interviews is to create conflict and use this as a gauge of how that candidate will fit into the work environment.
Haris: Rather than specific knowledge, really try to understand how a candidate thinks about a problem. Nuance is required in the interviewer’s ability to really be clear about asking what they are looking for. Don’t throw away a candidate because they don’t specifically know the answer you are looking for.
Scott: He likes to ask a candidate about the most obscure technology they have listed on their resume to see how honest and actually knowledgable a candidate is. Did they list a tech because they felt they should or thought it was cool OR because they really do know it?
Stacey: Recommends asking deeper questions, ones that can illustrate a candidate’s true knowledge of a technology. Ie "What does Python offer you that Javascript doesn’t?" or “What’s the number one bug in language x that you wished was fixed?”
Haris: At Shopify they do a pair programming exercise. The candidate can choose any stack they wish in order to solve a given problem. They are looking to see the candidate’s thought process, not the technique.
Scott: Loves whiteboard questions. But not specifically write some code, rather, to show high level thinking. One of his favourites is to sketch out a few circles that represent verticals in Uber and then asked the candidate to design Uber. He’s testing to see if they ask the right kinds of questions.
Haris: Whiteboards are problematic if all you are asking the candidate is to write code. This is an abuse. It’s not fair to do coding as you don’t have a normal coding toolset available. Whiteboards are best for letting candidates visually communicate ideas.
Stacey: Whiteboards should ultimately be a test of the candidate’s communication skills and confidence in expressing their knowledge.
As a candidate, don’t hesitate to ask to show the answer another way if that works better for you. Suggest pen & paper or a tablet or whatever you need.
Interviewers MUST work at making the candidate feel comfortable.
Scott: Don’t over prep. Don’t focus on things you don’t know. If an interviewer asks you about something that isn’t familiar, say you don’t know. Be honest. Focus on showing the things you DO know.
Also, be prepared to bootstrap an application with some toolset.
**Haris: **Have opinions! If you hate Angular, say so, but be prepared to say why.
**Stacey: **Humility goes a long way. Fine line between humility and over confidence/ego. Give credit to others who worked on projects with you. Don’t name drop.
Scott: You can find this during the time given for the candidate to ask questions. The things a candidate asks are solid indicators of who they are. Ask about how the teams work? Why do they do things a certain way? Challenge the interviewer.
Suggest finding better ways to ask about work/life balance than asking that specific question.
For certain roles there is a need to see past certain things to find someone skilled in a very specific problem set.
Haris: Looking for passion, what makes a person tick.
Stacey: Looking to see that you are passionate about things. Often this is illustrated by side projects.
**Haris: **Prefers to let the candidate decide what to show. If they do offer it, it does give you a chance to see what they know.
Scott: They let you look at old versus new code to see learning over time. Doesn’t need to see personal projects, but likes to see activity on other projects.
**Haris: **It would be great if all interviewers would let candidates know why they were rejected. He himself was initially rejected by Shopify. But they gave him feedback that helped him grow and improve so that he got hired next time.
Scott: Getting feedback becomes harder when you are dealing with large organizations.
Stacey: She will always give feedback if the problem was a technical one.