These are notes that I typed up when google was presenting on effective strategies for the technical interview.

googletechinterviewnotes.md

title	date	author
Google Technical Interview Prep Workshop	\today{}	Ralph Vente

Interviewers

• Brendan
• Raymond
• Elena

Resume

• intended graduation m/yr
• relevant coursework
• projects and classes focused on data structures and algorithms
• extra-curriculars to gain technical experience
• coding proficiency and experience

be sure to review the minimum and preferred qualifications

bold the names of algorithms draw the recruiters' attention

• put ttp residency or any ttp affiliated anything

• put acm, club membership

• "went to baruch hackathon"

buzzwords are a no-go. They will not help you. They just take up space.

resume should contain github and linkedin

Ask questions that challenge the interviewer: "Have you thought about quitting in the past month and if not, why?"

Don't be afraid to ask for questions Don't be afraid to switch it up. If you reach a road-block, express that you're at a roadblock;

breadth-first, depth-first search

Tech Interview Considerations

• write tests; include edge cases; spanning zero on the number line; empty input object

• explain why the data structure works

• leave comments in the code (make sure comments are correct)

• if your code has bugs and you find them, that's good

• you should be writing function

• don't be off by one

• draw a rubber duck

Comms and Presentation

• view this as a discussion, not an interview
• Ask clarifying questions (especially when writing examples / test cases)
• draw a cfg
• assume all questions are hints

Common Mistakes

• don't start coding immediately. Write high-level pseduocode / a cfg; explain what you think

Do's and Donts

Mention if you have seen a problem before. This helps your reputation.

• don't have too many test cases

• write a runtime table chart with the state of every variable

• colored marker on the board

• show thought rather than code; start out with a pseudo code comments

  • pay attention to inputs and outputs, but not specific implementation details

• don't prematurely optimize

• other comments on for loops may reflect time-complexity

• brute force is not evil, but talk about tradeoffs

Example

Rearrange an array of characters so that no to adjacent characters are identical:

Bad practice: didn't ask questions before going into code

Who would be calling this function? Notice: Determine whether it's appropriate to mutate or make a copy.

Bad practice: arguing with interviewer

rundown of good technical interview practices

Continually\dots

• acknowledge time constraints
• ask questions if you're unsure or there is ambiguity
• be respectful.
• acknowledge trade-offs between two methods.

#. Repeat the question back them. Find edge cases.

• Even number of elements vs odd number of elements #. Pseudo code and diagram code #. Write main function/class. Call implementation functions. #. Whiteboard to confirm your main against your pseudo-code/diagram #. Return to your implementation functions

Q & A

(@q1) Question: "Should your resume be OCR -optimized?"

No, a human always looks at your resume. The idea that automated machinery looks at your resume is largely a myth. -- Raymond

This document is CC-BY-SA. You have the freedom to share and produce derivatives , but please keep this copyright and acknowledge the authors of all previous versions if you do so.