Cananito.github.io/interviewing-for-big-tech-cos-swe.html at master · Cananito/Cananito.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
<!DOCTYPE html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Interviewing For Big Tech Companies (Software Engineering) - Rogelio Gudiño</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width" />

    <style>
        html {
            background-color: #fff;
            font-family: Avenir, sans-serif;
            color: #444444;
            font-size: 125%;
            margin-left: 1.5%;
            margin-right: 1.5%;
            margin-top: 0.75%;
            margin-bottom: 0.75%;
        }

        #content {
            margin: auto;
            max-width: 660px;
        }

        a {
            color: #6498cc;
        }

        span#my-name {
            font-size: 28px;
            font-weight: bold;
        }

        span#last-updated {
            font-size: 90%;
            font-style: italic;
        }

        div.table-container {
          overflow-x: scroll;
          position: relative;
          width: 95.5vw;
          left: calc(-45vw + 45%);
          margin-left: 1.5%;
        }

        table, th, td {
          border: 1px solid black;
          border-collapse: collapse;
          margin: auto;
        }

        th, td {
          padding-left: 6px;
          padding-right: 6px;
        }
    </style>
</head>
<body>
    <span id="my-name">Rogelio Gudiño</span>
    <hr />
    <div id="content">
        <h1>Interviewing For Big Tech Companies (Software Engineering)</h1>
        <p><span id="last-updated">Last updated: Dec 20, 2022</span></p>
        <p>Given that interviewing for software engineering roles in big tech companies is a skill of its own, <strong>the goal of this document</strong> is solely to help people gain or improve that skill and increase their chances of getting a job at a big tech company. It does not argue for or against the interview process and neither does it propose something better.</p>
        <h2>General Preparation</h2>
        <h3>Big O Notation</h3>
        <p>Not always, but in most interview exercises/problems you’ll be asked to identify the time/runtime or space/memory complexity of a method or algorithm. Be familiar with both the <a href="https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions">notation and their name</a>. Mainly:</p>
        <ul>
        <li>O(1) = constant.</li>
        <li>O(log n) = logarithmic.</li>
        <li>O(n) = linear.</li>
        <li>O(n^2) = quadratic.</li>
        <li>O(c^n) = exponential.</li>
        </ul>
        <p>This will be asked with one of three purposes:</p>
        <ul>
        <li>The interviewer simply wants to assess you have the skill to correctly identify complexity.</li>
        <li>You presented more than one solution and the interviewer wants you to go with the most optimal.</li>
        <li>Your solution is not as optimal as the interviewer expects, so once you identify the complexity, they’ll tell you what’s the complexity of the solution they expect from you.</li>
        </ul>
        <h3>Basic Data Structures</h3>
        <ul>
        <li>Hash Map/Table (A.K.A. Dictionary).</li>
        <li>Linked List (singly and doubly).</li>
        <li>Queue.</li>
        <li>Stack.</li>
        <li>Set.</li>
        </ul>
        <p>You won’t necessarily be asked to implement these, but you’ll very likely be using them as part of your solutions. So it’s very important you’re very familiar with them: how they’re implemented, and the runtime complexity of all their operations (read, add, remove, etc.).</p>
        <h3>Binary Trees</h3>
        <ul>
        <li>Implementation (modeling it).</li>
        <li>Traversals: pre, in, post.</li>
        <li>Depth-First Search.</li>
        <li>Inserting.</li>
        <li>Runtime complexity of all operations.</li>
        </ul>
        <p>Less important, but be familiar with:</p>
        <ul>
        <li>Breadth-First Search.</li>
        <li>Deleting.</li>
        <li>Balancing.</li>
        </ul>
        <h3>Algorithm Techniques/Methods</h3>
        <ul>
        <li>Recursion.</li>
        <li>Dynamic Programming.</li>
        </ul>
        <h3>Other Topics</h3>
        <p>These are either less likely to come up or just need to have a notion about them:</p>
        <ul>
        <li>Sorting algorithms: Extremely unlikely you’ll need to implement one. They’ll likely come up in conversation only when you sort something via standard library methods in order to assess your runtime complexity identification skills of a given solution.</li>
        <li>Trees: Mainly for modeling. Outside of that, might be useful to be aware/familiar with some concrete types of trees:<ul>
        <li>Binary tree.</li>
        <li>Ternary tree.</li>
        <li>N-ary tree.</li>
        <li>Binary search tree.</li>
        <li>B-tree.</li>
        <li>AVL tree.</li>
        <li>Red-black tree.</li>
        <li>B-tree.</li>
        <li>Trie.</li>
        </ul>
        </li>
        <li>Threading/locking/async: Interviewers might add this aspect to their problem to test knowledge around it.</li>
        <li>Binary search on both binary trees and arrays: Also unlikely for you to have to code it up, but will be useful to know how it’s done.</li>
        <li>Bitmasks and bitwise operations: These tend to show up in tricky questions (which are likely banned from most companies) that involve performance.</li>
        <li>Heaps and priority queues: // TODO.</li>
        <li>Graphs: // TODO. Outside of that, might be useful to be aware/familiar with some concrete types of graphs:<ul>
        <li>Directed graph.</li>
        <li>Undirected graph.</li>
        <li>Directed acyclic (DAG).</li>
        </ul>
        </li>
        <li>ArrayDeque (A.K.A./and/or: Circular Buffer, Ring Buffer, ArrayQueue): Will probably never come up, but they’re interesting! (For iOS folks, NSMutableArray is <a href="http://ciechanowski.me/blog/2014/03/05/exposing-nsmutablearray/">implemented this way</a>, which is why inserting and removing objects at index 0 is super fast!)</li>
        </ul>
        <h3>Whiteboard</h3>
        <p>This is optional, but because onsite interviews will very likely be on a whiteboard, it’s recommended that you practice solving problems in one. If you’re not used to writing code in one, odds are it’ll hurt you a tiny bit since you’ll either run out of space, write extremely slow, find yourself erasing a lot, trying to fit stuff you missed in tight spaces, etc.</p>
        <p>A few tips are:</p>
        <ul>
        <li>Start at the very top left or as close as you can get to that corner.</li>
        <li>Do not write things down as they come to your mind. Quite the opposite, try to have a rough draft of the whole code in your head before writing it down. This will save you from erasing or doing weird contortions in order to fit missing code.</li>
        <li>Use a right corner for non-code, like input and output examples.</li>
        </ul>
        <h2>Domain Specific Preparation</h2>
        <h3>iOS with Objective-C</h3>
        <ul>
        <li>Memory management.<ul>
        <li>How ARC works.</li>
        <li>How ARC compares to garbage collection.</li>
        <li>Ownership property attributes: <code>strong</code>, <code>weak</code>, <code>assign</code> (with both objects and primitives), <code>copy</code>, etc.</li>
        <li>How to prevent memory leaks: retain cycles via property ownership attributes and block scope capturing.</li>
        </ul>
        </li>
        <li>Delegates, notification center, target/action, KVO, responder chain, handler/callback blocks.</li>
        <li>Copying.<ul>
        <li>NSCopying protocol: <code>- copyWithZone:</code>.</li>
        <li>NSMutableCopying protocol: <code>-mutableCopyWithZone:</code>.</li>
        <li>NSObject class: <code>- copy</code> and <code>- mutableCopy</code>.</li>
        </ul>
        </li>
        <li>Equality.<ul>
        <li>NSObject protocol: <code>- isEqual:</code> and <code>- hash</code>.</li>
        <li>NSObject class: default implementation of that protocol.</li>
        </ul>
        </li>
        <li>Block syntax. Some companies/interviewers will require you to know it, some others are a bit more forgiving/flexible. So just to be safe, memorize <a href="http://goshdarnblocksyntax.com/">goshdarnblocksyntax.com</a>.</li>
        <li>Extending classes via categories (and/or class extensions) vs subclassing.</li>
        </ul>
        <h3>iOS with Swift</h3>
        <p>TODO: Need to update with latest language features!</p>
        <ul>
        <li><a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html">Memory management</a>.<ul>
        <li>How ARC works.</li>
        <li>How ARC compares to garbage collection.</li>
        <li><code>weak</code> and <code>unowned</code> references.</li>
        <li>How to prevent memory leaks: retain cycles via property ownership (solved with <code>weak</code> or <code>unowned</code> references) and closure scope capturing (solved with closure capture lists).</li>
        </ul>
        </li>
        <li>Reference vs value semantics: classes, structs, <code>inout</code>.</li>
        <li>Optionals, <a href="https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html#//apple_ref/doc/uid/TP40014097-CH5-ID333">optional binding</a>, and <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html">optional chaining</a>.</li>
        <li>Enums: <code>indirect</code> (<a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html#//apple_ref/doc/uid/TP40014097-CH12-ID536">recursive enumerations</a>), <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html#//apple_ref/doc/uid/TP40014097-CH12-ID149">raw values</a>, and <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html#//apple_ref/doc/uid/TP40014097-CH12-ID148">associated values</a>.</li>
        <li>Generics: <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Generics.html#//apple_ref/doc/uid/TP40014097-CH26-ID182">type parameters</a> and <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Generics.html#//apple_ref/doc/uid/TP40014097-CH26-ID189">associated types</a>.</li>
        <li><a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/TypeCasting.html">Type casting</a> (checking types and downcasting).</li>
        <li><a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html#//apple_ref/doc/uid/TP40014097-CH25-ID284">Optional protocol requirements</a>.</li>
        <li><a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID5">Access control levels</a>: <code>open</code>, <code>public</code>, <code>internal</code>, <code>fileprivate</code>, <code>private</code>.</li>
        <li>The <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/doc/uid/TP40014097-CH33-ID524">guard</a> branch statement.</li>
        <li>Closure syntax. Some companies/interviewers will require you to know it, some others are a bit more forgiving/flexible. So just to be safe, memorize <a href="http://goshdarnclosuresyntax.com/">goshdarnclosuresyntax.com</a>.</li>
        <li>Extending classes via class extensions vs subclassing.</li>
        </ul>
        <h3>Android</h3>
        <p>TODO!</p>
        <h3>Front End</h3>
        <p>TODO!</p>
        <h3>Back End</h3>
        <p>TODO!</p>
        <h2>The Interview</h2>
        <h3>Choosing a Language</h3>
        <p>It’s very likely you’ll have a choice on which language to use. Always pick the one you’re most familiar with or know the best.</p>
        <p>That said, there are a few things to consider:</p>
        <ul>
        <li>If it’s not a popular one, odds are your recruiter won’t find interviewers that are familiar with it, and your odds of succeeding may be lower since interviewers not familiar with it won’t be able to make as good of an assessment.</li>
        <li>If you’re interviewing for an iOS or Android role but you’re not very familiar with Objective-C/Swift or Java (respectively), you should still stick to your main language. It’ll make it a bit harder or error-prone for the recruiter to find the correct interviewers, but the odds of you succeeding will likely be higher.</li>
        <li>If you’re interviewing for an iOS role and the language you’re familiar the most is Objective-C, it’s tempting to choose a less verbose one because it’ll take less whiteboard space. It’s highly suggested you stick to Objective-C.</li>
        </ul>
        <h3>Syntax Errors</h3>
        <p>Most companies are forgiving when it comes to syntax errors (Facebook might be the most strict). That said, you should strive to avoid them and write code that essentially compiles.</p>
        <h3>Interviewer Notes</h3>
        <p>Interviewers both take notes and copy your code. For note taking they’ll either use their computer or pen and paper (although some with great memory don’t take notes). For the copy of your code though, they’ll either type it live into their computer or take pictures of the whiteboard and then transcribe it all into their computers once the interview is over.</p>
        <p>Many times the interviewers that write your code live into their computers won’t tell you about it at the beginning, so it throws people off sometimes: it’s either distracting or it makes it feel like they’re not paying attention. With that said, know that they <em>are</em> paying attention (which may make it less distracting).</p>
        <h3>Before The Problem(s)</h3>
        <p>The first 3-10 minutes of the interview are likely for the interviewer to ask you domain specific questions, behavioral questions, about your resume, or to answer any questions you have about the company or the interviewer’s job (this last one is most likely to happen at the end of the interview).</p>
        <h3>The Problem(s)</h3>
        <p>The key to performing well in the interview is communication and verbalizing most—if not all—of your thoughts.</p>
        <p>The other thing you should keep in mind is that in most—if not all cases—you want to have a working solution fully coded, rather than a highly optimized solution that’s incomplete or contains many errors.</p>
        <p>The following steps are a good recipe to succeed:</p>
        <p>TI = The interviewer.<br />
        Y = You.</p>
        <ol>
        <li>TI: They will describe the problem to you.</li>
        <li>Y: Ask questions that clarify or reveal the specific edge cases of the problem. If the interviewer didn’t give you input examples, it might be a good idea to ask for some. If you don’t have any questions, at the very list verify that you understood the problem by saying out loud what you need to do. A few examples of questions: “do I have to worry about case sensitivity?”, “can you remind me of the definition of x?”, “can the input be a negative number?”, “is there a specific memory or runtime complexity I should aim for?”, etc.</li>
        <li>Y: Once everything is cleared out, vaguely describe the first solution that comes to mind. If multiple solutions came to mind before or during your description of the first solution, continue by mentioning/describing them. If you gave more than one, tell the interviewer what are the pros and cons of each one and which one you’d like to go with.</li>
        <li>TI: They might have a different opinion on what solution you should go with. Odds are they’re trying to guide you in the right direction, so it’s recommended you gracefully take their recommendation (after understanding and evaluating/assessing it, never take recommendations blindly!).</li>
        <li>Y: Try and give them all the steps of the solution‘s implementation verbally. In some cases this is not feasible or very hard to do so, but try. In some cases the steps are simply the main lines of a method. In other cases the steps are a bit bigger, general, and/or abstract.</li>
        <li>TI: If they detect an issue in your steps hopefully they’ll bring it up. They might also have new questions or suggestions for you. But at this stage it’s likely that not much conversation around the solution needs to take place anymore.</li>
        <li>Y: Announce you’ll now proceed to write code and do so. If you can, speak and write at the same time. If this is hard, try doing the speaking before or after you write each line of code.</li></li>
        <li>Y: Once you’re done writing the code you needed to write, tell the interviewer: “I’m now going to test the code to see if it works. Do you have any question, comment, or suggestion before I do so?”. If they do have one, address it.</li>
        <li>Y: (VERY IMPORTANT STEP!) Now proceed to test the code by making a line by line dry run<span style="color: #892bf5; font-weight: bold;">*</span> with a couple or few different inputs (if you were giving examples of them, use those) and going line by line of all the code you wrote. For example: “Ok let’s say we pass in 5, so x = 5, x square is 25, if x is greater than 10 we do this, then we return true. If we pass in 1, x = 1, x square is 1, if x is less than 10 we do this, we return false”.</li>
        <li>Y: If you found errors or issues, address them. If not, tell the interviewer that is your solution.</li>
        <li>TI: 3 things can happen now: they’ll add something new to the problem, they’ll give you a new problem, or you’re done with the interview. If it’s one of the first two, simply repeat from step 1.</li>
        </ol>
        <p><span style="color: #892bf5; font-weight: bold;">*</span> There are very few interviewers who’s expectation of testing the code isn’t a line by line dry run of your code, but to write actual unit tests. Make sure to ask the interviewer what are their expectations when it comes to testing the code.</p>
        <h3>After The Problem(s)</h3>
        <p>You’ll likely get 5 minutes at the end of the interview to ask questions to the interviewer (if this didn’t happen at the beginning). For the most part (if not the sole purpose of) this is for you to genuinely learn about the company through the interviewer.</p>
        <h2>Practicing and Other Resources</h2>
        <h3>Cracking the Coding Interview</h3>
        <p>For many years, the <a href="https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850">Cracking the Coding Interview book</a> by Gayle Laakmann McDowell has been the most popular way to prepare for technical interviews. This was the way I prepared myself, along with the series of videos: <a href="https://vimeo.com/ondemand/ctci">https://vimeo.com/ondemand/ctci</a>.</p>
        <h3>LeetCode</h3>
        <p>In recent years LeetCode has been to main resource for technical interview preparation. The following are curated lists of top questions to practice:</p>
        <ul>
        <li><a href="https://www.teamblind.com/post/New-Year-Gift---Curated-List-of-Top-75-LeetCode-Questions-to-Save-Your-Time-OaM1orEU">Top 75 questions</a></li>
        <li><a href="https://leetcode.com/problem-list/top-google-questions/">Top Google questions</a></li>
        <li><a href="https://leetcode.com/problem-list/top-facebook-questions/">Top Facebook questions</a></li>
        <li><a href="https://leetcode.com/problem-list/top-amazon-questions/">Top Amazon questions</a></li>
        <li><a href="https://leetcode.com/problem-list/top-microsoft-questions/">Top Microsoft questions</a></li>
        <li><a href="https://leetcode.com/discuss/general-discussion/1734481/apple-top-100-questions">Top 100 Apple questions</a></li>
        </ul>
        <h2>Specific Companies</h2>
        <h3>Google</h3>
        <p>TODO: Process (recruiter contact, schedule phone interview, schedule on-site interview, interviewers submit feedback, recruiter decides whether to send review packets to committee, committee makes a hiring decision, review packet is sent to Larry (or a VP?) for a quick last check, offer is extended).</p>
        <p>TODO: Practice in a Google Doc for phone interview. Tools, Preferences..., Uncheck: “Automatically capitalize words” and “Use smart quotes”.</p>
        <p>TODO: On-site: 5 interviews of 45 mins each. 1 hour for lunch with a Googler, free to ask anything, you don’t get evaluated.</p>
        <p>TODO: Google Hiring Process videos:</p>
        <ul>
        <li><a href="https://www.youtube.com/watch?v=k-baHBzWe4k">How We Hire</a></li>
        <li><a href="https://www.youtube.com/watch?v=ko-KkSmp-Lk">Prepare for a Google Engineering Interview</a></li>
        <li><a href="https://www.youtube.com/watch?v=XKu_SEDAykw">Example Coding/Engineering Interview</a></li>
        </ul>
        <h3>Facebook</h3>
        <p>TODO!</p>
        <h3>Apple</h3>
        <p>TODO!</p>
    </div>
</body>
<footer>
    <hr />
    <p style="text-align: center;"><a href="/">Home</a></p>
</footer>
</html>