(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.
I say that if you can organize well a messy closet or kitchen you have a basic skill to be a good ok programmer.
Not necessarily means that all good programmers are superb closet organizers, but they should be able to face clutter and leave things much better than how they found them.
I don't think those are the same skills at all. Organizing a program is about merging the things that are the same and separating the things that are different. Organizing a closet is about putting things in categories, but 20 identical shoes need just as much space as 20 different shoes.
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?
One way to approach this is to say something like: "I have a selection of (simplified) problems we've faced recently. They're representative of the sorts of issues you would be taking care of if you join our team. Let me walk you through them one at a time and we can discuss. We'll start just by verbally going over them, then either move to a whiteboard or to a workstation to dig into them a little deeper.
The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done."
Imho, there are only three things you really need to know about the candidate:
1) Will this person fit into the current team with the minimum of fuss?
2) Can this person do the job professionally and in a timely way?
3) Is hiring this person a financial risk we're willing to take?
I'll addressing two things from your post 1) is there a better way and 2) show me the defect that you fixed.
1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company.
What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz.
2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.
You need people who know how to find the answer to such questions. I would much rather hire a Java developer who knows how to implement equals() and hashCode() correctly, with a unit test to validate it, and knows that if they have any questions on say searching and sorting that they should reach for their copy of Knuth v3 first before writing a single line of code. That to me is a much more valuable employee than one who can spout off how a Linked List works.
90% of programming is problem solving. Knowing how to solve a problem is much more useful than being able to spout out the right answer.
(To echo the first poster. Number of times in 20 years outside of a job interview I've had to implement a Linked List: 0)
IMHO Google, Facebook et al are largely the cause of the current recruiting mess because companies who don't understand what makes a good employee for their company have been cargo-culting Google, Facebook et al in the hope that will "make it rain" for them.
> You need people who know how to find the answer to such questions.
You can't look for an answer if you don't know what question to ask.
This has to do with that whole "conscious competence learning matrix" stuff, more entertainingly described by Steve Schwartz as "shit you know, shit you know you don't know and shit you don't know you don't know" [1].
The purpose of interview questions about algorithms and data structures is to see whether the candidate has the basic understanding of how the most fundamental data structures work and when to use them; whether they understand the concept of complexity and why it matters.
If you think these things don't matter, you're taking them too literally. Knowing when to use a linked list, when to use a binary search tree and when to use a hash map might be the difference between your software being able to scale or not.
Asking algorithm trivia questions will tell you nothing about whether or not the candidate can apply that knowledge in the real world.
A large part of what I do involves coming into teams that are struggling with delivery, and helping them get back onto the path of productivity.
More than once, I have had developers that could (and have) leave and easily pass a Google interview. They knew more about computer science than I probably ever will.
And in many of these cases, the code they wrote was actively harmful. Unreadable, tangled messes, that nobody else on the team could unwind.
Knowing how and when to use monads, or bloom filters, or any number of other fun tools separates the supermen from the mere humans.
But before you need to care about that, there are more fundamental concepts that matter. Like being able to write readable code that conveys intent, knowing how to write tests that are flexible yet specific, and so on.
Who said anything about trivia? Asking trivia is pointless and any company dumb and/or lazy enough to base their interviews on trivia deserves the bad hires.
While we're at it, who said anything about monads and bloom filters? The former aren't really data structures or algorithms, the latter would hardly qualify as "the most fundamental data structures".
Also, I don't remember saying anything about the irrelevance of writing readable code and flexible-yet-specific tests.
In short, you're certainly disagreeing, but apparently not with me.
As someone else who has also been in the industry for quite a while, it used to be fairly common for me to implement linked lists back when I was programming primarily in C. But lately, yeah, it has been mostly abstracted away, even in languages where doing pointer operations is useful or allowed.
As far as companies attempting to emulate Google or Facebook when it comes to interviewing, this sort of thing is even older than either of those companies -- in the mid-90s it was common to attempt your own spin on the "Microsoft interview".
I totally agree with the basic point, though... for all of the supposed rational thinking that goes on in tech, hiring people is mostly cargo cult and voodoo magic.
I don't think interviewing candidates based on basic knowledge of CS is cargo-culting Google and Facebook. I think this predates those two companies. Also, someone that implements hashCode() correctly and can't spout off how a linked list works, is a problem for me. I guess it is subjective.
Your last paragraph really resonated with me. I personally could not emphasis my feelings and opinion towards "companies who don't understands what makes a good employee for their company" by any means.
I'm currently a CS student and I do find many of the startups locally do involve loads of problem solving on the job, which is beneficial from general algorithm knowledge. Although I believe it's more so the ability to understand the concepts as opposed to spouting knowledge for any specific abstract data type or algorithm.
But by any means all companies are not similar, and outside of the purpose of prodding for problem solving aptness it is definitely not the best topic to discuss in an interview to find the /right/ employee for many of the companies of which do ask it.
Why? Do Google or Facebook engineers live in a magical world in which they need to know off the top of their heads the big-O complexity of every possible sort function ever mentioned in an academic paper?
I see this argument used time and time again, but it makes no sense to me. Surely they can just search for it when they need it too :)
This is needed more for the people inside than outside. I used to be at a famous hedge fund, and then at banks like Goldman Sachs where this attitude was common : "We hire selectively; only 1 in 750 applications is given an offer". Now how does that make you feel to be an employee? It's an amazing feeling, isn't it? To know you're special, that you're a diamond in the dust. It makes it easier for the employer to then demand you to create great things, eh? You're going to pressurize yourself to show them you're worth it.
But in reality, what happened, at least in my experience, is that the top talent almost always left because a) they never really got to use that Longest Common Subsequence algorithm that they quizzed on, so the actual daily work-experience was sappy compared to the hype or b) it was just one more conquest anyway; off to better / greater things that challenged their abilities
The real gems, in my not-so-objective perspective, were the in-betweeners : people who may not be brilliant, but those who worked hard enough to pass the interview and were really thankful to have a great employer. They stuck around and worked sincerely and were an asset to the firm in every way possible.
IMHO, a firm needs 90% ordinary folks, and only a handful of brilliant crazy geniuses.
It's not about knowing the complexity of every possible sort function. It's about having a good base to stand on, a nicely sized toolbox.
If you're working on a solution to an actual problem, it's a pretty damn good to have an idea about the complexity of it. You don't need to be an expert, but developing some kind of intuition for it is very helpful.
If your attitude towards these things is "I'll just Google it" then you're not going to be quite as useful when it comes to discussions. Your toolbox needs to be bigger than that.
Again, what's the point of having a tool you never use?
I have had to implement a sort once in 10 years of professional programming, it was in IE6's painfully slow js to fix a slow table sort. More than most. I didn't do a CS degree, the people around me with CS degrees didn't know the answer.
I googled it.
After the 15 minutes it took to find and implement it I mentioned it to one of the CS people, he promptly reeled off the definition to me, but couldn't see how it solved the problem.
Give me someone who never cuts and pastes over someone who know algos any day.
It's not about "sorting" or any particular algorithm, it's about whether you're actually considering the costs and tradeoffs of the code you're writing (which is actually a big part of software engineering), and are equipped to handle those. Now, one cost is execution time, another is memory usage, another is development time, another is maintenance effort and so on. These costs are spread across different domains, but it's important that a programmer considers them.
It's really not a big part (apart from the rare times when it is).
Firstly you're almost always wrong about what you think will be slow. Add to that it's rare you actually know how a programm will really be used.
Secondly most programs never get stressed so it was a complete waste of time.
Third, you just made the program complex for no actual good reason, just inexperience and flawed logic.
So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.
A for each. That's what you'll use 80% of the time, a for 20% and your algos 0%, for all intents and purposes.
> Firstly you're almost always wrong about what you think will be slow. Add to that it's rare you actually know how a programm will really be used.
If you don't have a good idea of what is likely to be slow, we have a problem. It's usually I/O, especially synchronous network I/O.
During initial development, maybe you don't know how a program will be used, but maintenance is usually a bigger phase than initial development, so you should have some idea of how things are used.
> Secondly most programs never get stressed so it was a complete waste of time.
What are you working on? Everything I've worked on that has users could go faster. It doesn't take that much complexity to get something that takes 100 ms; and making that take 50 ms instead is an easily perceptible difference.
> So all that knowledge, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.
You could fill volumes about the cock ups and bad code caused by completely garbage performance because people didn't stop to think about how to do things right. Simple things like reducing the number of round trips to the database, or avoiding calculations until you know you need them could be called premature optimizations or just doing the job right. Having knowledge of algorithms (and knowing what algorithms are likely to underly the abstraction layers you're using) helps you avoid writing code that will blow up.
Reducing the round trips to the DB or doing calculations when you need them need no knowledge AT ALL of algos.
Saying it's "I/O" is so abstract and ultimately useless. A simple SQL query could hold a dark secret of a missing index on a table with a billion rows. Yes, that's technically I/O, but for today's programming that's so obtusely abstract it's pointless calling it that. It's a couple of lines of code that all the algo knowledge in the world won't have stopped the problem happening.
It's simply common sense. This is what we're trying to tell you. This is what we're trying to explain to you. Performance problems are almost always unintended consequences rather than "I'll suck it and see". Knowing how to implement the sort yourself won't save you, you have to spot the problem first, which is the hard part.
Basic multiplication is not algos. Knowing that a 100 loops of a thousand loops of a 1ms method is bad doesn't require magical knowledge. Algorithms was always a smoke and mirror trick, the ones you need are usually already in your language written much better than you could and the rest simply hides the truth that performance is mainly down to unexpected I/O bottlenecks usually buried under many layers of abstraction (SQL) or the occasional loop within a loop hidden in a long call stack.
Depending upon what sort of industry and scale you write code for, very often, it is a HUGE part.
I accept the point that over optimizing is the root of all evil and the rest of the philosophy along those lines. But knowing algorithms and data structures inside out, because where and when you have to choose what - i doubt one can be called a programmer without all that.
And i would say again, i am yet to find some body renowned, who has made their mark as a programmer, and doesn't regard all of this stuff high enough.
Having said all that, if you work in a high level language and develop client facing / application layer desktop/web related stuff - and not involving too much scaling, you won't need these things most of the times. But if not, you can't live with out these.
Lastly, since college and probably since learning to program, the best of the breed usually were the guys who went on to acm and top coder kinda stuff. It is true that building products is not synonymous, but it definitely plays an undeniable part albeit i must agree that it is slightly over valued, nothing else.
High level language? I haven't heard that kind of condescension in years. Whatever you're working on isn't as hard as you think it is. Most experienced programmers could probably do it as well as you in a couple of months.
And who is renowned in this industry? Game programmers. Not Sass, enterprise or consumer web programmers, who make up the vast majority of working programmers. No, one of the tiny subsets of programmers who do need algos.
You're stuck in your own bubble thinking it's bigger than it is (and seemingly thinking it's "proper" programming). So you're wrong because your premise is flawed. 95% of programmers do "high level language and develop client facing / application layer desktop/web related stuff". Simply open a job website and search for "developer". Add them up by SASS/Enterprise/Consumer Web and then everything else. The first category will be much bigger, 20-30 times bigger.
I never tried stating it was hard, or making it look like it is main stream. I just said that depending upon the domain you work in, Algorithms and data structures might be more important and you might encounter them more often then in web or desktop, than an average programmer does.
So the whole line of reasoning is irrational to me. Never tried saying systems programming is more main stream then web or desktop or enterprise.
Talking about renowned, Yes people who have written kernels, operating systems, network stacks / protocols - there is huge list of renowned ones. Do you want me to spell the names out starting with Torvalds or Stallman?
it seems to me that people with 10+ years of experience have more empirical evidence what is actually needed/useful.
Your comment and other similar ones sound to me as textbook material which is abstract and correct in principle but not exactly how it is when you spend some time in industry.
I have my own empirical evidence as an user: a lot of software I use is slow or uses too much memory, or has memory leaks. As a programmer, I keep wondering if those could have been averted if the programmers working on that code would have used better/more efficient algorithms, instead of just going with the simplest solution.
No. It's not. It simply inexperienced programmers. I bet they even have CS or EE degrees.
One of the biggest culprits of truely awful programs are graphics card makers. I bet they all know algos, the problem is that they think they know how to program when they're little more than amateurs or hobbyists.
I can do time complexity etc. I know about compilers, trees, graphs & other shit data structures and I can read academic papers on any new shit with a comfortable head. I can learn any new imperative, oop or functional language in a week.
As evidenced by countless anecdotes and accounts by people who used to work at these companies, they don't. It's not about needing that knowledge, it's about removing those people from the employee pool available to competitor companies and the entrepreneur class.
Agreed. I think there's a tinge of arrogance to the claim that Google/FB/what have you need The Best(tm) while everyone else does not.
The reality is that there are some jobs (a small minority) at these companies that require incredibly deep algorithmic knowledge - they really do do some complicated things.
But the majority of jobs at TwitGooFace are your run of the mill programming jobs, where the requirement and the reality don't call for anyone at that level, and hiring someone at that level is just going to make them bored. Indeed, the vast majority of people I know at these companies aren't algorithmic encyclopedia, they're just solidly competent engineers.
Having worked at a "AAA" tech giant and many more places across the country, I'm happy to report that for the most part there's nothing exceptional about Silicon Valley jobs and what they require. For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge.
The thing is, that 0.1% would probably be better off just looking for a Math PhD. I suspect it is much easier to teach a mathematician C (Or Python/Haskell/OCaml/Java) than a programmer real math.
Math guy here, spent the last year writing high-performance ODE integrators that run on graphics cards. No formal background in CS at all. Hiring maths people to write performative algorithms is more common than not.
The problem is that Math PhDs tend to be arrogant and think that programming is for monkeys and they are above that. Code that they produce tends to be sub-par and under-tested (because they are above writing unit-tests).
Source: worked with multiple Math PhDs. Have a few friends who are Math PhD working on some esoteric problems that I could not understand.
That is what gets me about these interview questions. I know a lot of very clever people. I am carefully differentiating 'clever' from 'smart', by the way. So many that are superficially fast and smart about solving whiteboard problems are terrible at all the things that actually seem to matter when it comes to creating value:
* Keeping a project on budget and schedule
* being able to create a budget
* managing people and resources
* Grinding out boring, but bug free code
* Writing clean code
* Being able to refactor
* Design software that is maintainable
* not tick off the people around you
SW engineering is a big, fuzzy, ill-defined optimization task in n-dimensional space. There are plenty of clever people that aren't very good at that sort of real-world iterative process. Sure, it is great to have a few people that can quote Knuth (if you don't know what algorithms are available, you'll often choose a substandard one), but by and large I want an engineer, not a scientist. A good one can learn red-black trees, or whatever, when it becomes necessary. The converse (a CS-y type person becoming productive in an engineering environment) seems less likely to occur, in my experience.
Yes... I ran a small group where we all got too inward focused being clever in our code and optimizations, all the while ignoring (for various reasons) that we had less income each month, and eventually folded.
I've since seen this firsthand at a couple other companies, on the inside and outside, where engineering types get way too focused on trying to hyperoptimize for a theoretically possible scenario X, while ignoring real world tickets that are costing them customers daily. They don't seem to realize that... when enough days pass, and enough customers leave, there is no more money to pay them.
Having lived through a couple failures (personal and professional), it's probably easier for me to spot these behaviors (again, because I used to do it myself). In my case, I wish I'd had someone early on beat that out of me - I simply wasn't aware of what was going on. As much as you can say "people have to learn for themselves", I don't believe that's the right attitude to take when the fate of a dept or company rides on what you're doing - too many other lives are involved.
This is in reaction to your 'budget' stuff above - I don't expect people to be Excel/Quickbooks/Peachtree gurus nor CPAs, but understand that you have to get stuff out, on time, and sometimes have to choose your battles and put out less than optimal code, then have a plan to address the known shortcomings.
I agree too on the CS adapting to engineering being more rare than engineering adapting to CS.
Unless you're being hired a PhD Senior Software Designer, there is exactly 0% chance (in 2014 anyway) that you're going to be working on improving Google's PageRank algorithm.
I was a lowly software engineering intern at Google and spent most of my summer writing MapReduce jobs which would traverse (1) every document in a large index of the web or (2) every book Google has scanned. Even worse, I sometimes needed to compute correlations between pieces of text in the documents. So, not only was the input size huge, the work per document was non-trivial. The remarkable thing about this sort of gig is how utterly unremarkable it is in a large tech company. If there's anything to Big Data beyond hype it's the commoditization of previously incomprehensibly large computations...and everyone doing computation on that scale should at least know the basic language of reasoning about time/space/communication complexity. You don't necessarily need to know the official jargon (though it helps to concisely describe ideas), but you should at least be able to think about how much extra work your program does for each additional input item (and how much extra storage it needs, and how network bandwidth it will eat up).
Except the thing is that these companies already have established internal libraries and tooling that implement "these sort of things," to a large degree and insulate the business needs from new hires such that any given hire's O(n) skills are not going to touch them until they get put on the task.
I highly doubt that someone that does not know what binary search is, that cannot think for a minute and come up with a small implementation, is going to "google and quickly learn" algorithms and the related thinking.
The issue isn't if you can write on simple binary search (considering such a search is a intro-to-programming task[1], that should be a given), but if you have an understanding of the topic in general.
When your project calls for a certain performance bound, will you flail around or have some idea what you're looking for?
I don't think it is difficult as you make it sound. The most difficult part is finding the term "binary search", but even that is not very difficult. All you have to do is generalize your problem and state it to Google. Binary search will almost invariably come up in the results. It even works for algorithms that are far more obscure.
My point isn't that if you don't know what binary search is then you're going to have a hard time doing a lot of algorithm searches. Just like if you didn't know what a linked list was, or a hashtable. Writing a hashtable or reasoning out the properties of a linked list, is not the kind of thing you should need to look up. It should be easy to talk it out during an interview.
These are basics. Same for strings, too. A programmer should be able to decisively explain how strings work in their language. Where do you draw the line? Arrays are just another data structure, is it OK if they don't know the properties of arrays since they can look it up?
> My point isn't that if you don't know what binary search is then you're going to have a hard time doing a lot of algorithm searches.
My point is that you can write a lot of software before you need to know what binary search is, and at the point that you do need it, you will be able to find out about it with ease. Like you said, it is a basic topic, so you don't even need much lead time to bring yourself up to speed.
I think where you are going with this is that if you don't know what binary search is, you won't recognize when you need it, which sounds quite logical, but experience has suggested it doesn't actually play out like that in the real world.
> is it OK if they don't know the properties of arrays since they can look it up?
I think so. For the vast majority of software being written, the only thing you do need to understand is the language's interface to arrays, which are usually presented as abstract collections. The idea of a collection is something that transcends beyond programming and computers and is understood by basically everyone. When the time comes that you do need a lower-level understanding, you can look it up quickly and efficiently.
A effective practice for writing efficient software is lazy loading, and I believe it works well for humans too. I might be willing to accept that it is a skill that not all people have taken the time to acquire, however.
I have seen developers struggle to identify the problem. You can't solve a problem if you don't know what a particular algorithm do for you. I have seen java developers knowing only ArrayList and nothing else in the collection.
In numerous forums, people ask for code because they don't know what the problem is. In which case, even search can't help.
> You can't solve a problem if you don't know what a particular algorithm do for you.
I'm sure anyone who is a CS researcher would disagree with you, but I'm probably taking your point out of context.
> I have seen java developers knowing only ArrayList and nothing else in the collection.
And I have seen a full-fledged computer science graduate, from a top school for CS, use MS Access for everything, including projects that had nothing to do with databases, because he didn't know how to use any other tools, and didn't appear to have the know-how to take full advantage of that specific environment. Bad programmers are bad programmers.
> In numerous forums, people ask for code because they don't know what the problem is. In which case, even search can't help.
Technically speaking, isn't that still a search? The only difference to using Google is that the results are indexed by humans instead of machines. I think this further emphasizes that most people really can recognize when they need a new tool and can find the right one on demand with very little trouble.
And, like I said, I am willing to believe that it is a skill that is acquired. Skills, by nature, come with varying degrees of ability. Perhaps the least skillful stand out most predominantly in your mind? The best are probably so good at it that you don't even realize that they are doing it.
You might be working in a scenario where you can't just look those things up. You have to code them through. Learning them then through general concept AND THEN implementing is too much. For instance, if you work in the embedded domain, you won't have the liberty to use public / standard / open source libraries.
You should know enough to avoid doing nested loops to find the intersection of two lists. Things like that come up on a regular basis for me, although I don't work at any tech giant.
There are things built into some standard libraries that are able to be combined in a way that produces a list intersection, but that are O(n^2). I prefer working in high level languages as much as the next person, but there's no substitute for knowing basic algorithms and data structures.
Yes, you just demonstrated an example of a case where a developer is not hurt by not understanding algorithms or runtime complexity.
Here's one where they are: In python, the in operator works on both lists and sets. For one, large numbers of elements will perform very quickly. For the other, it will perform very slowly. If a developer doesn't understand how they work, and where it's appropriate to use each, they can still do something completely terrible without even straying away from basic APIs.
While it seems like you're moving goalposts, this example also appears to be something a person could know without touching on nested loops or O(n) at all.
Of course, but neither was your point. You were rebutting that algo & bintree knowledge are unnecessary in the vast majority of companies, in favor of the pursuit of O(n) knowledge in candidates. None of your examples validated this, and "should" became merely "helpful."
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.
> 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.
I've got ~36000 hours of professional programming behind me and like you, there have been many a time where initial testing has highlighted a performance issues.
So out comes the hash table, the binary search, the double checking of the memory allocations or the some new index on the SQL table.
Now I know Big O tries to formalise these sort of things (or at least I hope that is the case), but is knowing the answers to these Big O questions that important?
Since I have Engineering degree I certainly can’t give a credible answer to a Big O question, but I have absolutely no trouble fixing sluggish code.
> But you should be able to recognize that a design
Unfortunately, at a lot of the places I've worked, not much time is ever allocated to design :(
Managers seem to want easy to read, high level, non technical design documents to take to their managers meetings and once those are approved they then want something coded ready for QA.
I sort of agree to most. Being able to write recurrence out of master theorem is never kind of thing really needed here. Even if you know conceptually the running time of a loop (nested ones etc.) and be able to apply that practically is sufficient.
Ah... yeah for the design statement :) i can't say much beyond that for most of the companies with established practices - you have to write a design document, often down to the level of writing data structures and function names - run through debates with others to justify your choices BEFORE you can even start to write first line of code.
I understand this partially because of being in Embedded, C/C+ domain where you can literally shoot yourself in the foot due to wrong choices and often product models are different.
E.g. at one place that i worked, code reviews and conventions were very rigid, some what more than say Linux kernel, because the product was an RTOS and associated stacks, which were sold to companies WITH SOURCE since the customers were actually developers developing end applications using our APIs. So even one comment not written according to company's coding convention often won't pass a peer code review - but i believe this is a pure exception rather than the norm.
Really? may be you didn't have an actual example so had to get sarcastic about it. So let me put a real scenario here.
How about a gateway device receiving some minor 3-4 millions subscribers traffic and processing like 40-50Gigs per second. I suppose worrying about hashing those ips to access individual records is a waste of time, and a simple list should work? right?
The scenario is not as common as may be building a website. But it a whole industry and a whole bread of programmers exist who do this all day. You should go out more :)
This is purely anecdotal however I've been doing Rails dev (and prior to that Javascript, PHP and even Matlab) for 14 years and I have only a vague grasp how most of that list works.
That's not because I'm lazy or scared or even disinterested. I've exhaustively learned everything about anything that what I do involves and how most of what it touches works as well. However the simple truth for me has been that I've never worked on things that needed to know about the things you're talking about.
I constantly do need to know more about the fundamentals of the systems I actually work with - Rails, Angular, HTML, caching, Node etc. I'm sure there will come a point when I need to know more about some of those things too.
However there is a tonne that I don't know even about the things that I need to know about and I will always invest my time in learning those things. That's why I would always focus interviews on the languages and frameworks that someone actually uses. Those may be the ones you describe but for plenty of developers may well not.
Maybe you've been lucky? Being forced down the stack seems to happen either when you need more performance, or when stuff blows up.
I only drill into a framework or language when someone writes that they're an expert on it. Otherwise, learning a new framework or language might be bumpy but if they have skill then it shouldn't be a problem.
More like persistent cache misses in SQL or some weird edge case caused by an errant vertical tab or a filename getting too long or some limit in array length causing your compiler to do weird stuff.
Knowing how any of that list works is more for sysadmins than programmers.
It's funny how the things you know well always happen to be the bare minimum of what you expect from others. Then you learn something else and hopefully realize that yourself of yesteryear still managed to write good, maintainable software, but that your current self would consider the old self a charlatan.
Lists like these reflect your own experience. I care more if an engineer can quickly grasp the "big ideas": Maybe they don't know about threads, but do they express disbelief that they solve a real problem, or an unwillingness to explore them? A willingness and aptitude for learning is so much more important because the state of the art is a moving target.
Yeah, but low level systems stuff isn't anything that's going to change anytime soon. My operating systems professor had been teaching that class for years!
If you write code, you should know what your code is running on. You should understand some of the layers of abstraction or at least be curious about them! Even if it's not related to your job, you shouldn't take the magic underneath for granted.
I see a big correlation between programmers who take a lot of this stuff for granted with cargo cult programmers - people who tend to think of things as "if I do x, y comes out" instead of "if I do x, this will trigger y, which causes z".
Sure, but why TCP and not UDP? Why threads and not processes? Why a web server and not a mail server? Why ports instead of sockets? The list you made is a decent baseline for somebody doing web development, but a smart person programming in another domain could easily pick up any of these things.
TCP is more complex than UDP. UDP is really just I pick my local ip and port, and send to your remote ip and port, and hope you get it. TCP has handshaking, acks, flags, resets, etc; a lot more to go wrong. Anyway, understanding DNS means understanding UDP too.
I've seen a lot of things in HTTP land that I wouldn't have been able to figure out without tcpdump. The most exciting thing is that livehttpheaders doesn't always tell the whole truth. :( But also subtle things like (TCP) load balancers mungling option fields, forged reset packets (and determining from whence they may have come), weird packet corruption.
Yes, absolutely I don't expect people coming from an offline world to know the internet stuff... but who's really offline these days?
Just about the only two things I ever encountered from your list are threads and web server. I work on web applications, but details of TCP, ports and ethernet are simply too low to be of any practical use.
But honestly I like to see any knowledge in low level systems - especially operating systems. I think it's important for people to know what their code is running on!
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.
This is crazy. You probably end up hiring the most convincing bullshitters. How can't you see that.
The reality for most engineers is that it depends on outside factors 99%. Engineers try to be rational. Here is what the real-world answers to your questions look like and I bet you never heard them.
Are you diligent and consistent with your work?
IF it's being rewarded, yes. If I get yelled for missing the deadline, then no. Do I get credit for doing diligent work or the credit goes to somebody else who managed to get more visible things done less dilligently?
Are you the kind of person that bursts through work in a flash?
That's a straight-out stupid question. There is work that should be done in a burst(like a fix) and there is async work that can be done in chunks or in the background(planning, monitoring or support). Nobody is exclusively committed to burst/no-burst, or at least it's very rare.
Do you prefer to work alone or in a team?
Nonsense question. It's more of a question for you rather than the interviewee. Everybody wants to be on a good team and everybody hates to be on a bad team. Also is teamwork rewarded, how are politics resolved? How do you manage politics? Who gets credit/blame for the teamwork?
How do you feel working with people below your position or above it?
Same as the previous question. How do you manage politics? How is credit/blame distributed? What power do I have to push changes up and down the chain? How would you handle an under-performing member up the ranks?
Just saw this comment got many responses! Answering a little late but answering.
I dont see any correlation between "bullshitters" and providing information. I definitely dont see a correlation between "non-bullshiters" and utter lack of information.
And also I don't know the correlation between "bullshiters" and actual technical knowledge.
The questions above were phrased quickly, and as i mentioned, its the questions you dont ask in an interview, but an information blank you have to fill out.
There are many ways you can answer and provide information about your work and professional that aren't empty phrases.
"I made this cool site with Rails, Angular, CSS transitions" -> purely technical
"I made this cool site with Rails, Angular, CSS transitions with consistent monthly releases, coordinated with open source contributors @ github. I also assisted community members in the technical setup of the project." -> technical + diligent + teamwork. And verifiably so.
Remember that we are talking about resume screening here, its a piece of paper that could be all lies , technical or non technical, its all about standing out and finding the right fit.
I am hardworking and very consistent with my work. My communication with coworkers is always friendly and respectful. I am able to point out mistakes and faults without hurting the person I'm talking to.
There you go, what did you learned about me?
If you base your hiring on what people wrote about their own personality, you will hire plenty of great salesmen. They will all be able to guess what the boss might like and generate nice sounding sentences to him.
They can still be poisonous jerks. And if they do, they will be perfectly able to hide the toxic culture they created from you.
As mentioned in my above response, there are many ways to show professional demeanor, attitude and culture that is practical and verifiable. For higher up positions, it will be always a referral call, but that is a lot of work to do for intern/entry level/medium level engineering to the which you usually lack an unbiased referral source.
Also, its delusional to believe a resume is not a selling tool. There are good and bad resumes and its pure salesmanship. Finally, you will have to prove that there is a correlation of any kind between salesmanship and technical ability.
A hire is a full package deal. If you interview a total wiz, but he comes to the interview naked, you will not hire him. Well, I doubt I would vote for a hire.
I'm not sure how you could convey your character or professional demeanor on a resume. I mean sure, everyone is just going to say they are wonderful and professional, no one is going to say they are terrible and sloppy.
It's up to the interviewers to make that determination with the help of professional references.
> 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.
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 ?
re: do you know how to actually name functions and variables well (unbelievably important)
It's also subjective and can be taught. If I asked people to name some functions in an interview, what would I really learn?
Similarly, the other things you mention, while important, don't seem particularly testable. They don't give me anything I can give to the hiring committee to back up my answer.
Actually learning something real about a stranger in 45 minutes is pretty hard. Asking them to solve a problem means you can have a technical conversation in front of a whiteboard. It doesn't answer much but it does let me know whether it will be worthwhile asking the candidate to help me solve a tricky problem, or whether they'll be coming to me for help all the time. After all, ideally I'm looking to hire someone smarter than me.
Algorithmic trivia questions are designed to bias an "objective" recruitment process towards recent graduates who have just revised all that stuff for their exams. It's a way to sneak ageism past HR.
You've just put into words what I've always been thinking.
In the 7 years I've worked and contracted web dev across 6 different companies I have never, let's reiterate, NEVER had to implement a sorting algorithm. However, if needed it would be quite simple to research and implement the best solution.
There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. For many software roles I'd much rather have someone who can write clear, maintainable, and performant code first, with deep knowledge of CS fundamentals only a requirement depending on the nature of the role and product.
Have you ever had to wrestle with the consequences of the complexity of analyzing a not-so-simple-and-well-researched data structure for which no generic implementation exists in any language?
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.
I have an unexpired H1B visa, but I left that job and the US in November, 2012. Now I've accepted another H1B job and my join date is in April, 2014. If you were counted against the h1b cap in the last 3 (or 6, I'm not sure) years, you will not be counted against the cap again, and you do not have to wait until october (when this year's H1B visas become valid) to enter the US and start your job.
H1B Transfers don't count against the H1B quota. If you still have time left on your H1B (i.e. approved I797 petiton) and have not violated the 'leave immediately if out of job' rule, it is possible to have a new employer file a petition for transfer of the I797 (H1B)
In fact, in such cases, you don't even need a new visa stamp for the transferred H1B. As long old H1B stamp has not expired, you can present this H1B along with the approved transfer petition and they will let you in.
This is just my understanding of the process and does not constitute legal advice. I am not an immigration attorney or any such. Just a technology guy -:)
Even if it were some sort of H1B transfer, I believe by leaving the US he might have abandoned his H1B. So I think the OP better get his immigration status verified by his new employer, because the last thing he wants to do is get a 10 year ban at the border.
There isn't a H1B transfer, but people often refer to it as a transfer, including immigration lawyers.
Basically, you must get a brand spanking new H1B to start a new job. However, if you have already recently gotten a H1B, then you can skip the quota, and get it approved pretty much immediately. This is commonly referred to as a "transfer" even though it is not technically a transfer.
Technically, if you lose your H1B job, you're out of the country right now. However, in practice there is some leeway, though lawyers differ on what they expect USCIS will let you away with (there seems to be some consensus on "10 days" though).
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.
Perhaps this is because big companies are interested in loyal employees in the first place, so they prefer candidates which can learn certain not-so-practical pieces of knowledge just for the sake of passing the interview for that company.
Give me a shout when you're in bootcamp (my unixname is 'nbm'), especially if you're interested in working in infra and want help finding out about and choosing between teams.
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.
You have the first part right. You try to get them to be the first to name a number, but obviously if both sides are following that advice, something is going to have to give; sometimes you have to name a number.
The key is, you should want to aim too high! They're not going to say 'no, and never darken our door again' (or if they do, then you had a lucky escape - if they're that nasty and irrational at negotiation time, what would they be like to work for after they had you in the door??)
They'll say some variant of no - 'that's a little higher than we were thinking of' or 'ha ha, very funny' or 'well we were looking at something closer to typical market salary' or 'I'm afraid there's no way our budget would cover that' or however they want to put it, the point is, they're not willing to go as high as the number you named, which is good - if they were, that would probably have meant you were leaving money on the table.
Then you say 'okay, what sort of figure were you thinking of?' Now you're negotiating.
As I said above, I've been in Silicon Valley for almost 20 years, I've never been "forced" to make the first offer. Maybe it's different here, but I find that unusual. The most I get from the recruiter is "How much do you currently make", and "What are your salary expectations." As I said above, when asked about salary expectations, I always say "market rate", and have never been asked for something more specific than that.
Always go for the highest they offer. E.g. If you apply for a job 25,000 - 35,000 go for 35k. My thinking behind this is that it shows you're confident in your ability. Remember a lot of companies are big enough to incur an extra 5k of salary in order to get the very best candidate.
I'd say the above becomes more true the bigger the company gets... Small companies <10 employees this theory could well breakdown.
Not good advice. This is a noob mistake. Where did that 25-35k range come from? From the other side of the negotiation. So, they've just anchored you to think that 35k is high. What if they would go up to 50? You'd never discover this unless you start outside their starting range.
The truth is, no (decent) company will reject you because you asked high but reasonably high. For some people it might mean that 'hey he must be good, if can asks that much and has no problem with employment!'. Social proof goes a loooong way. So don't worry.
Personally, I research what is a 'standard' pay in that geographical area and then add ~15%. Nothing to lose, a few thousands to win :)
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'
Working at a big-name tech company definitely makes you more marketable. It won't help you much, if at all, in the interview, but it will absolutely help you get your foot in the door. "If Google hired him, he's worth an interview" is a fairly rational thing to say, and a lot of employers say it.
So if your resume is lacking, that's not a bad reason to take a job. If your resume is already getting you interviews regularly, a job at Google might not help you much in your next job search.
I call bullshit on this one. Having a big-tech company on my resume has done nothing but send an endless stream of recruiters knocking on my door. Doesn't make getting a final offer any easier, but it has definitely improved my chances of getting the interview I want vs. just any old interview.
I always hear "Well if Google/Apple/FB are willing to hire you..."
"Having a big-tech company on my resume has done nothing but send an endless stream of recruiters knocking on my door"
I know plenty of people who didn't work at a Google/Apple/Facebook with an endless stream of recruiters chasing them. Maybe you have the type of background they're being paid to chase after.
"I always hear 'Well if Google/Apple/FB are willing to hire you...'"
If I hired the wrong person, 'well they worked at google' is a poor explanation for the hiring mistake. I'm sure working at Google can play to your advantage for higher level career goals and some people have done amazing things at Google. I just think people are over-estimating it.
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.
The fastest algorithm for computing the sum 1 + 2 + 3 + .. + n is constant. But the result of the sum is O(n^2).
You can use that result to conclude that algorithms like for example bubble sort has a worst case running time of O(n^2), since it does (n-1) + (n-2) + ... + 1 swaps in the worst case during the whole sorting.
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.
If you gave that response at an interview, you'd be praised for knowing what a URL shortener is, then asked to drill into more detail. For example, what data store would you use for your hash table? What technology do you use for your web tier? Are those physically on the same box? OK, that's fine. Twitter just bought you and you have 48 hours until you're receiving 100,000 requests per second. What needs to change about your architecture? OK, good answer, good answer. We recently discovered that people are abusing our infrastructure to cloak links to pages delivering malware. We need to be able to ban a domain and yank all their links retroactively. How can you accommodate that? etc, etc
How would you guys answer this one?
Start by saying that you're capable of approaching that problem at multiple different levels of the stack, from the browser chrome to the networking layer to HTTPS to HTTP to Google's (presumed) infrastructure to the browser again. Ask where they want you to drill down. Networking? OK. Evince some knowledge of what DNS is. Mention that Google controls the records for google.com on a nameserver somewhere. Maybe talk about bind a little bit. Mention in a wee bit of detail how the A record propagates out to the rest of the network, including to the user's DNS server. Observe that since it is google.com it is certainly cached there (and is probably already in the OS's DNS cache to boot, you might add). Ask if the interviewer would like to hear about TCP/IP or SSL handshakes or what have you next.
I've had it twice. The first time, with Google, they were genuinely interested to know how deep I could go, so I talked about DNS, TCP, SSL, HTTP etc, but I also talked about application event loops and keyboard drivers and interrupt handlers.
The second time, with Rackspace, I presumed they want the same, but they were a bit bewildered and wanted to keep it higher level (protocols only).
I sort of hope someday to be in an interview where they ask that question. I'm pretty sure I could go an hour straight on it. Possibly two. Obviously, they won't let me. But still, it ought to be fun... I'll probably get stopped somewhere around the CPU trying to figure out which layer of cache the kernel's event handler is in, if not before....
Come interview at Facebook for a Production Engineering position[1]. I bet you your interviewers will push you at least that far or I'll give you a free lunch[2]. Even if it's just for the interview experience.
[1] I work there and love it. My contact details on my user page.
[2] I'll give you a free lunch either way. No purchase required. Void where prohibited.
Can you recommend how to learn this? I don't work with the web or networking, and would like to shore up that part of my knowledge. Are there any good books that gives the high-level overview of it all?
I find that the best way to learn it is to start poking at it. Fire up Wireshark, load google.com, and take a close look at the traffic. You'll see every packet going back and forth, and can try to figure out what each one of them is. Set up a proxy that can MITM the SSL connection, and look at the contents of the packets. Just setting that up will probably tell you a lot about how it all works, and you'll be in a better position to see the plaintexts of all of the handshaking traffic.
The first question has had a semi-famous answer from this post in 2011: https://plus.google.com/+JeanBaptisteQueru/posts/dfydM2Cnepe I'd be interested to know what if any books people recommend as well, though my own strategy is when encountering a black box, and desiring to learn about it, I learn about it using whatever resources I can find to make it transparent (often revealing many internal black boxes...). Occasionally online I'll find someone who made really good visual diagrams that help summarize a thing that I might not have found otherwise in a book, e.g. http://code.google.com/p/corkami/wiki/ELF101 or http://brendangregg.com/linuxperf.html
As for the link shortener infrastructure, I'd ask for more context to get a better idea of the scope. If there is not more context than that, define the scope at which you're operating (eg, "I understand 'infrastructure' as 'the structure of the service' and not as 'the physical infrastructure'" and define yourself what the URL shortener does (going with "a web service with a single endpoint" sounds reasonable to me). It's really important to understand what you're trying to achieve first, especially when faced with a real problem.
Ask the interviewer. One of the things that I find most difficult about interviewing is when the candidate doesn't ask me any questions during the technical parts of an interview. If you aren't sure, you need to ask me -- I am perfectly capable of misphrasing a question or assuming you have context that you don't. Asking your coworkers for help is a perfectly legitimate problem solving strategy.
Interviewing is stressful and hard; no need to make it more stressful and harder on yourself.
I sometimes ask questions and get 'What would you do if there was no one to ask?' and 'What would you do if there was no Google?' and I would like to understand this. Should I have everything rote memorized? Should everything I do be a bespoke solution?
The latter is a gentler way of saying, "no, I want your solution to this trivial problem".
The former is a question about your work process; for instance, if they say, "ok, so build Twitter" and you respond rationally with, "what of Twitter should I build?", they're probably looking for how you operate in an environment with underspecified work. It might be a good idea to talk about how you'd defend your decisions to draw the boundaries of the problem; why you chose to ignore e.g. streaming updates or following; &c.
Can anyone cite a good source that provides a fairly detailed answer to the second question? I'm not looking for a hand-waving forum post but an actual answer aimed at someone who doesn't necessarily already know it.
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...
Why SF? From what I've seen the London tech scene is really kicking off now. Some of the better funded start ups here are even starting to compete with finance jobs salary wise. And on finance: There are loads of jobs that industry in London, C++ and python make the world go round in hedge funds and investment banks!
Could you share what companies you are referring to? Which finance companies use Python? I am soon to graduate and I would like to find something in London that is using Python or C/C++.
Don't want to get too far off topic (or reddity), but Hogwarts seems like more of a trade school. (Great for magic, not for a university education or for fields such as computer science.)
> 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.
I also think that an individual employee needs to put a discount on options because you don't have the ability to diversify, your risk profile is vastly different than the investors, and the founders presumably have effective veto over exits which allows them to capture more of the value in a middle of the road outcome like a acquihire.
I personally think that options should just be used to mitigate the career "risk" of the instability of the company and maybe having to move down-market into some less valuable skills if that's what the company needs.
"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.
When relocating from NYC to San Francisco a couple years ago I similarly tried to minimize the number of trips. I tried to be very thorough in phone screens to make sure that they were intersted in me and I was interested in them.
After the first 24 hour trip (leave at night east coast time, fly to SFO, drive south, interview all day, drive back to SFO and fly home) I knew that wasn't going to work (I certainly didn't perform as well on that interview as others).
My next trip was arranged by me with costs split as fairly as I could. I found companies were happy to be flexible and reimbursed me very promptly for their share, but as the article suggests it was a little out of the norms for them and probably harder to arrange then HR or their travel agent doing the "standard package".
I had two companies split the airfare, and others pay for a night hotel each. I didn't chase meal or transportation expenses, though nearly all of them offered to cover them (and generally lunch was part of an interview each day anyways).
I had the opposite impression. I tried to cram 4 interviews into a week so I wasn't constantly flying away from school and every company was more than happy to pay less to fly me out. One company paid for my flight there, one for the return trip, and two lucky places got off paying nothing at all (I had places already lined up with friends nearby to crash at so no one insisted on buying hotel rooms).
I think this might be a case where you cross that company off the list for being unreasonable. You don't want to work in the type of environment if that's typical policy.
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
nice... i recoil at spreadsheets for similar tasks too but must confess that i usually find a text file with a couple special delimiters sufficient / am lazy enough to convince myself that such a text file is sufficient. both could just as well be imported into a database/app later, but i find that text is more free-form and easier to work with than spreadsheets.
Curious what you find wrong about using a spreadsheet for this? I've used it a couple of times in the past when I had lots of applications and interviews going and found it worked rather well. It doesn't really use spreadsheet capabilities (except for adding up number of interviews or success rate maybe) but I didn't find anything wrong with it.
i don't find it "wrong." i just find it "wrong for me." the real (and very subjective) answer is that all the spreadsheet uis i'm familiar with are very clicky (as in you wind up using the mouse a lot). when i'm at a computer rather than a touchscreen, i prefer to use a tiling wm and programs with keybindings. perhaps i just haven't taken as much time getting proficient with spreadsheets as i have with text editors. also, some people prefer using a mouse, and there's certainly nothing objectively wrong about that.
also, as i said in the previous comment -- and this is more objective, i think -- text files are more flexible than spreadsheets in that they don't impose any particular structure on the data you're entering. if you're populating a relational database, you're going to wind up having to put things in table format eventually, but perhaps you don't want to have to decide exactly what data you'll be entering from the moment you start entering it. in that case -- and perhaps this is going back to personal preference again -- i find it easier to rearrange a text file than a spreadsheet.
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.
A standard Quicksort implementation is absolutely worst-case O(N^2). Variants do exist like median-of-medians quicksort or introsort, but I would never describe O(N^2) as wrong. In fact, I would be very happy if candidates knew the difference between worst-case and average-case analysis.
first of all, it's all nomenclature, and i don't want to make a whole thing out of this, but binary search requires that you can randomly go left or right every time you subdivide the (linear) ordering, not that you can randomly index to any element.
EDIT
also, perhaps against better judgment, i'm going to throw a possibly inflammatory remark out there and say that the big-O thing is really not that difficult or important (although i suppose that it's important that it not be difficult). what i can see taking some skill/experience (which i totally don't have) is knowing a bunch of algorithms and being able to consider the time/space tradeoffs of the algorithms you already know quickly. being able to prove the time-complexity of some new algorithm is good, but, sadly, perhaps, i don't think most companies hire people to do that.
i wish people would comment when they downvote. i made the final comment already knowing (and stating!) that it might rub someone the wrong way but hoping that it might provoke discussion. it's a reasoned and reasonably-informed comment, not just noise-making or an attempt to troll. downvoting without comment in that situation doesn't really further the discussion.
of course, when there are two or three items left, choosing between left and right is the same as choosing an arbitrary index. that's nomenclature. whether you follow the rote textbook definition and do that indexing up front or delay it until you've paired down your possibly-large list into a manageable (whatever that might mean for the problem domain you're dealing with) size, it's still pretty much the same algorithm.
and since you're imagining rather than being certain, that means people continue to downvote without comment, and i continue to cheerily object to that.
"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).
Honestly, there were none. I think giving someone a challenge to do a their own pace was a perfect idea. I interview candidates in a discussion format so I can attempt to gauge passion, competency, and potential. I have been interviewed by startups where the guy on the other end of the phone seems annoyed to even have the call. The fact someone in your position in the company does direct phone calls to engage your candidates is EXTREMELY positive because you are showing care for your company by being that involved to know your candidate.
Heading out to Mountain View for an on-site interview with Matasano next week. So far the process has been great for me too. It has been challenging but they (tptacek and co.) still manage to do a great job of moving things along quickly.
Hopefully I don't scare them off after they've flown me out (and I've spent 16 hours on planes and in airports).
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.
I was in an identical position 3 weeks ago and I shared some of your concerns as well. I can tell you that it seems scarier than it really is once you're in it. You shouldn't be worried about getting 'stuck', I did a number of times and quite often would get hints and directions from the interviewer. Never give up, even if what you know you don't know the answer right away, let the interviewer see that you're thinking and try to engage a discussion.
And really just try to take it easy. I was also under a bit of pressure, but think of it like an experience, even if you end up not passing. It's just another company and the feedback of 5 random people.
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.
This is poor advice. When you say "I'm always open to negotiating", you've immediately lost to a degree. Think about these two scenarios:
Q: "How much are you seeking?"
A1: "I'm looking for 80K"
A2: "I'm looking for 80K, but I'm always open to negotiating"
A1 may get 80K, A2 is unlikely to get 80K, because A2 has started negotiations before even being told no.
When you are asked for a salary requirement in a live setting, say your number (assuming you choose to say your number) and stop talking. There may be some silence, and that's ok.
This mistake is one I mostly attribute to entry level job seekers. I've been recruiting some junior level roles lately and these candidates almost always add the "willing to negotiate" to their number. I give them this same advice - say your number and stop.
This is generally good advise (don't suggest willingness to negotiate, because that suggests you will take less).
But, unless you've done research and have confidence that the $80k is viable for your experience and the position, you can also scare off many potential employers.
That's why I'd suggest delaying giving a hard number to much later in the process, after all the screening and interviews when its time to develop an offer. You'll have more information then to justify a given price point and more leverage for a "take it or leave it" moment.
I recommend giving either a range ($70-$90k) or your last salary (I made $70k at my last job, so that's a reasonable minimum I would expect). As an employer, I'd likely start on that low end ($70k) with an initial offer. That gives you the opportunity to decline (I made that at my last job, and my skills and experienced are much improved since), and then give me your terms (say $80k or even higher) with justifications.
No argument here - if you walk into any hiring situation without some knowledge of fair market value, you are in a bad spot. I think candidates don't prepare for the question as well as they should and try to improvise on the spot, and many are not good at the improv. Having a number that is well-researched is quite useful, and being able to negotiate on your feet as necessary once numbers are discussed is important. Email is made much of that easier, as numbers are often shared in that manner instead of in live conversation.
Yeah, but I assure you that most of your entry level job seekers have no idea and either ask too low or some wildly inflated number (my friend over at blah blah was offered $120k...). It's more about being able to justify your expectations than having an accurate number which is why softer targets like ranges or previous salaries are usually easier.
Entry-level tend to fall into two categories in my experience. One are the "...but I'm willing to negotiate" types that end up getting 10K less than their likely value, and the others are the ones who ask for some stupid number like you mention and end up blowing a handful of solid opportunities before eventually learning how the game is played. For both, it's part of the learning process.
I agree that ranges are not a bad idea, but having a target number to quote (even if it is a few K above what you are willing to take) and a basement number (will not accept below) is a good idea.
Never, ever, ever pin yourself down with a number. This weakens your ability to negotiate tremendously. Not giving a number forces the other side to present what they believe to be a good offer, as opposed to what you already mentioned as a desired number, which might be a lot lower than what they were thinking of.
I always say "I'm fine with a market-rate salary. I'm open to a salary cut from my current salary if the position has a great opportunity."
This routinely great advise (never make the first move!) just doesn't work in practice. Those making the hiring decisions are going to want to identify a range of possible salaries before continuing the recruiting process. Otherwise, if the candidate later demands an extremely high price, we both wasted a lot of time and resources.
Here's what I recommend and have used successfully:
A) Offer a range
B) Offer your last salary (with some expectation of a bump)
The key is that this gets you in the door for consideration without being committal. Once the employer begins to really sell themselves on you, then you have the leverage. Other offers can justify increasing your ask and now they're more hooked on you as the right candidate.
I've always used this very common tactic successfully in my almost 20 years living in Silicon Valley. If they take offense to this, then they're probably not a good employer.
The thing is, what you believe is a fair rate could be vastly below market rate. As a salaried employee, you don't have any real insight into what they are paying people.
For example, I've heard from a friend at Apple $170,000/yr + 250k in RSUs over 4 years. He said a co-worker accepted a job at Google for 180k + 400k in RSUs over 4 years. I would never have known these, and if I gave what I believed to be a fair rate, I might have underbid myself.
If your answer to "what salary are you expecting?" is: "I'm fine with a market-rate salary", I'll just ask you what you think market-rate is for your position.
Now, usually, you can just say something like: "market-rate will vary with the type of position, role and responsibilities".
The goal of the recruiter is just to get a confirmation that your expectations are in within the range permitted for the position.
If you suggest that others at Apple or Google are making $X and $Y for the same role, that helps the recruiter identify how you're evaluating a market-rate. It's up to you to not price yourself below what the market may pay for your services.
That's the fallacy of never making the first offer. This expectation that you could be undercutting yourself and your negotiation partner would have offered more. In reality, this almost never happens, especially if the expecatation that the terms are negotiable. The company will just offer the least favorable terms first expectating a counter if they're unsuitable.
I will admit to not knowing how things are done outside of Silicon Valley, so if that's the norm outside then I gladly defer to you.
But in Silicon Valley I've never been pressed to give a salary. So in today's market, if I were talking to you as a prospective employee and you pressed me to give you a salary without you telling me how much you want to pay for the salary, I would politely decline to continue the interview process. I don't need a job that badly (yet). It would feel to shady to me to have the prospective employer force me to give a salary expectation before they give me an offer. They know what their budget is, and if we're in the negotiation process, they know if I'm worth whatever their best offer is.
If you are a recruiter, and this is the initial phases of the conversation, and you press me on salary expectations, then I most assuredly will not continue the conversation. I don't think it's appropriate for either side to discuss salary expectations at that point.
If I'm desperate for employment, then I'm sure my feelings would change on this, but so far (knock on wood) this hasn't been an issue.
Yeah, fair point. If by Silicon Valley, you mean the large tech companies (like Google, Apple, etc), you're correct that they won't ask your salary expectations since they have their own internal process for determining compensation for a given candidate. (They also generally think they can outbid anyone else).
I have been working with smaller startups (down here in LA, but I've seen the same behavior up north), who tend to filter candidates based on expected salary due to limited resources and hiring for an exact role. (We tend to mask our cheapness by using phrases like "hungry" or "passionate").
Given that, as an employee, you are the seller in the relationship, that would be like Walmart not posting prices on any items and making you suggest what it is worth at the checkout. It is not usually how business is done.
About the only exception that I can think of is in sales of commodities, where the buyer typically does make the offer. I'm not sure you want to treat yourself and career as a commodity, do you?
Wouldn't it be better to state your price alongside your sales material? If you're not in the ballpark, then you can even save yourself wasting time talking with the potential client further.
> Given that, as an employee, you are the seller in the relationship
Very serious question: Is that actually true, and why do you believe it?
Is it "I'm not the one with hard cash, therefore I am obligated to negotiate like a big box retailer"? Don't be fooled into adopting an unhelpful paradigm or power-relationship just because what you are bartering is harder to quanitfy.
In many ways your employer is much more like Walmart than you will can be. For example, they are a larger entity that can amortize risks over lots of individual interactions. Also. they invest significantly in accounting, data collection, and have better knowledge of what rate they can accept for a transaction.
Walk into a negotiation thinking that you "owe" the other guy an advantage, and you've already given it to them.
The opposite of a seller is a buyer. Do you think an employee is better described as being a buyer?
> In many ways your employer is much more like Walmart than you will can be.
This is the commodity situation I mentioned. Try being a farmer for a while and see what it is like selling your crops. You'll then know exactly what I'm talking about.
If you are just another person that is easily replaceable by any other person, then you are, in fact, a commodity. However, I don't think that is what you want to strive for in your career. Setting yourself apart is how you make more than commodity wages. And, in that case, only you know how much your time is worth since there is nobody, or few, to even compare you with.
If you don't even know how much your time is worth, how is anyone else supposed to know? If you do know, why hide it? You are (hopefully) the desirable smartphone that boasts to everyone how expensive it is, not the undesirable flip phone that has to hide its true cost in fine print in hopes someone might be foolish enough to buy it.
> Do you think an employee is better described as being a buyer?
No, I'm asking why you see yourself as a seller-like-Walmart, which is a subtype of seller who freely offers a public fixed price in advance of negotiations (if any.)
It's entirely normal to negotiate for different kinds of things in different ways... And your labor is quite different from anything Walmart sells.
> If you don't even know how much your time is worth, how is anyone else supposed to know?
Well, so what? That cuts both ways! If the company also can't price the tasks they need finished, how is anyone else (i.e. the employee) supposed to know?
> I'm asking why you see yourself as a seller-like-Walmart
I see myself as a seller, and sellers have largely chosen the fee up front model because it is more efficient.
If you need an income of $150K per year for your time, you're probably not going to find many who really wanted to offer you $200K, and you're probably going to deal with a lot of people who only want to offer you $50K. Why would you want to spend potentially months or years in talks with people who cannot afford you just to finally find the gem who wants to pay you even more? Setting your price at $150K gets you talking with people who will pay you that much.
Even if you managed to get an offer $50K above your hidden asking price, does that justify the time spent finding it when you consider average employment terms? You cannot look for work for free. It is actually quite expensive.
I will add that setting yourself apart means, well, doing that. You shouldn't even consider doing what other people are doing anyway if you agree with me on the premise of not wanting to become a commodity.
> If the company also can't price the tasks they need finished, how is anyone else (i.e. the employee) supposed to know?
Does it matter? People selling their employable services tend to price them by the hour, day, month, or year. If the project costs $100K or $1B, it doesn't really matter from your perspective, unless you are concerned about the well-being of the investing party – but that is a risk even with low costs.
One need not behave like Walmart to be a successful seller. Car dealers, Auction houses, and Turkish carpet salesmen, to name just a few, are examples of other extremely successful sales protocols.
"But, I'm always open to negotiation" is a good way to guarantee you won't get what you want.
It's pretty well accepted that the first person to give a number loses, so you want to push this on them. They are the business with a budget, and a budget for your position, they already know what they can and can't afford. All they are trying to figure out is how much you are undervaluing yourself.
This question typically comes up WAY too early as well. If this is part of the phone screen I just tell them it's too early to tell as I don't know the full responsibilities of the role and other factors such as growth potential, etc.
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?
If I was guessing, I'd say that I very consciously made my CV/cover letter/blog "intriguing". I'm an OK programmer, but at the moment my strength is probably that I have a diverse list of fairly wacky and mostly unrelated other stuff that I've done. I think this meant that a lot of companies who would otherwise have passed straightaway were at least curious enough about the guy on the other end of this application to talk.
I should point out that after a Skype or 2, most of said speculative companies did realise that whilst founding a clothing company that makes sweatshirts with pictures of fruit on them is cool, it doesn't really help you write Clojure when you don't have any functional programming experience ;)
Of course, it could just be something boring like the fact that companies really need Ruby guys at the moment.
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.
I may be wrong, but I believe that interviewing in the US while you're on a tourist visa/ESTA (presumably your case?) constitutes "seeking immigrant status" and is unlawful. You may want to avoid posting about it in public forums where your identity can be easily traced.
You are (mostly) wrong. A job interview is a perfectly legitimate activity to undertake on a B-1 (business) status. I have done it more than once. At immigration, they ask the purpose of your trip; you say, "job interview;" and they stamp your passport with B-1 (business) rather than B-2 (tourist). It really is as simple as that.
I am really, really not a lawyer, but he says he is seeking a job offer for a TN visa, which is non-immigrant status, so I don't think this is a case of seeking immigrant status.
The size of the number (result) is (N(N + 1))/2, the computation of the algorithm is constant. I've never heard anyone discuss the result of the algorithm using Big O.
> 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.
I'd say hashes aren't going to make everything faster, but they will always be faster than disk lookup. But more to the point that I understand you to be making - hashes are excellent when you have large amounts of _repeated_ calculations.
For instance, counting word occurrences in a large body of text. Rather than run through the body N times for N words, you run through it only once and increment a word's tally every time you come across an occurrence.
Do you mean that a cpu-bound process could improve on this?
To be fair, he refers to the strength of lookup time in the quote you cite, which is not exactly the property that improves the algorithm I just mentioned (which is that the use of a hash completely restructures the algorithm). I'm curious to know more about situations in which you find writing cpu bound code to work better. Including - what sort of N are you dealing with when you make this choice?
I can imagine that generating HTML on the fly is a simple enough computation to outweigh the benefits of caching every possible view - which is to say, the N of each rendering is small enough not to be truly cpu bound. But even then, that ignores the fact that we'd be reading from disk anyway, and so I don't see how that's worse than paging.
These are my thoughts. Not gotchas. I just want to know what I'm missing.
O(N) brute force algorithms (almost) never beat hashing. O(log(N)) tree-based algorithms sometimes do, because it’s easier to get good data locality out of them when the queries have some temporal relation.
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?
Obviously I would say this, but the Stripe process was really enjoyable, rapid and well thought through. It was clear that everyone really cared about making sure that you were able to really show your true skills and abilities. The team is great (and obviously just got 5.8% more great when I joined) and really happy to answer any and every question you might have.
So I strongly recommend. Although I would say that.
wow, just upvoted your helpful reply. Can I ask what/how to prepare for the Stripe interview? Looks like cramming algorithm questions is not going to work. And it looks like, through your and OP's experience, Stripe is looking for people that are cool to work and hang-out with, self-motivated, and can write clean code.
That sounds about right! Greg's Quora answer pretty much covers everything, and I'd say that there's not much you should particularly do to prepare other than to keep getting better at what it is you do anyway and to chill out. pc specifically said to me that the primary thing he cared about was that people were able to show how good they actually are, and that everyone feels they got a good crack at the whip and didn't get screwed over by a weird question or not preparing some specific thing or anything like that.
I am actually the OP :), my email address is in my HN profile and feel free to email me with any more questions!
Some links are here https://news.ycombinator.com/item?id=7325545
I really wish I had had a chance to read that before my interview. Knowing what the interviewer is going for when you are coding helps tremendously.
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.