CSE 403Software Engineering

Spring 2020

Interviewing and Wrap up

June 05, 2020

● Interviewing● Code-interview examples● Wrapping up the quarter

Today

Interviewing

● If you have done this before, reflect on your experienceand think about what you would add.

● If you have not, you are likely going to be doing this soon!

Overview

1. Recruiter/resume screen2. Preliminary interview(s)

● Non-technical and/or technical phone screening● 1-2 technical phone interviews● 1-2 online programming challenges

3. On-site interview day(s)● About 3-6 in-person technical interviews

4. Follow-up technical phone/video interview(s)

Timeline: 3 weeks to 3 months

The process

● Practice result-first and situation-action-result pitch.○ By how much did you lower costs or increase profits, and how?

● Focus on recent experience and prepare for typical questions.○ Tell me about a project you’ve worked on.○ Tell me about a recent programming challenge you faced.○ Tell me about a recent conflict with a teammate.○ Why do you want to work here?

Studying for non-technical questions

● Practice result-first and situation-action-result pitch.○ By how much did you lower costs or increase profits, and how?

● Focus on recent experience and prepare for typical questions.○ Tell me about a project you’ve worked on.○ Tell me about a recent programming challenge you faced.○ Tell me about a recent conflict with a teammate.○ Why do you want to work here?

Keep in mind your “basic” job description.

Studying for non-technical questions

● Practice result-first and situation-action-result pitch.○ By how much did you lower costs or increase profits, and how?

● Focus on recent experience and prepare for typical questions.○ Tell me about a project you’ve worked on.○ Tell me about a recent programming challenge you faced.○ Tell me about a recent conflict with a teammate.○ Why do you want to work here?

Your CSE 403 reflection is a great starting point.

Studying for non-technical questions

● DO pick a good language and know it well!○ Use language features that make things easy (e.g., list slices in Python)

● DO know the obvious topics○ Depth-first and breadth-first traversals.○ Implementation/operations/traversals/running times for hash tables, binary

(search) trees, arrays, singly-linked lists, and heaps.○ Quicksort, merge sort, ...○ Non-traditional uses of hash tables.○ Dynamic programming.

Studying for technical questions

● DO practice real questions○ Strongly prefer breadth of knowledge to depth.○ Work through the questions, don’t just read the answers.○ Read interview books and websites (interviewers look here too).○ Share with friends (but consider NDAs).

● DO use paper or a whiteboard, not a computer.● DO switch roles with a friend being “interviewer”

and “interviewee”.

Studying for technical questions

● DON’T (re)learn complex data structures in detail○ Your interviewers haven’t written an AVL tree since college, if ever.○ Most questions feature traversals of arrays/strings, linked lists, grids

(two-dimensional arrays), and DAGs.

● DON’T rely on the recruiter to tell you about questionsand topics to expect○ Each interviewer selects their own questions.○ Interviewers are likely from different teams.

Studying for technical questions

1. Write the problem on the whiteboard. Ask clarification questions.

2. Talk through an algorithm. No code yet!

3. Write code at a moderate pace.

4. Step through at least one non-trivial test case. Fix bugs carefully and methodically.

Tackling a technical question: outline

1. Write the problem on the whiteboard. Ask clarification questions.● Guarantees that you understand the question/problem.

● If you’ve done this exact problem, say so and outline a solution(be prepared to describe the solution in detail).

● Discuss simplifying assumptions and clarify the spec:○ What about symbolic links in file systems?○ Does this maze have more than one exit?○ Is the input size bounded (is space complexity an issue)?

Tackling a technical question

1. Write the problem on the whiteboard. Ask clarification questions.

2. Talk through an algorithm. No code yet!● Always mention obvious-but-inefficient solutions. They’re great

fallbacks, and show that you can solve the problem.

● You’re never totally stuck. You can always decompose and solve at least part of the problem, so focus on that!

● Stay positive.

Tackling a technical question

1. Write the problem on the whiteboard. Ask clarification questions.

