CS for Interviews -- Base Understandings
Learning Goals
- Students will have a basic understanding of what types of challenges they can expect in a technical interview
- Students will understand the limited scope of Computer Science that appears in technical interviews
- Students will build a linked list to illustrate the concept of a data structure
- Students will practice iterating on algorithmically-challenging code in a short period of time
Warm Up
Before class starts, write notes and thoughts on the following questions:
- Are you a Computer Scientist? Why or why not?
- Why do you think Computer Science topics like data structures and algorithms are the focus of some technical interviews?
- If you were asked “What kind of CS topics have you studied?” what would you answer? Can you come up with at least five specific examples?
S1: Understanding the Technical Interview (40 minutes)
Let’s set some context by discussing the following:
- Where do technical interviews typically fall in the hiring sequence?
- What questions does the technical interview attempt to answer?
- What are the common formats for a technical interview?
In pairs: Given that context, do you think the technical interview will be a strength or weakness of your interview process? Why?
Technical Interview Buckets
Live technical interviews, conducted in-person or remotely, generally fall into one of these buckets:
- 60 minutes to solve a puzzle or challenge from scratch
- 30+ minutes to iterate on or refactor your previously submitted take-home challenge solution
- 60-90 minutes of pairing with a developer at the company to write new features or solve a puzzle
- 60+ minutes to independently add a feature or fix a bug in an existing app that you haven’t seen before
Pathways to Technical Interview Success
1. Exposure to Common Puzzles
- There is a large set of potential topics and puzzles
- There are a small set of puzzles and concepts that pop up a significant percentage of the time
- Some common puzzles are collected in turingschool/challenges
- These are the kinds of things you should be practicing regularly now and throughout the job hunt.
- 30-60 minutes 3+ times/week done consistently would be great.
- There are many sites with other examples like Exercism or LeetCode
In pairs: Have you used any resources like that to practice already? What have you learned?
2. Practice with Data Structures & Algorithms
- If you got a CS degree, you’d spend at least two semester-long classes on DSA
- If you’ve written implementations of each of the common challenges two or three times, you’re well equipped to succeed
- Common data structures: Linked Lists, Stacks, Queues, Binary Trees, Graphs
- Common sorting algorithms: Bubble, Merge, Insertion, Binary Tree
In pairs: What do you think you can individually improve or practice to do your best in a technical interview?
3. Defining a Process
- What do you do when you don’t know what to do?
- In flight school, you learn to Aviate, Navigate, Communicate
- If you just “do programming”, you’ll fail and look bad doing it
- You need to know what your process is and make it easy to get started
- Make the easy things easy: how do you set up your environment? Files? Tests?
- Define success: how will you know when you’re done?
- Start small: iterate, learn, prove your progress – not just one big leap
- Practice being loud and talking it out
- Half, not half-assed
In pairs: If you started a 60 minutes code challenge right now with an interviewer watching you, what would be the first three things you’d do?
4. Intentional Practice Not Stupid Practice
- Most people missed the point on the idea of “10,000 hours”
- If it were just a matter of stacking hours, every worker with five years experience could be “world-class”
- Intentional practice means breaking down complex processes and practicing the skills both in isolation and combination
- If you’re working on your free-throws in basketball, you might take 50 shots where you’re focused on the flick of your wrist
- 50 shots where you focus on the last moment your fingertip touches the basketball
- 50 shots focused on the movement in your hips and knees
- Not just 150 free throws and hope you get better
In pairs: Have you ever practiced a skill with real intention? What was it and why were you trying to get better?
Conclusions
- Technical interviews are not real programming, they are a circus trick
- Like a Rubik’s cube, if you know the right steps to take then you can look like a genius
- You can practice and be prepared because success is mostly dependent on process not knowledge
- There is knowledge/familiarity worth building to solidify your confidence
S2: Linked Lists (60 minutes)
We’ll use the rest of our time today doing some intentional practice using Linked Lists.
Conceptual Intro
Let’s diagram a Linked List. You should be comfortable defining/using/differentiating all of these terms:
- List and Node
- Data and Link
- Head and Tail
- Push and Pop
Linked Lists can be implemented using an iterative method, a recursive method, or a hybrid of both.
In pairs: In an interview, how would you describe the difference between an iterative approach and a recursive approach?
Setup
Please follow all instructions carefully and completely.
- Clone the repo at turingschool/data_structures_and_algorithms
- Move into the
linked_lists
subdirectory - With your pair, add the day of the month that each of you were born (ex: Feb 12 + Nov 23 = 35)
- If the result is
>=31
, you’re working in JavaScript.<30
then you’re working in Ruby - Move into the subdirectory for the language you’ll be using
Paired Work Challenge
The repo you’ve cloned is an example of how some technical challenges are communicated. Rather than laying out complex instructions in English, it just gives you tests to pass. But our point here is to practice our process more than it is to complete building a Linked List. Instead of just pushing ahead as fast as you can, follow these steps:
- Write the class files you need to get the tests running with no errors (only skips)
- Unskip the tests that focus on the functionality of a
Node
(ruby) orListNode
(js) - Work to make those tests pass
- Switch which of you is typing and who is talking
- Find the tests that emphasize using
push
to add a node onto the list. Work through making these pass. - Delete your implementation of the
push
functionality. Yes, seriously.skip
tests until you’re back to the beginning of working onpush
- Switch typer/talker (aka driver/navigator) roles. Rebuild the
push
functionality again. - Stay with the same roles and work through the
pop
functionality until tests are passing - Delete your
pop
functionality and switch roles, then rebuild it step by step. - Stay in your roles and build the
lastNode
functionality. - Swap roles and build the
include
functionality - Swap roles and build the
find
functionality - If time allows, continue to build out
delete
andinsert
operations
Review
- Look at the code you’ve written. Is it complex? Which was slower, writing the code or figuring out what to write?
- What does that imply about how you should spend your time in a technical interview?
- As the functions got more complicated, were you gaining momentum or slowing down?
- How did the role reversals affect your process?
- How does exploring a problem like this in pairs influence your ability to do it solo?
S3: Intentional Practice (50 minutes)
Let’s treat this period a little more like a technical interview.
You should not…
- Use the web/Google. There are no complex methods or classes you need to implement these solutions and googling “recursive linked list in javascript” is just cheating ;)
- Let yourself get stuck. You’re practicing your problem solving. If you really can’t get over it, move around it.
You should…:
- Work solo
git reset --hard
to get back to a blank repo just like we started with- Code in the language of your choice
You may…:
- Ask staff members conceptual questions, but the programming is up to you.
- Get asked questions by staff members probing to understand your thinking and process
And, most importantly, follow the flow of the test suite working through each individual feature first implementing it using iteration and making that pass, deleting that implementation, then reimplementing it using recursion. Don’t build one entire implementation then the other, do it feature-by-feature.
S4: Closeout (10 minutes)
Let’s spend 10 minutes to reflect on our work today:
- What’s one thing you thought you knew but it turned out you didn’t?
- Are you going to build Linked Lists on the job? Why learn them?
- Why is practicing your process more powerful than building your knowledge?
- How does today’s session change your plan to prepare for technical interviews?