151–160 of 289 posts
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.
Getting a job in Silicon Valley, as an outsider, isn't hard. Getting a good job is hard. Many offers will come through at a lower level just because, whatever you did, you didn't do it in the Valley. That's Cali arrogance for ya. Hedge fund interviews are a lot more intense and technically difficult (and you feel good when you pass) but don't come with the VC-fueled, youthful arrogance of a proper Valley company. Hed…
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.
> 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 serve…
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.
Earlier quoted context omitted.
If you work at Google or Facebook or any other of the tech giants, you need to know your algorithm-type questions. For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.
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 on…
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.
Earlier quoted context omitted.
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 :)
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" the…
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.
This may very well have been an excellent piece. But, the author lost me no later than 2 sentences in with his immature and sexist "nerdy girl" analogy. I just didn't even bother to read the rest. Working in silicon valley myself, I already waste enough time on people who think this kind of immature male mindset is okay.
I don't think that was intended as a sexist remark at all. Rather, it was a pointed jest at the Hollywood trope of "nerdy girls"—basically making fun of Hollywood for being sexist. http://tvtropes.org/pmwiki/pmwiki.php/Main/BeautifulAllAlong
(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 n…
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?
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.
Earlier quoted context omitted.
If you work at Google or Facebook or any other of the tech giants, you need to know your algorithm-type questions. For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.
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 on…
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.
Earlier quoted context omitted.
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 th…
"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