Greg Wilson, a former UofT professor and now co-founder of Software Carpentry, came to give suggestions on how to perform a technical interview and insights into the hiring process at his own company.
General Advice
- Take what he says with a grain of salt; it has been a long time since he was applying to jobs
- Do not apply if you don’t meet the legal criteria
- However, still apply if you don’t necessarily meet all skill criteria (e.g., programming language requirements)
- Page 1 is the only page that matters
- Include your GPA; he prefers consistent grades that can be slightly lower (e.g., Bs) rather than lots of As and Cs
- For any stats included in your resume, (e.g., “42.3 improvement in customer retention”), ensure you can back up statements like this; even professionals don’t have those same statistics
- Stats: out of ~1700 applications, he typically hires around 4
- When applying to jobs, looking for interdisciplinary (e.g., CS + X jobs) are typically more niche (harder to find) but with less competition
- Referrals can be helpful but not always, but useful to keep your network in mind to ask questions about their experience with the company, interviewing, etc.
- Open-source GitHub contributions can be beneficial
- Green flags: it’s been around for 2 <= x <= 10 years, 3-4 contributors, regular release history, has plug-ins (e.g., PyPika, mkdocs)
- Things to consider when debating contributing: how fast are response times to issues or PRs, and how quickly is it possible for you to get caught up/started
- Ergonomics is important! Take care of your hands and wrists
- Interview is two-way street, you are also interviewing them
- Don’t do during interview, but maybe once hired, ask if the interviewers are trained
Zoom Interview
- First screen is 15 minutes with HR, just to ensure that you haven’t misrepresented yourself
- Second is 30 minutes with Greg
Greg’s Interview
Structure
- First two minutes to introduce yourself
- Question example: “What course was your favourite and your least favourite?”
- Looking for coherence and clear explanations; practice interview questions (without knowing them before) with your friends!
- Introduction followed by 3 minute icebreaker (3:00)
- Next interview question, “What’s the most complicated thing you’ve built?”; expected time around 5 minutes
- Start with what does your project do? High-level explanation
- What was the biggest challenge?
- What did you do differently next time?
- Question about design, also around 5 minutes
- Suppose you wanted to build an X.
- Suppose we want to make it more complicated by doing Y, by adding Z feature.
- You think of a solution, you realize it might be wrong, you rethink about it and correct yourself to come with a better solution — that’s what always happens.
- He talks about the company, also around 5 minutes
- Look at the company website - what products they’ve built.
- Around 5 minutes left for your questions
What Greg is Looking For
- Can you explain technical details?
- If it’s on your resume, I’m allowed to drill down.
- If you dodge, he will definitely drill down
- Can you explain why you built something as you did?
- Can you think aloud / think with him?
- Do you have interesting questions (i.e., have you looked at the company prior to the interview)?
Coding Interview
- Your CV tells me that you can write code, but can you debug?
- A better indicator of on-job performance than LeetCode exercises
- How well do you use your tools?
- For example, Greg has run an experiment measuring the coding speed of 4th year students. They can range from 3.5 minutes to 28 minutes.
- Those who code it faster are the ones who can use the features of their code editors (like VScode or Pycharm)
- To him, AI counts as a tool. But double-check with interviewer during interview
- Debugging is very important in the industry!
- Looking to test how methodical you are
Offer Process
- Internships typically not negotiable, but real jobs yes
Improving Chances of Getting Hired
- Practice with friends: critique each other’s CVs, practice Q/A
- Learn to use available tools well (e.g., conditional debugging breakpoint in the code editor)
- Build a personal website, GitHub Pages counts, but hosted and interactive is better
- Be kind
Improving Chances of Getting Re-Hired
- Learn to participate in status meeting
- Learn to review code and software designs
- For example, if an algorithm is broken, will it interact badly with other parts of the code?
- Learn to estimate effort
- Realistically how long will something take?
- It is a sign of politeness
- Take time to learn about the other people at the company in different roles; what is it they do, and what happens in the other 90% of the business
Interactive Exercise
- Clone this repo
- Take a look at the README
- Spend 15 minutes looking at PicoSSG file and explain it
- Talk through the code:
- Where did you start? Where did you end?
- What do you think this one function (main()) is doing?
- What does parse_args() do?
- What does find_files do?
- What does the loop do?
- Only Environment() may not make sense at first sight, but you should be able to understand it from the context it’s used in and by inspecting its arguments/other elements it’s interacting with.
- There’s still something there that doesn’t make sense? Google it!
- Start with the hardest part.
- Interviewers watching you navigate through the code, looking to see how you deal with pieces you don’t understand. How do you resolve it?
- There’s still something there that doesn’t make sense? Google it!
- Use debugger to go over code, as a step-by-step code execution tool
- Each project will have CODE_OF_CONDUCT.md and CONTRIBUTING.md in its parent directory, these will include instructions and rules over how you should run the files, etc.
- What might be missing from the directory?
- There is no tester!
- It’s important to write unit tests
Resources
- askmanager.org - lots of advice and stories from managers