2. Talk through an algorithm. No code yet!

3. Write code at a moderate pace.● This will feel slow!

● It’s okay to forget some syntax or an API, just say so.

● Use good decomposition: “I really wish I had a function that …” (don’t implement any helpers unless asked to).

● And btw, stay positive :)

Tackling a technical question

1. Write the problem on the whiteboard. Ask clarification questions.

2. Talk through an algorithm. No code yet!

3. Write code at a moderate pace.

4. Step through at least one non-trivial test case. Fix bugs carefully and methodically.● Don’t be careless or fast-paced.

● Make sure to diagnose the root cause before fixing a problem.

● And yes, stay positive :)

Tackling a technical question

Examples

Two code-interview examples

Breakout rooms● Pairs, 2x8 minutes

1. Student 1: interviewer; student 2: interviewee2. Student 2: interviewer; student 1: interviewee

● Coding problems:1. Given a set of n-1 numbers

○ Numbers enumerated from a to b (n numbers)○ One number is missing○ Find the missing number

2. Determine whether a player has won in Tic Tac Toe

● You have to be competent and make the interviewers like you.

● Some interviewers pick a question they know you can’t solvejust to see how far you get and how you handle the stress.

● Postpone important interviews until after you’ve had practicewith other companies.

Other aspects: psychology

● You are also evaluated on the questions you ask.● Demonstrate insights, passion, and critical thinking

○ I’m interested in learning X. Did you come to this company with a background in X already, or are there opportunities to learn it?

○ How do you overcome problem Y given your environment(scale, distributed systems, tools, deployment, etc.)?

Other aspects: your turn to ask questions

● You are also evaluated on the questions you ask.● Demonstrate insights, passion, and critical thinking

○ I’m interested in learning X. Did you come to this company with a background in X already, or are there opportunities to learn it?

○ How do you overcome problem Y given your environment(scale, distributed systems, tools, deployment, etc.)?

● Do you want to work there?○ Can you imagine getting along with your interviewers?○ Questions to ask:

■ Is there opportunity for advancement and movement between projects?■ How much time do you spend in meetings per week, coding per day, etc.? ■ What is the ratio of developers to testers to product managers?

Other aspects: your turn to ask questions

● You got the job, yay!○ Negotiate, it’s expected.○ Make reasonable and justified demands.○ Remember: a lot of money to you is peanuts to them.

● Or you didn’t○ Don’t take it personally, the false-negative rate is really high.○ Reflect on the experience and prepare for the next interview.○ Companies encourage you to “try again and again”.

Did you get the job?

● Cracking the Coding Interview (Gayle Laakmann)● Programming Interviews Exposed (Mongan, Giguere, and Kindler)● Elements of Programming Interviews (Aziz, Prakash, and Lee)● Don’t Call Yourself a Programmer (Blog post, Patrick McKenzie).● How to Get a Job at Google (NYT, Thomas L. Friedman).● UW CSE Recruiting Policy for Employers (UW CSE).

Resources

● Technical questions do not test the most import software engineering skills, but they show up on interviews anyway. Why?

● What are advantages of coding interviews?

● What are disadvantages of coding interviews?

Discussion

Wrapping up a challenging quarter

● Compare your skills today to a quarter ago…○ Bottom line: Your project would be (much) easier for you.○ This is a measure of how much you have learned.

● Your next project can be more ambitious○ Building interesting systems is never easy (like all worthwhile endeavors).○ Practice is a good teacher.○ Requires thoughtful introspection -- don’t learn only by trial and error!

What you have learned in CSE 403

Please complete the course evaluation form online:https://uw.iasystem.org/survey/225417

● Useful to future students● Useful to course staff● Useful to the department

Course evaluation

● System building is fun○ It’s even more fun when building them successfully.

● Be an engineer and solve problems○ Don’t call yourself a programmer.○ Don’t be defined by a technology stack.

● Continue to learn○ Use the techniques and tools of CSE 403 effectively.○ Build, reflect, refine, and repeat.

Go forth and conquer