Massive Technical Interviews Tips: Interview Preparation Misc

Wednesday, December 2, 2015

Interview Preparation Misc

http://itsallonesandzeroes.blogspot.de/2013/07/prepping-for-google-interview.html

Be on LinkedIn and update your resume as often as possible. If you are a software engineer this will surely raise the attention of big name companies like Google, Facebook, Yahoo, Twitter, Amazon, etc... and their recruiters will at least email you.
Do mock interviews with SW engineer friends
Keep talking to the interviewer as you work - silence is not a good thing.
Reason out things that you dont understand. Even if it seems hard, your interviewer will nudge you in the right direction if you put up an effort.
Do not change the question - if they say your input is a linked list, dont change it to be an array to serve your purposes
Don't write psuedo code, they want a coding sample. So be as complete as possible
Unless you are the creator of the language you are using, DO NOT tell them you are a 10 out of 10. There is a chance, although minor, that the person interviewing you wrote the language or had a part in it.
Check for bound cases whenever writing code,
When using recursion, remember the stop case.

"The consensus was that you are a smart guy. He said everyone basically said that if you spent more time on the design/analysis, then your code will be alot cleaner to write" Boom goes the dynamite! I have been going about this all wrong. I spent way too much time on algorithms/data structures and not enough time on code cleanliness.

Working day to day as a SW engineer at a variety of companies, I tended to just come up with a general idea of what I wanted to do, start writing code, compile, run, fix bugs and repeat. Unfortunately this breeds bad habits especially when code quality is being scrutinized during a programming interview. And since I got that feedback maybe that's something that shouldn't be a norm in my day to day job either. However I do want to emphasize this, DONT EXPECT TO ALWAYS BE ABLE TO WRITE BUG FREE CODE - it just not human, nor is it realistic for anything than the most trivial of code blocks. So don't feel bad if you cant. The goal is to write relatively bug free code. Besides your interviewers probably cant write completely bug free code either. Side note ( for high tech companies the probability that most engineers could get their job back if they re interviewed is 50% anyways - but I digress.)

Working day to day as a SW engineer at a variety of companies, I tended to just come up with a general idea of what I wanted to do, start writing code, compile, run, fix bugs and repeat. Unfortunately this breeds bad habits especially when code quality is being scrutinized during a programming interview. And since I got that feedback maybe that's something that shouldn't be a norm in my day to day job either. However I do want to emphasize this, DONT EXPECT TO ALWAYS BE ABLE TO WRITE BUG FREE CODE - it just not human, nor is it realistic for anything than the most trivial of code blocks. So don't feel bad if you cant. The goal is to write relatively bug free code. Besides your interviewers probably cant write completely bug free code either. Side note ( for high tech companies the probability that most engineers could get their job back if they re interviewed is 50% anyways - but I digress.)

I then spent quite a bit of time watching programming interviews on YouTube. I think this surprisingly helped me alot. Reading/Writing algorithms and such is great but watching a highlights reel on YouTube on good interviews was def the final nudge I needed. I would suggest YouTube as a major resource for getting the feel of good programming interviews.

1. Ask all questions regarding the given problem

Ex. Integers vs Floats vs Doubles etc...
Ex. AlphaNumeric Strings vs AplhaNumeric + Spaces/Punctuation
Ex .InPlace or using Auxillary data structures
Ex. Memory vs Speed constraints

2. Write Psuedo Code
This is your opportunity to be messy in figuring things out. Make sure you tell the interviewer you will be writing psuedo code so they don't think that's how you write real code. Here you should talk about everything you are thinking, whether it may sound dumb or not. They want to follow your thoughts, so its ok to say "hmm if I iterate over everything twice might work but wait that might not help so much"

Once you have a semi formed way of solving it. At a minimum do the following:

Check Input - Is input NULL, length == 0,etc...Does the input datatype match what they asked for?

Check Step by Step of the algorithm

Here literally write out step by step of the algorithm explicitly. You may find bugs yourself here which scores big points with the interviewer.
Recursion? Where is the stop condition?

Check Output, are you returning an index or a number or .... Make sure it matches the requirements of the function

Check Edge Cases, Linked Lists? What happens with 0 nodes, 1 node, n nodes. Search? What happens when element is not found.

3. Write Real Code
Once your interviewer feels confident your pseudo code is 90% there, they usually nudge you to start writing real code. This does not mean your pseudo code is actually complete. It just means its close enough.

