181–190 of 289 posts
Earlier quoted context omitted.
In SV you can at least feel like you're producing something, however silly. At a hedge fund you're just sucking capital all dracula style.
I don't see how a hedge fund is qualitatively different from a VC firm. They're both allocating investment dollars and hoping to make big money on the return.
"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…
You didn't have to board the return flight and you don't have to board the last companies' arrival flight. There, problem solved :-).
Earlier quoted context omitted.
Sexism is a problem in the tech world, but I think some people also just love to be offended. Bill Burr calls it being 'professionally outraged'.
How do you know sexism is a particular problem in the tech world? Unequal representation of some particular demographic group is not sufficient evidence for discrimination.
Earlier quoted context omitted.
Yes, exactly.
So, is that really knowing "enough" to avoid the things you mention, or can the heuristic be that you should know the standard library?
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…
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...
Earlier quoted context omitted.
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 th…
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? W…
> 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…
Can you explain more what you mean? 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 o…
(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…
then maybe you're not solving very challenging problems.