Interview
Guide to behavioural and technical interviews
Guide to behavioural and technical interviews
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
Allen and Jing, two software engineers at Google, recently hosted an insightful workshop aimed at demystifying Google’s interview process. The following highlights key takeaways from the session, including a detailed breakdown of the interview steps and useful tips to help you prepare effectively. Process Breakdown By Role Types SWE Internship Online coding assessment & survey Two technical interviews Project search Offer STEP Internship (for first- and second-years) Two technical interviews Offer Project allocation Full-Time Online coding assessment & survey Four virtual interviews: one behavioral, three technical Product area match & final approvals Offer More About Each Task Online Survey Can reference standard libraries and official documentation Make sure to do it by the deadline (typically 7 days) Technical Interview 5 minute introduction + 35 minute coding question + 5 minute closing for you to ask your interviewer any questions Some time to take a break in between rounds Can ask for accomodations during the interview but try to do so before starting the task Languages: C/C++, Java, Python, Javascript, Go; allowed to ask for other languages Possible Topics Loops String manipulation Conditional logic Sort & Search Divide and conquer Dynamic programming memoization Greedy algorithms Recursion Big O Graph traversal Arrays Linked lists Sets Hashing Binary trees Heaps Graphs No brain teasers, puzzles, or trick questions Interview Tips General Keep your microphone on Can use paper to scribble down notes Speak out loud Be careful about what you’re sharing Be yourself - you will be more memorable and it will be easier to connect with your interviewer Come prepared with thoughtful questions for your interviewer What Interviewers Consider How did you analyze the problem Did you miss any edge cases Did you solve the problem methodologically and logically Did you demonstrate a strong foundation in concepts Does the code work, was it testsed Is it clean and easy to maintain the code Were the ideas easily and well explained DO Listen carefully, rephrase the given problem and ask clarifying questions Design a solution and think out loud the whole time Communicate the high level strategy Iterate by analyzing Big O runtime or space complexity Handle edge cases in design too Write actual code Test that code Discuss potential optimizations and expect follow-up questions Explain your thought process throughout the interview AVOID Jumping directly into code Not talking about examples or testing Not writing real code Not understanding question or prematurely optimizing Resources Google Job Alerts Google Career Profile Google Career Resources Google Diversity Google Scholarships Google Careers OnAir Email techstudents@google.com with more questions