I suggest to write code by translating line by line psuedo code to real code.This should make it alot more straight forward to write code vs fumbling around and modifying it like crazy which gives the impression of "sloppy code" which is programming interview death.

Once you have done that, now go back and again go line by line dissecting your code. This is the point at which you may discover that you need an extra variable to do a swap, need an extra condition in the for loop etc... Again here i suggest taking a break from writing real code but rather go back and modify your pseudo code to improve what you just found out. This shows the interviewer that when you get stuck you take a methodical way of resolving it vs just splashing around until you somehow get it to work. After all lots of interviewers often think how you would be to work with, so having a SW Engineer who just hacks it to work is scary especially when its a challenging problem with a deadline looming over them.

4. Optimize The Code
Once you have a working version the interviewer seems to like. Take some time to actually optimize your code. Do you need that extra loop, extra variable, maybe a reference is better to use vs a pointer. This demonstrates not only do you care about solving the problem but you care about the elegance of the actual code itself. Most interviewers will copy your code same if its a phone interview to show others. So make sure you do a good job of making a final draft.

They also did mention that they couldnt give me an offer because I jumped too quickly into code rather then hashing out a good design before I started coding.

https://github.com/vhf/free-programming-books/blob/master/free-courses-en.md

https://github.com/andreis/interview

Recommended: Talentbuddy [web] [free app]

Coderust (great selection of problems) [$10 app]
Hacker Rank [web]
Interview Cake [web]
HackerEarth [web]
HiredInTech [web]
Project Euler [web]
Google Code Jam practice problems [web]
Top Coder tutorials [web]
Infoarena training path (RO) [web]
LeetCode Online Judge [web]
more – Free Programming Resources [web]
more - Web Resources and Tutorials That Don't Suck [web]

https://www.reddit.com/r/cscareerquestions/comments/1jov24/heres_how_to_prepare_for_tech_interviews/

Data Structures

Go to wikipedia and read the whole page of each of these a few times, then write your own (for real, actually write the code and play with this stuff - that is the most important part)

Array
Linked List
Stack/Queue
Trees (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc. Learn as many as you can)
Heap
Hash Table (this is really important - understand all of the different collision mitigation mechanisms, understand what amortized constant-time means)
Directed/Undirected/Weighted Graphs
Trie (pronounced "tree")
Linked Hash Map (this is very specific, but comes up a LOT in interviews)

You should know the Big-O for insert, delete, lookup, etc. for each of these. Know how the mechanics work. It isn't a good interview questions, but you should be able to code every single one of these. Then, prepare real-world examples of when you'd want to use each of these and explain why it's the best choice. Data Structures come up in technical interviews in two way. The first is in coding questions where you're expected to use the right one at the right time. The second is on a comparison question - not connected to code - "why would you use X over Y in situation Z."

Algorithms

Again, make sure you actually code these for real when practicing. Simply reading code someone else wrote will not cut it. Open up your favorite IDE and start typing. This is critical because often times you actually have a gap in your knowledge, but your scumbag brain convinces you it's ok (this happens without you even realizing it). The only way to find these gaps is by writing code. Know all of the Big-O for this and how it's derived.

You don't have to go crazy here, but review a couple of:

Sorting algorithms (both comparison sorting and non-comparison sorting)
Tree traversals (just memorize all of these inorder, preorder, postorder, level order)
Traversals - Dijkstra's, A*, BFS, DFS (know the difference between DFS and BFS when would you use one over the other and why - hint, is usually matters when you don't have to search the whole space. Also make sure that you can code recursively and using your own stack/queue)
All the prefix-tree searches

Great, you're about 60% done now. Now you need to practice applying this knowledge. Find a source of interview questions (random websites, glassdoor.com, cracking the coding interview, etc.)

Code answers to those questions. I strongly recommend forcing yourself to pretend you're in an interview setting. Most of these questions should be solvable in ~10-15 minutes, some will be more like 20-25. Time yourself. Before you write a single line of code, organize your thoughts and figure out the entire solution, then start coding. The coding part should be boring and straightforward.

In the actual interview, do the same thing. Before you write a single line of code, make sure that you validate with the interviewer that your approach is a good one. Practice practice practice this stuff.

Fill Gaps

This is where you get to be honest with yourself. That long list of things you don't know that you keep telling yourself is ok because the stuff you don't know isn't actually important....well, it is. Even if it isn't, your interviewer might think it is and it's better to have a job than be right. Here's a list off the top of my head that I hear people say isn't important (but you really should know).

