Lessons from a Silicon Valley job search
robertheaton.com
robertheaton.com
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.
For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.
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 :)
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?
1: "Guess my number between 1 and 100!"
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 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.
In numerous forums, people ask for code because they don't know what the problem is. In which case, even search can't help.
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.
I do think some people at FB/Google need to know this stuff cold, but even that isn't going to be 100% of their engineers.
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.
+1
* 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
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.
Source: worked with multiple Math PhDs. Have a few friends who are Math PhD working on some esoteric problems that I could not understand.
Minimizing the CPU and memory usage of your application is engineering more than science; however, doing it requires a lot of CS knowledge.
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.
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.
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.
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.
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.
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?
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.
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.
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.
But I still can't find a job in Google.
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.
Large companies tend to already have very stable revenue and now need people to make their systems more efficient in order to decrease expense.
intersection = ary1 & ary2Here'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.
Case in point, 10s of Googling produced this link: http://stackoverflow.com/questions/2831212/python-sets-vs-li... ...and I don't even use Python yet.
Is it helpful to understand? Definitely.
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.
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'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.
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.
[1]: http://jangosteve.com/post/380926251/no-one-knows-what-theyr...
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.
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.
- How virtual memory works
- How threads work
- How TCP works
- How ports work
- How ethernet works
- How DNS works
- How a web server works.
And so on. A lot of these things are more important than theory (but I think theory is important, too!).
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.
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.
TCP? DNS?
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.
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.
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".
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?
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!
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.
(think parsing and searching monster flat text databases from disk)
Augh, PTSD trigger.
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.
It's up to the interviewers to make that determination with the help of professional references.
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?
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.
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.
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.
What in the actual fuck. What do you expect to see? "I am clean and not a raging asshole"?
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 ?
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?
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.
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?
Can you explain what you mean by this? Are you not familiar with the term, or do you not believe it exists?
then maybe you're not solving very challenging problems.
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.
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.
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.
I know, I am constantly concerned about sorting that list of 100 items!
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 :)
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.
That is what I would expect someone who has had to wrestle with big-O problems but didn't recognize them to say. I honestly don't know what you're working on if its actually true. I had a time complexity issue just this week. On front-end code, no less. I probably work on an issue involving time complexity once a month, if not more often.
In 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.
All of the other points are what actually matter.
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.
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.
Maybe the OP's situation is the same.
I do not understand how could he quit his job and search for another job for 3 months using the same H1B.
I might be missing something here.
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).
Something I learned after the whole process was that people apparently take a month or two to prepare intensively and specifically for interviews with these 3 companies. Luckily I came out of the ordeal with an offer, but I wish I had known that tidbit before.
I'd say the above becomes more true the bigger the company gets... Small companies <10 employees this theory could well breakdown.
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.
Personally, I research what is a 'standard' pay in that geographical area and then add ~15%. Nothing to lose, a few thousands to win :)
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.
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'
I always hear "Well if Google/Apple/FB are willing to hire you..."
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.
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.
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.
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.
Congrats to him on the new job and the H1B visa and to Stripe for hiring him. He seems to really deserve it.
I'm wondering how to answer that?
* Get a short and memorizable url.
* When you enter an URL hash it, put it in a hash table and use the hash for the link.
> “If I type https://google.com into my browser and press enter, what happens?”
How would you guys answer this one? I'm not sure I've enough knowledge to do that. I'd say:
* first TLS handshake thanks to RSA to share a key
* then a GET
* then the server sends a cache version of Google according to location/cookies/etc...
* then the html gets displayed in the client's browser
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.
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.
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.
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.
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).
[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.
well, it closes the circuit in the enter key causing the electrons to move...
Background: London. Comp Sci. from top 10 worldwide college. 2 years C++, Python, iOS experience in well known company on high profile project. Internship at start up with VC funding before that. Github profile with open-source projects, own projects etc. Started blog etc...basically everything that is recommended.
Studied for 5 months (up to and including interview time) and did projects whenever I could. Applied to 40 companies in San Francisco. Got 12 straight no thank you, 2 interviews and the rest ignored.
Started process on Jan 1st 2014. Had interviews at Yahoo! and Palantir. Former, pulled the plug when the H1-B deadline was looming and they felt it wouldn't be done in time. They suggested a workaround to work out of London and try next year and then they pulled that idea a few days later when they didn't have the team in place to support it. The latter, I did 1 telephone interview which went fine, then on-site where I was quizzed for 1 hour in functional programming (never done any before and job is in Java) and had to code not on paper, or a whiteboard, but the glass conference wall...
Will have to wait another year.
Hogwarts?
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 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.
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.
you don't have to use a ticket that someone else paid for. why deny yourself agency in this situation? i guess i'm missing something here.
and if you're concerned they follow up and spied on you afterward, then you dodged a bullet.
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).
decided not to open source it?
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.
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.
Regarding hashes - it is not clear if you want the cadidate to mention collisions or not.
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.
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.
Hopefully I don't scare them off after they've flown me out (and I've spent 16 hours on planes and in airports).
So: see you there. :)
I feel like a coward for being afraid of this stuff.
Anyways, I just wanted to get that off my chest.
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.
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 :)
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.
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."
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.
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.
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.
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.
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").
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.
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.
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 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.
>Very serious question: Is that actually true, and why do you believe it?
Because we don't talk about the "buyer" of USD except in a currency exchange context - you don't say, "I just bought $100 with my old bike."
If I have a Rembrandt painting, I am a seller... But do I want to sell like Walmart, or do I want to sell like Sothesby's?
">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?"
and asked if it's true. There is no other context in the line you quoted except that the employee is the seller in that relationship.
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.
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.
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.
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.
Accepted but not necessarily true. In this market where the candidate often has very good salary data, s/he can also win by anchoring very high.
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.
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."
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.
I'm currently in Silicon Valley from Canada on a 2.5 day trip, with 4 interviews in that timeframe, and it's quite fun yet intense.
I'd also say that if you're a self-taught programmer (I'm an EE), it's worthwhile to read a book like Intro to Algorithms[1] cover to cover before you start doing technical interviews. There are just too many CS101 concepts that you'll never run into even after years of programming.
[1]: http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme...
EDIT: Nevermind, I think it means the value of the sum is on the order of n^2
The sum of the numbers is O(1) - you can calculate it algorithmically.
N*(N+1)/2
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.
Also, complexity analysis/algorithm questions that are asked in the interview setting is not rocket science...
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).
120k-140k 0.10% to .20%
Not really competitive with Google/Apple/FB/Amzn or even a mid-size tech firm.
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?
So I strongly recommend. Although I would say that.
I will really appreciate your reply.
I am actually the OP :), my email address is in my HN profile and feel free to email me with any more questions!
(inc kudos)
$Xk/year 10,000 options
This is literally equivalent to:
$Xk/year $100bn in monopoly money and bingly bongly bangly boo"""
It is incredibly dishonest and disrespectful when startups job offers hide information about the value of their equity. I know some investors are encouraging this behavior, but please have the courage to stand up to them. Employees have a right to know the fair market value of the compensation they will receive for trading away their time and labor.
Hedge fund interviews are a lot more intense and technically difficult (and you feel good when you pass) but don't come with the VC-fueled, youthful arrogance of a proper Valley company. Hedge funds also don't try to lowball you with insulting junior positions because you're not from California or you don't know the five 3-year-old technologies in their stack in detail. If you pass their interviews, the hedgies take you seriously. Most of these VC-funded companies, on the other hand, don't really respect most of the people they hire. They sell aggressively, but the options offers turn out to be ridiculous (sub 0.1%), relocation pay is nonexistent, and, if you're not a Valley insider, the positions are often pretty terrible, as you discover if you ask the right questions.
If you can deal with arrogance, you can probably get a good job in the Valley after enough time. But you'll have plenty of experiences that leave you thinking, "How is this company alive?"
What is the name of Java technology which loads classes? A: Classloader.
Yes, I do have two years of Java experience, I got used to their "Describe red-black tree algorithm"-like questions. But thank you, I measure myself not by remembering names of JVM components.
You can change 1 billion people's jobs every day with a handful of 3-year old technologies, starting today and ending as a VC-funded Internet startup. You can literally start today.
This is mostly going to be of interest to people building value though.
But here's a job tip: Don't talk about women like this. If you get a job, you will actually have to work with some. Also this level of immaturity will make your job search that much harder.
http://tvtropes.org/pmwiki/pmwiki.php/Main/BeautifulAllAlong
"She's All That" is a prominent example.
http://tvtropes.org/pmwiki/pmwiki.php/Main/BeautifulAllAlong
Romance is the most commonly used metaphor in the history of the English language. I suggest you avoid Shakespeare.