How to ace technical interviews
- 1. How to Ace Technical Interviews By Melvin, Timothee and Vadym
- 2. Introduction
- 3. TransferWise Singapore Engineering â—Ź 5 months of interviews â—Ź 1631 applications reviewed â—Ź 5 engineers hired
- 5. 78 NPS
- 7. Why do companies care about algorithms? â—Ź Performance matters Engineering cost of investigations, customer impact and resource cost â—Ź A quick way to see how people code Variable names, input validation â—Ź Faster than writing a whole program
- 8. “Design an algorithm to figure out whether someone has won a game of tic-tac-toe”
- 9. Algorithms Design an algorithm to figure out whether someone has won a game of tic-tac-toe What is expected? â—Ź Ask questions, no assumptions â—Ź Describe your idea and its performance (big-O notation) â—Ź Write the code (pseudo-code does not count) â—Ź Share what you are thinking
- 10. Resources ● Main book: ○ “Cracking the Coding Interview” by Gayle Laakmann McDowell ● Short version (videos): ○ https://www.hackerrank.com/domains/tutorials/cracking-the-codi ng-interview ● More algorithms: ○ “The Algorithm Design Manual” by Steven Skiena
- 11. Recommended topics (from the videos) â—Ź Data structures â—‹ Array, Strings, Linked Lists, Stacks, Queues, Trees, Heaps, Tries â—Ź Algorithms â—‹ Sorting, Binary Search, Depth-First Search, Breadth-First Search â—Ź Concepts â—‹ Recursion, Dynamic Programming, Bit Manipulation â—‹ Bonus (from me): Backtracking algorithms
- 13. “Design a car park ticketing system”
- 14. Object-oriented design Design a car park ticketing system What is expected? ● Handle ambiguity ● Define the core objects ● Analyze relationships ● Investigate actions ● Implement the methods related to the problem Resource: “Cracking the Coding Interview”
- 15. “How would you implement Twitter?”
- 16. System design How would you implement Twitter? What is expected? â—Ź Constraints and use cases â—Ź Abstract design â—Ź Finding bottlenecks â—Ź Scaling Resource: https://www.hiredintech.com/c ourses/system-design
- 18. “Do you know about HypeScript” “Yes” vs “Yes, it helps us accomplish X at work. Personally I’m more of a fan of TrendScript instead… Even though the initial learning curve is higher, once you get used to its avocado syntax you can write more productively with it. TrendScript is also faster in production because of quantum threading...”
- 19. “Start coding please.” < Sound of keys tapping and awkward silence for 20 minutes > vs “So what I’m thinking now is that A and B, but C seems like a challenging thing...” “I’ll do an outer variable here, I could do it within the method, but I won’t, because X...” “Let me think about whether this thing I’ve written performs well or not… so if J happens, then K, therefore L...”
- 20. “Do you know how database indices work?” Yes, I am very proficient with database indices vs Practically I know how they help application querying speed, but under the hood I’m afraid I haven’t paid as much attention as I should “OK so how do they work?” It’s simple they work by randomly accessing values until they hit the right one vs So I don’t know, but if I were to guess then maybe they work by randomly accessing values until they hit the right one
- 21. Project X went badly because my teammates were incompetent. vs Project X went badly because I made a mistake doing Y. “Talk about something that didn’t go well.”
- 22. “What do you want to do?” I want to lead a team. vs I want to solve this problem X.
- 23. Interview Metagame I.e. unfortunate facts about the interview process
- 24. False Positives vs. False Negatives ● As a hiring company, it’s a smaller loss to accidentally not hire an amazing person, than to accidentally hire a terrible person. ● So if the company is not sure? It’s more likely to lead to rejection than acceptance. ● You can help by mitigating uncertainty.
- 25. Doing Reconnaissance â—Ź Interview happening on HackerRank? Get familiar with the HackerRank editor. â—Ź Interviewer has given a talk before? Watch the talk and get familiar with their voice. â—Ź Interview happening on a whiteboard? Practice writing.
- 26. Law of Numbers ● Taking on more rather than less interviews: ○ Practice makes perfect ○ An underdog may turn out to be better than you thought ○ Equally-footed negotiations ○ Eliminating grass-is-greener syndrome ● But balance: Don’t let quality suffer as a result of quantity.
- 27. Product Engineering It’s not just about tech
- 28. Product Code=
- 29. Product Engineer â—Ź First of all an Engineer! â—Ź He knows well his domain â—Ź He is customer focused â—Ź He makes decisions
- 30. We have just built an MVP: Minimum Viable Product
- 31. Are you able to? â—Ź See what is the product (customer) impact done by your change. â—Ź Prioritise between tasks based on the impact? â—Ź Keep the balance between speed and quality? â—Ź Leave your biases aside.
- 32. Questions