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