Writing code - (I put this here half as a joke. I can't tell you how many people with 15+ years of experience lose their mind when I ask them tow write some code with me. These "architects" do not end up getting jobs. Same goes for managers and other support positions. I know that you're not going to write production code, that's fine - you should be able to write some code, though.)
Bits and Bytes - Yes, you should understand how all that bitshifting stuff works in whatever language you're going to interview with. You should know what big and little endian are. Do a couple practice questions, even simple one. Try something like..."write a method to determine if the bit-wise representation of an integer is a palindrome."
How the internet works. This applies more to companies....yeah....it applies to everything these days. You should know how sockets work, you should know what TCP/IP is. You should know what HTTP actually is. Learn your networking layers and what's responsible for what You don't need to know all of the details of the protocols, but you should know some of them and that they exist. This sounds daunting, it should only take a couple of hours.
Databases. Learn some basic SQL and data modeling if the job you're applying for uses databases.
Learn a bit about testing. Write some code and test it. What's TDD
If you've only ever used Windows....consider using linux for a bit.
Whatever else you can think of. A good mental exercise is to imagine yourself in an interview..."man, I hope they don't ask me about X." Figure out what X is and read about it.

The good news is, the things on this list usually are far easier to learn than you think they will be. These are usually scars from undergrad or gaps from a non-traditional route to CS that sound hard. They're all easier to tackle than you think.

Behavioral

Alright, almost done. Tech interviews aren't all about tech (they mostly are these days, but not completely). You need to come across as someone people want to work with. Smile, be energetic, be excited about the company, know what they do, have ideas about what they could be doing.

You're almost certainly going to encounter some behavioral interview questions. You can prepare for these. I suggest coming up with 3 situations where you were working on a tech project and things went well, and 3 stories for when things didn't go well. Then practice telling the stories, make sure to include some setup information, what was the setting, what was the project, who was working with you, what was your role...then tell the story....then for the positive stories talk about the impact of your work, did you win, save the company money, what? For the negative stories, finish up by talking about what you learned and how you'd approach the problem differently in the future.

Parting Words

Get a good nights sleep and do the best you can. Expect to fail at some of these interviews, that's ok, treat it as a learning experience and recognize that there are both good and bad interviewers. It's possible for a terrific candidate to get thrown to a bunch of shitty interviewers and not end up with a job (happens more than people like to talk about). That isn't to say that you should use this as an excuse to not learn from the experience, but interviewing is a game. Don't try and fight the rules or think it's stupid. It is what it is and that's what's standing between you and the job you want. Learn to play the game and win by practicing :-)

Don't over-share. If you think something is going to make you look bad, it probably will.

Exceptions to this rule: There are a few things that people think are bad which are perfectly fine: * Admitting you don't know something (better than making stuff up) * Asking questions to make sure you understand the problem * Saying that you're a bit nervous and want to take a couple seconds to compose yourself (totally fine, don't be overly dramatic about it, though)

Preparing for a technical interview with programming contests

Usually this part of the interview boils down to writing code on a whiteboard while being thrown an occasional curve ball, like “OK, now can you think of another way to solve the problem that uses a constant amount of memory?”

You’ll learn how to critically analyze your work. Because you don’t get credit for solving a problem until the code you write can generate the correct results for a large input set (and you don’t know what that input set looks like), you’re forced to think about things such as time complexity, memory usage, and nasty corner cases. Importantly, most of this work happens outside the context of a debugger. Debuggers are invaluable tools for figuring out why a given piece of code is buggy, but it’s better if you can write bug-free code in the first place. In an interview situation, candidates who can’t statically analyze their code generally have trouble showing their solution is correct (or figuring out why it’s not).

In general, you’ll become a faster and more confident programmer. This last bit isn’t specific to programming contests – it’s just a natural result of spending a bunch of time practicing the art of programming.

Part of the skill in such contests is learning how to map a previously unseen problem to a known set of techniques, oftentimes with a novel twist. In many ways, programming contests are direct practice for technical interviews.

Topcoder is a good resource for diving right in – they host weekly contests (including a rating system that allows you to track your progress) and keep an archive of past contests that you can work through on your own time.

If you don’t fancy the idea of competing in a live contest, there are also some good online problem archives. The Sphere Online Judge maintains a huge problem set that lets you submit your code to an automated judge, allows you to write your solutions in over 40 different languages, and runs a forum where you can discuss problems with other users.

http://www.1point3acres.com/bbs/thread-184542-1-1.html
1. 时间是稀缺资源。我在上班时基本没有空余时间，假期之前也因为回国一趟基本用完了，只能下班后和周末时，在条件允许的情况下，高效利用一切可以利用的时间。
2. 避免被老板发现。这个很难。我能感觉到我最后集中请假出去面试的时候老板是料到了的，很快也有相应的举动（不过并不是坏事）。对于这点我认为你要有充分思想准备，开弓没有回头箭。
3. 对待手头工作。基于上一条和目前相对严峻的找工形势，我们不能因为刷题跳槽就丢下手头的工作不管，反而应该更认真地对待手头的工作。码农工作很多都是相通的，你不仅会不断有所心得，在面试谈论简历和项目的时候也会更有底气。即使找工失败了，如果在驴子公司这里获得了新成就，例如升职加薪，也不是坏事。
4. 练手公司。受限于时间和精力，不建议安排太多练手公司。我投简历的原则是，只投拿到offer后愿意去的公司(FLAGUT)，另外平时可以多帮驴子公司面试，来积累自己的面试经验。如果安排练手公司，战线会拖长，时间会拖久。时间拖太久会让自己很累，也容易被压力压垮。
5. 面试级别。对于有工作经验的申请者，目标公司往往有更高的期望，你申请entry level的职位反而会比较奇怪。所以，坦然去面senior甚至更高的title吧，即使面不上也有降一级录取的机会。

关于刷题，现在申请我列的这几家公司的SWE职位，刷题不可避免，所以除了偶尔看看系统设计的东西，其它主要是在刷题。我刷下来以及面下来的感受是，刷Leetcode非常有帮助。刷的时候注意总结，体会，面试的时候即使不是原题也很容易找到思路。我的几点tips：
1. 用简单的语言。我基本上是能用Python就用Python，Python过不去OJ就用Java写。原因：省自己的时间。真实面试时，取决于形势，我有时用Python有时用Java
2. 买一个月Leetcode会员并充分利用。公司tag非常有用，对于同类型的公司，可以一起刷；没有任何公司tag的题目不用刷；小众公司tag的题目不用刷
3. 时常在纸上做题。很多公司是要白板写代码的，“写”代码和“敲”代码速度很不一样。在纸上练习的时候，要以no compile error作为目标，如果平时纸上代码写伪代码，那么真实面试的时候代码往往差的不能看，要知道白板面试官也是期待真实代码的。

关于系统设计，我推荐Coursera上的Cloud Computing Concepts课程，从原理上剖析了各种分布式问题为什么这样解决，而不是罗列一堆框架和buzzword，另外很多人也都说过各大公司的技术blog和talk，以及几篇著名paper，时不时看看确实是很有帮助的。

另外讲讲一些我面试过程中的典型案例：

1. 某轮代码，题目是boggle游戏的变种，要求是当场电脑写出代码并运行。面试官在我在白板上给出思路之后一直追问各种细节，比如某个helper方法的输入输出和实现细节，我预计代码量不会小但并没有打断面试官，直到面试官没有问题了才开始写，以至于前面对话花了一大半时间，面试时间结束的时候我刚刚写完代码，完全没有时间debug就结束了。事后发现除了几处typo之外我的代码是bug free的，但这轮feedback是negative，所以遇上这种情况，及时开始写代码是正道，首先自己写代码的速度自己最清楚，更重要的是可以运行的代码胜过千言。
2. 某轮设计，具体题目忘了，面试官一开始给出的条件又像又不像map reduce，疑虑了一会还是没有往那个方向答，最后结束的时候他说了他期待的答案就是map reduce……于是这轮feedback是negative，遇上这种情况，还是要尽量think out loudly，而不是自己蒙头想
3. 某轮代码，第一题是普通的二叉树中序遍历，一时想不开一定要用迭代解，有bug……还修不好，面试官说算了，让我说了下递归怎么做就下一题……好在我迅速调整心态，忘记之前的窘迫，下一题是meeting room变种很快秒了，面试官又出了一道题，也秒了。这轮feedback是positive。所以，对于明显warm up的题目不要浪费时间做fancy的解法。当然，面试中有挫折也要及时调整心态，不要纠结，不要放弃。
4. 某轮设计，题目是tinyURL，老掉牙的题目了，但我之前读到过有些实现采用了base 61甚至base 59及其原因，我就卖给面试官了。面试官当时没有什么表示，但这轮feedback是positive，所以平时多积累，说不定什么时候就用得上，能够答出面试官不知道的点会是big plus
5. 某轮聊天，面试官随心所欲地问我简历上的东西。我简历上有语音识别的项目经历但着墨不多，面试官从这个项目开始问，等我提到HMM和Viterbi算法，面试官就开始追问这两个是什么东西，算法怎么实现……现想……好在是做过的，虽然有点忘记，但总体也答出来了。这轮的feedback我不知道，聊天面试主观性和随意性很大。我想主要还是对自己简历上的东西真正熟悉。
6. 某轮代码，题目是Leetcode copy linked list with random pointer原题，刷的时候没有看leetcode讨论，只会hashmap的解法，面试官要O(1)空间解法，想不出，按hashmap做了，面试官不依不饶要O(1)，最终还是没想出。于是这轮feedback是weak negative，所以不要满足于能过OJ的解法，也要去leetcode讨论区看看别人的解法。

至于大家常常遇到的某族黑问题，我也遇到过，有一轮题目完美解决，但是某族面试官说我有bug，纠结半天发现是面试官不知道Python中list[-1]的用法，我解释了，他表示懂了，以为皆大欢喜了，结果feedback是strong negative，无语了。不过，我也遇到过该族面试官给我strong positive的时候（recruiter给我念了feedback，真心各种溢美之词，我都不好意思），遇到的其他该族面试官也没有什么可以吐槽的地方。我也遇到过不是很给力的同胞面试官（最大的问题是，彼此英语都不怎么的），所以我认为这个问题也不必过于看重，不要根据族裔预设立场，正常对待每一轮面试。也不要因为同胞面试官没有帮你，或者没有明显帮你，就嚷嚷着人肉，诅咒，同胞面试官本来就很少了。至于那一轮明显黑我的，我差评＋投诉了recruiter，即使没有什么卵用，至少要表明一种态度。

至于目前的招聘形势，我感觉活的比较好的公司还都是在招的，但infra背景的感觉要求会高于product或者mobile背景的。New Grad的形势确实不好，连很多人鄙视的Oracle也难了很多。在这样的形势下，我想也只能尽自己所能，充分利用时间，多学习多练习。也希望我的分享能够起到一些帮助作用。

http://www.ugrad.cs.ubc.ca/~cs490/sec202/notes.html

https://www.facebook.com/hackercup

https://www.evernote.com/shard/s576/sh/7e58b450-1abe-43a8-bf82-fbf07f1db13c/049802174415b418a2e65f75%20...

Algorithms

https://www.hackerrank.com/domains
https://oj.leetcode.com/problemset/algorithms/ LeetCode至少要刷三遍，付费部分的题建议花点钱看一下，舍不得孩子套不着狼
http://lintcode.com/
http://www.ninechapter.com/solutions/
http://www.geeksforgeeks.org/about/interview-corner/
TopCoder Algorithm Tutorial: http://help.topcoder.com/data-science/competing-in-algorithm-challenges/algorithm-tutorials/ 其中几何算法的教程要仔细看，Google特爱出几何题
CC150: Cracking the Code Interview: http://www.valleytalk.org/wp-content/uploads/2012/10/CrackCode.pdf

OO Design

http://blog.csdn.net/longyulu/article/details/9159589

System Design

Here are some articles about system design related topics.

Hot Questions and Reference:

There are some good references for each question. The references here are slides and articles.

Design a CDN network
Reference:

Globally Distributed Content Delivery.

Design a Google document system

Reference:

Design a random ID generation system

Reference:

Design a key-value database

Reference:

Introduction to Redis.

Design the Facebook news seed function

Reference:

Design the Facebook timeline function

Reference:

Design a function to return the top k requests during past time interval

Reference:

Design an online multiplayer card game

Reference:

Design a graph search function

Reference:

Design a picture sharing system

Reference:

Design a search engine

Reference:

Design a recommendition system

Reference:

Design a tinyurl system

Reference:

Design a garbage collection system

Reference:

Baby's First Garbage Collector.

Design a scalable web crawling system

Reference:

Design and Implementation of a High-Performance Distributed Web Crawler

Design the Facebook chat function

Reference:

Design a trending topic system

Reference:

Design a cache system

Reference:

Introduction to Memcached.

Wednesday, December 2, 2015

Interview Preparation Misc

Labels

Popular Posts