Live data from Hacker News

Lessons from a Silicon Valley job search

robertheaton.com

251–260 of 289 posts

Re: Lessons from a Silicon Valley job search

#251

Earlier quoted context omitted.

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, th…

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 bo…

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.

Re: Lessons from a Silicon Valley job search

#252
post #162

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.

Re: Lessons from a Silicon Valley job search

#253
post #244

Earlier quoted context omitted.

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, th…

> 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 develop…

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.

Re: Lessons from a Silicon Valley job search

#254

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.

Well, then you missed out on the date rape joke halfway through. Unnecessary additions to an otherwise good article.

I was about to reply "nonono it's not a date rape joke" but then I realised that the word "violent" in "violent sexual abuse" means it actually could easily be taken as one. I only meant to joke about receiving unpleasant messages on a dating site, which is probably not fun, but I think is generally OK to joke about. On the other hand, date rape is not OK to joke about. I've changed "violent" to "aggressive", which I think keeps the same tone I was going for but removes the ambiguity.

Re: Lessons from a Silicon Valley job search

#255
post #214

Earlier quoted context omitted.

Binary search requires random access. Things that support random access can be used as lists, but not all lists support random access.

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 impo…

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.

Re: Lessons from a Silicon Valley job search

#257
post #43

Earlier quoted context omitted.

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.

Re: Lessons from a Silicon Valley job search

#258
post #246

Earlier quoted context omitted.

> 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 spee…

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.

Re: Lessons from a Silicon Valley job search

#259
post #81
post #50

"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).

Thank you! But: I'm sure we did some things wrong or sucky. If you can think of any, I'd love to hear them; you can reply here if you like. :)

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.

Re: Lessons from a Silicon Valley job search

#260
post #91

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 th…

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.
Post reply on HN