▲ 414 points
back
279 comments
(sorry for sidetracking the excellent piece but...)
When I examine the ~13,000 hours I've spent programming I find it hilarious that interviews should centre around algorithmic problems. I've been guilty of it myself and failing FizzBuzz is definitely a true negative but it's so little of a true positive it's not even funny.
What I would really love to know about you as a candidate is:
- do you know how to actually name functions and variables well (unbelievably important)
- do you know your chosen languages and frameworks well enough to avoid cack-handedly reinventing them on paid time
- do you understand how to code an application that someone else (possibly just you) will quickly understand on coming to it cold in 18 months time
- do you understand the trade-offs between features and maintenance, the technical debt that features, designs and toys incur and when to invest in them and when to avoid them
- are you diligent and careful and do you check and re-check your code or just chuck it in the mix for other people to fix
- do you actually do real work for at least four hours each day
- do you take the time to write up the things you've done and share decisions and architecture with the rest of the team
- does your addition to the team on average make your team mates become better or worse coders
- do you understand the exquisite balance between too much testing and too little
In 13,000 hours I have had to wrestle with the consequences of O(n) complexity or binary tree search algorithms approximately NO TIMES.
I did not mean to sidetrack Rob's excellent, excellent piece on finding a job in Silicon Valley however I did want to take the opportunity to state the things that I have empirically found as a professional developer to actually matter.
Most software isn't hard to invent; all software is hard to maintain. For the overwhelming majority of software development, being organised is more important than being clever.
What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome person on a team at your last job and just goof off all day and now put everything that guy did on your resume?
I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can you work with this linked list on a white board" simple programming problems, but right now I don't know a better way. So I don't consider programming puzzles meaningless on the assumption that the guy who slacked off won't do well with them while the guy who paid attention and loves to program will know and demonstrate a thing or two.
I know with some potential hires I can review a github repository, but that has similar problems. I've handed an interviewee code from his own github repo where he had fixed a defect and asked him to point out the defect he fixed on the page, and he couldn't find it. Does he just have a bad memory, or is he lying about that being his code? How can I tell?
If you work at Google or Facebook or any other of the tech giants, you need to know your algorithm-type questions.
For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.
For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times.
Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it matters which area / programming environment are we talking about in general.
Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability.
And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well.
But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point.
Or that your linear traversal should dramatically improve if you could code and use a hash table instead.
Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.
Not a software engineer here. I've still tackled O(n) in real work, while writing ancillary scripts. I'm glad I learned it.
(think parsing and searching monster flat text databases from disk)
I think most interviews don't focus enough on systems. I expect every software engineer to know:
- How virtual memory works
- How threads work
- How TCP works
- How ports work
- How ethernet works
- How DNS works
- How a web server works.
And so on. A lot of these things are more important than theory (but I think theory is important, too!).
I am now fairly involved in my company's interview process and Im constantly surprised that none of the resumes I get mention anything about the applicants character or professional demeanor.
For all the fear of being "culturally unfit" for a company, highlighting what kind of role you play and how you interact with your coworkers is fundamental.
Are you diligent and consistent with your work? Are you the kind of person that bursts through work in a flash? Do you prefer to work alone or in a team? How do you feel working with people below your position or above it? etc.
These questions have the issue, however, that you rarely ask them in an interview. You just gauge them from a conversation, that really doesnt speak to any of them. If someone is a complete technical ace, but is silent 100% of the interview besides technical points, i still get red flags. A co-worker is not a cog in a machine, its someone you will be spending 40 + hours a week with.
I disagree with hard theory NOT being important. Im a drop-out but i still went through all the algorithms and data structures classes out there and they gave me knowledge to communicate about hard problems, even though Im not the one solving them (we got some phds for that). And above all, at least in our case currently, several of the algorithm questions we do are actual problems we had in our product. In particular i wouldnt even call O(n) "hard". Its maybe the single most important performance computer science knowledge you need, and its not hard to calculate for the vast majority of applications.
> In 13,000 hours I have had to wrestle with the consequences of O(n) complexity
That is what I would expect someone who has had to wrestle with big-O problems but didn't recognize them to say. I honestly don't know what you're working on if its actually true. I had a time complexity issue just this week. On front-end code, no less. I probably work on an issue involving time complexity once a month, if not more often.
"In 13,000 hours I have had to wrestle with the consequences of O(n) complexity"
then maybe you're not solving very challenging problems.
On your first bullet, naming functions and variables, I think that is important, sure but I think, and this may be blasphemy, that it is a little overblown. Many would make that seem like the most important thing but I think you can be a competent programmer and a valuable without being great at naming. For one, it is very subjective. You may think 10 compound words resulting in 100 character variable name, ala Java or .NET, makes perfect sense, while others think it is ridiculous. Also, I'm not sure I think "technical debt" is a real thing. If you have not dealt with complexity or algorithms then you may not be doing the kind of programming many other people are doing. Also, as a programmer, if you don't know basic algorithms and data structures, for me all the knowledge of what is hip is not a great substitute. But I can agree with a lot of what you're saying here.
I don't think this debate is as complicated. There are a certain set of things you can do with the knowledge outlined above.
And there is a certain set of things that you can do with semi-advanced or advanced algorithmic knowledge, knowing how the cache works, knowing how distributed algorithms work and so on.
Some companies don't need the latter. Some companies do. The latter companies do want to hire someone who can do both, and not be stuck to a special set of tasks that they can do i.e. they want a generalist who can be assigned to any project of varying complexity.
Personally speaking, many of the tasks I do don't involve the algorithmic skill set. But some do - now without that skill set would I just outsource it to the "brighter" folks in my company or would the company just prefer that everyone who they hire know that stuff ?
How is your H1B still valid after you lost(?) your job and left the country? H1B is tied to an employer and a specific job, so I don't know how it's still active. Are you sure that your H1B hasn't expired yet? If you try to enter on an expired H1B, you might get banned from entering for 10 years (this happened to my friend 6 months ago) so make sure your immigration status is rock solid.
My age, work experience and expertise are similar to the OP's. I just interviewed with Google, FB and Amazon, and found myself nodding my head at several points in the article.
Something I learned after the whole process was that people apparently take a month or two to prepare intensively and specifically for interviews with these 3 companies. Luckily I came out of the ordeal with an offer, but I wish I had known that tidbit before.
I never really know what to do during negotiation time. During the first interview, I'm usually asked how much. I'm told that I should always try to push it back for the other person to make the first offer. However in matter how hard I try, they demand that I make the first offer. I don't want to aim too high or too low in fear that I'd lose out on the opportunity.
Starry eye programmers from outside the Bay Area should be forced to watch the Office Space movie for an idea of what Silicon Valley is really like: a gindingly dull suburb.
I'm currently performing the same job search but as a future new graduate from a Computer Engineering program in Canada.
So far the biggest parallel with your experience is gaining the confidence to even begin applying for jobs. I came to the conclusion that I have almost nothing to lose by applying for jobs and it's really difficult to burn bridges by just sending in a resume or a quick email saying I'm interested in your company.
Some of the interviews so far have been excellent and left me really excited about following up with a take-home coding exercise. On the other hand some have left a really bad taste in my mouth. I found it surprising how much I can get a feel for the type of person a CEO/CTO is over the phone. One of my biggest complaints is when interviewers want me to do spec work[1] for their app. That's a big red flag for me.
My biggest successes so far have come from downloading/signing up for the product or service and spending some time using it. So far interviewers have really enjoyed that and it has led into great discussions about the product and how I would improve it. Furthermore, in remote coding interviews, being honest and saying, "I don't know, could you please show me." is really appreciated and demonstrates character.
As someone who has both looked for engineering jobs and also staffed engineers on my team in silicon valley, I'd suggest people to be a little less shallow about their employers.
Yes, you can work somewhere with free lunches/perks/nerf gun wars. However, you should always ask yourself 'Will working here make me a better person?'.
This could mean providing more financial stability or a huge boost to your resume via gaining expertise in a sought-after area. I hate the argument that 'If I work at Google, I'll be more marketable to future employers'. No...as someone who's hiring, I don't care if you were some guy/girl at google. If you worked on BigTable, awesome you're probably well-qualified for any job in that area and will be paid as much as you want. If you're employee number 70,001 and worked on designing icons for 'Google Trends', you shouldn't expect a huge payout at your next job for being 'Ex-Googler'
"sum of the numbers from 1 to N is O(N^2)"
Maybe I'm misunderstanding you, but no it isn't. it's O(N) if you have to traverse a list of numbers it's actually constant time if the numbers are sequential.
I'm not a programmer, but...I would want to work with this programmer in a heart beat. Smart, respectful, strong boundaries but not a jerk. A lot to learn from him for everyone on Hacker News, not just the devs.
Congrats to him on the new job and the H1B visa and to Stripe for hiring him. He seems to really deserve it.
> “Design the infrastructure for a link-shortener.”
I'm wondering how to answer that?
* Get a short and memorizable url.
* When you enter an URL hash it, put it in a hash table and use the hash for the link.
> “If I type https://google.com into my browser and press enter, what happens?”
How would you guys answer this one? I'm not sure I've enough knowledge to do that. I'd say:
* first TLS handshake thanks to RSA to share a key
* then a GET
* then the server sends a cache version of Google according to location/cookies/etc...
* then the html gets displayed in the client's browser
I recently went through the same process and didn't have quite the same luck.
Background: London. Comp Sci. from top 10 worldwide college. 2 years C++, Python, iOS experience in well known company on high profile project. Internship at start up with VC funding before that. Github profile with open-source projects, own projects etc. Started blog etc...basically everything that is recommended.
Studied for 5 months (up to and including interview time) and did projects whenever I could. Applied to 40 companies in San Francisco. Got 12 straight no thank you, 2 interviews and the rest ignored.
Started process on Jan 1st 2014. Had interviews at Yahoo! and Palantir. Former, pulled the plug when the H1-B deadline was looming and they felt it wouldn't be done in time. They suggested a workaround to work out of London and try next year and then they pulled that idea a few days later when they didn't have the team in place to support it. The latter, I did 1 telephone interview which went fine, then on-site where I was quizzed for 1 hour in functional programming (never done any before and job is in Java) and had to code not on paper, or a whiteboard, but the glass conference wall...
Will have to wait another year.
> If a company is currently worth $10m, options for 0.1% are worth $10k.
This isn't really accurate. The company is not giving you 0.1% of the company. It is giving you the option to buy the gain on 0.1% of the company above that value at the time you start. If the company never gains in value, your options are not worth anything.
"Flying out to interview with a single company is easy - they pay for the flights and hotel and you use them. Interviewing with 7 companies made for a surprisingly stressful round of negotiation before I’d even arrived, as I tried to spread the cost according to who could most afford it and who was getting the most time with me."
When I last was searching for an out-of-state (albeit not California) job, every company was adamant about arranging all the flight arrangements. It was very clear they did not want me to interview at other companies during the time. Even after I agreed to pay my own way, they still insisted on paying and have me fly out immediately after the interview. The stress of multiple flights during my short interview period definitely affected my performance.
I built an app for tracking job applications... amazing how many people just do this on a spreadsheet (as per point 2.3 of the post), which is fine, but I needed an excuse to build something, so
sigh Unless your nomenclature is all screwed up, and you're confusing arrays and lists, finding an element in a sorted list takes O(N) time -- binary search doesn't work on lists.
I do a lot of interviewing (at my company). Here's other common misconceptions lots of candidates have:
* Quicksort is O(N^2) -- don't make that mistake.
* There are plenty of "faster than O(NlogN) sorting algorithms, but they're all special cases. (Radix, Merge on multiple processors, etc.)
* Hashing is not a panacea. Collisions are always worth mentioning.
"Some places like Matasano, Stripe, Github and I’m sure many others are aware of this and are equally aware that it has the potential to harm their company a great deal." I actually had the pleasure interviewing with Matasano. I thought their process was fun and really enlightening in regards to what they do. Everyone I met during the process were really cool (and extremely smart).
I actually have an interview with Google in a week or so, and I'm absolutely terrified. After some reflection, I realized that I'm not afraid of not getting the job - I like my current job and wouldn't mind staying. I'm fundamentally afraid of failure - of being unable to do well on the problems and having the interviewers think I'm stupid. It's so silly, because I'll likely never see these people again, and I should be confident enough in myself and my abilities to not let their opinions affect me at all, but there it is. What if I can't make heads or tails of the weird binary search problem they give me? What if I get confused (I ALWAYS get confused) trying to manipulate a linked list? What if I get sent home after the first one or two interviewers? What if this reflects poorly on the Googler who recommended me?
I feel like a coward for being afraid of this stuff.
Anyways, I just wanted to get that off my chest.
I haven't noticed anyone expressing their thanks for sharing helpful information on getting a job in SF.
Your post is directly applicable to my current situation, and has reassured that I am not "average outsider" and should continue pushing my dreams, despite of being recent graduate in UK.
Huge thanks for sharing your experience and giving advices to obstacles :)
>> You want to start negotiating at your strongest point - when they have said “we love you, let’s make a deal.”
One simple practice is at the end of the interview when you get the, "So what's the salary range you're looking at?" question, I always give them about 5-10K higher than what I'm currently making with the caveat, "But I'm always open to negotiating." which keeps the door open for the company/agency to get creative with incentives or other valuable options to bring you on.
You shouldn't feel bad about asking for extra stuff. 95% of the developers companies are hiring are just taking what they offer them. If you negotiate, companies are more likely to give you some additional extras. You just have to ask for them.
You applied to 25 companies and got responses from 17? That seems like an extraordinarily high response rate. Your process sounds pretty normal, but my understanding is that most people who follow a similar process get a much lower response rate. Why do you think this is?
I like the negotiation comments. It is always ok to say, "If you love me, and I love the firm, I'm sure we'll find a way to make a deal."
The best way to have leverage to have another opportunity in hand. Then you can say, "I will be fully transparent, and won't play any games with you, but I do want you know I'm talking to someone else too." That lets them know that you are valued. You just have to be polite, and not turn it into a multi-stage bidding war. But it does give you the ability to say, "I love your firm. I don't want to start a 2 week cycle of bidding, but if you could at least close 2/3 of the gap in offers, I won't have to worry about paying rent."
Not to take away from this post but I wanted to share a little bit about my own job search. Hopefully engineers who regularly interview candidates have some interesting feedback to share. There was a post I actually just hearted on Secret this morning where someone equated "hard algorithm" questions to "hazing." That may be a little dramatic sounding, but I do think there is some truth to that.
So much of the early 2000s tech interviews were full of brain teasers that either through sheer luck of the candidate or someone who read the popular book "How would you move Mt. Fuji?" would ever have a shot at solving them. Microsoft pioneered it apparently and Google took it to the next level. They even went so far as to post them on billboards for anyone "clever" enough to figure them out.
At some point they went out of favor and the new favorites became these multi-step dynamic programming questions, or quad-trie/kd-tree disguised problems. The unfortunate truth is, if you want to get a job in the valley beyond your first out of school job, you're going to need to study and refresh your brain on those last chapter algorithms. Make sure to practice doing them recursively as well because with 45-60 min interviews you won't have time to do it iteratively. Just like the OP mentioned too, it also couldn't hurt to practice writing code on paper in front of a friend.
The biggest thing I found writing code on a white-board vs. a laptop is that you lose all the things that make coding in an editor so much faster. You can't just erase a line if you need to insert something above it. You need to be extremely thoughtful of your order of operations from line #1. Usually what I found worked for me was writing a checklist of how to solve the problem in English, so as not to confuse the interviewer that I'm writing code/pseudocode. Then I rearrange the steps until I get a solution that works. From there I can quickly write out the actual code that then becomes the easiest part of the interview.
So the BIGGEST tip I can add when doing white-board coding, write as polished as you can. Interviewers always seem to proclaim they won't judge your chicken scratch, but I've never been in a feedback session where someone joked "his handwriting was so messy, but I was very impressed." In fact I've always heard the opposite, "wow, they wrote crap all over the place, even though they figured it out it was very unorganized, so I dunno, it's a maaayybe from me."
Also, when asked one of these questions, DO NOT take your time trying to be clever upfront. Get the worst case on the board, 1) it will give you and the interviewer a chance to to talk about it and 2) they will want to ask you how to optimize it anyway.
If you're Mexican/Canadian, a TN Visa might be a better option than H1B since there's no annual limit.
I'm currently in Silicon Valley from Canada on a 2.5 day trip, with 4 interviews in that timeframe, and it's quite fun yet intense.
I'd also say that if you're a self-taught programmer (I'm an EE), it's worthwhile to read a book like Intro to Algorithms[1] cover to cover before you start doing technical interviews. There are just too many CS101 concepts that you'll never run into even after years of programming.
[1]: http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme...
Why is summing a list of numbers 1 to N O(N^2) instead of O(N), don't you just iterate through the set of numbers once?
EDIT: Nevermind, I think it means the value of the sum is on the order of n^2
> the fact that Hashes have O(1) lookup time is often a great way to speed up an algorithm.
In practice I have learned that being CPU bound will turn things around faster than paging and thus for things that involve a sufficiently high number for n I prefer to avoid hashes and O(1) "speed ups." The less I store in memory the better, especially on servers that handle lots of requests simultaneously, at least for servers that aren't meant to be a memory store like memcache or redis.
One thing that I always see in these threads is how these interviews are not really a good indicator. I work for a company that does these interviews, and most of us acknowledge that the interviews result in sizable false negatives, but the ones that do come through the process are usually very competent ones.
Also, complexity analysis/algorithm questions that are asked in the interview setting is not rocket science...
What this doesnt say is whether the salary was on par with BayArea market or London Market.
He did go through the Developer Auction/Hired so that gave him some idea of what companies offer.
I remember when Buffer "open sourced" their salaries and revealed that they were below the market rates in the Bay area(for Buffer's bay area employees).
Thanks for the great article and congrats on your Stripe offer. Great company to work for.
Despite the great story of your general interview process, I am quite interested in the hiring process of Stripe. What is its interview like? What do you think probably make you got the offer?
The article mentions to practice code-oriented challenges. Are there are good resources out there to help with this?
Thanks for sharing. Helpful reading.
"Funemployment". Love it.
it is really a good lesson to learn.
"""Far too many offers come through as:
$Xk/year 10,000 options
This is literally equivalent to:
$Xk/year $100bn in monopoly money and bingly bongly bangly boo"""
It is incredibly dishonest and disrespectful when startups job offers hide information about the value of their equity. I know some investors are encouraging this behavior, but please have the courage to stand up to them. Employees have a right to know the fair market value of the compensation they will receive for trading away their time and labor.
Getting a job in Silicon Valley, as an outsider, isn't hard. Getting a good job is hard. Many offers will come through at a lower level just because, whatever you did, you didn't do it in the Valley. That's Cali arrogance for ya.
Hedge fund interviews are a lot more intense and technically difficult (and you feel good when you pass) but don't come with the VC-fueled, youthful arrogance of a proper Valley company. Hedge funds also don't try to lowball you with insulting junior positions because you're not from California or you don't know the five 3-year-old technologies in their stack in detail. If you pass their interviews, the hedgies take you seriously. Most of these VC-funded companies, on the other hand, don't really respect most of the people they hire. They sell aggressively, but the options offers turn out to be ridiculous (sub 0.1%), relocation pay is nonexistent, and, if you're not a Valley insider, the positions are often pretty terrible, as you discover if you ask the right questions.
If you can deal with arrogance, you can probably get a good job in the Valley after enough time. But you'll have plenty of experiences that leave you thinking, "How is this company alive?"
This may very well have been an excellent piece. But, the author lost me no later than 2 sentences in with his immature and sexist "nerdy girl" analogy. I just didn't even bother to read the rest. Working in silicon valley myself, I already waste enough time on people who think this kind of immature male mindset is okay.