26 May 2022

Improving an interview experience

Alice Walsh

PhD, VP of Translational Research at Pathos
Alice works in drug development, where she is excited about the potential of computational research to yield breakthroughs for patients.
Watch this hangout
portrait of Alice Walsh in front of off-white wall

Episode notes

We were joined by Alice Walsh, PhD, VP of Translational Research at Pathos. Alice works in drug development, where she is excited about the potential of computational research to yield breakthroughs for patients.

 

Loved that Alice also asked this question back to the audience:

 

How do I make an interview a good experience for a candidate? Or have you had any nightmares that’d be helpful to share?

 

A bunch of thoughts shared from the group:

 

⬢ I’ve had way more success not giving a technical interview, and having the technical interview be more of a discussion where I’m not even asking them to whiteboard anything or it’s just talking.

 

⬢ If I asked them, “how do you develop a shiny app”, I’d much rather someone tell me I’ve never developed a shiny app in my life but I use R Markdown every day. That tells me a lot about their ability to actually jump in and learn something new and their transparency.

 

⬢ I’m much more interested in the process. How do people approach a problem and solve challenges that they encounter versus the specific project they worked on because they’re not going to work on that project ever again with me. It’s going to be a new project so they will need to learn something anyway.

 

⬢ I’ve had success hiring from meetups or hackathons. Seeing people here and the way they problem solve gives you a lot of insight about these individuals.

 

⬢ My company actually does do a technical interview and we give candidates a data set while they’re on site or in a Teams meeting. We give them an hour to see what sorts of insights they find with a few very specifically directed questions. What we’re often looking for is not someone to have perfect answers to those questions – it’s really about understanding how they looked at the data set, what other information they want, and what do you wish you had more time to do. You get to see how people work through something and it’s okay if they don’t have a perfectly polished presentation.

 

⬢ I’ve had a nightmare interview that became a pop quiz on R stuff. What are all the packages in the tidyverse (and at the time I didn’t use tidyverse I was base R)

 

⬢ A nightmare one that sticks in my head was, please describe in detail the differences between Python 3 and Python 2.

 

⬢ I think, “this is something I would Google” is a valid answer sometimes because even if I don’t know this, I know where to find it and am really confident in my ability to Google this.

 

⬢ Honestly if I ask somebody a question and they said this is something that I know I could find the answer to, that would be a perfect answer to me. Not knowing but knowing where to find the information great.

 

⬢ I went on 3 interviews and they each had a technical part where for every single one of them the answer was: dynamic programming. They must have gone somewhere and decided that was the algorithm to ask about. I found that a bit ridiculous because it wasn’t relevant to what they were working on and it was off-putting. Now, when I interview people I try to make it more of a conversation around the data and what we might actually be doing.

 

⬢ I have an optional take home: “here’s a data set, take an hour and tell me something. Use whatever tools you want: Excel, R, Python, an abacus.” The key thing I want to see is a written output of what you did. I’m still on the fence, though, because I know a lot of people are anti-technical component. I’m still trying to figure out if it is really helping us make the best hiring decisions.

Subscribe to more inspiring open-source data science content.

We love to celebrate and help people do great data science. By subscribing, you'll get alerted whenever we publish something new.