Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from a Silicon Valley job search

robertheaton.com

Post reply on HN
Print view View original

191–200 of 289 posts

Re: Lessons from a Silicon Valley job search

#191

Post by gedrap »

MichaelTieso wrote: post #25

I never really know what to do during negotiation time. During the first interview, I'm usually asked how much. I'm told that I should always try to push it back for the other person to make the first offer. However in matter how hard I try, they demand that I make the first offer. I don't want to aim too high or too low in fear that I'd lose out on the opportunity.

The truth is, no (decent) company will reject you because you asked high but reasonably high. For some people it might mean that 'hey he must be good, if can asks that much and has no problem with employment!'. Social proof goes a loooong way. So don't worry.

Personally, I research what is a 'standard' pay in that geographical area and then add ~15%. Nothing to lose, a few thousands to win :)

Re: Lessons from a Silicon Valley job search

#192

Post by rpicard »

tptacek wrote: post #81
mac1175 wrote: 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. :)

Heading out to Mountain View for an on-site interview with Matasano next week. So far the process has been great for me too. It has been challenging but they (tptacek and co.) still manage to do a great job of moving things along quickly.

Hopefully I don't scare them off after they've flown me out (and I've spent 16 hours on planes and in airports).

Re: Lessons from a Silicon Valley job search

#193

Post by rhizome »

recursive wrote: post #184
rhizome wrote: post #174

Earlier quoted context omitted.

So, is that really knowing "enough" to avoid the things you mention, or can the heuristic be that you should know the standard library?

There are things built into some standard libraries that are able to be combined in a way that produces a list intersection, but that are O(n^2). I prefer working in high level languages as much as the next person, but there's no substitute for knowing basic algorithms and data structures.

I just demonstrated a substitute for knowing basic algorithms and data structures.

Re: Lessons from a Silicon Valley job search

#194

Post by randomthought »

aboveandbeyond wrote: post #67
gregors wrote: post #56

"sum of the numbers from 1 to N is O(N^2)" 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.

It's actually O(1). It's (N * (N+1))/2

what about (n(n+1)/2) n^2 ? .

Re: Lessons from a Silicon Valley job search

#195

Post by temuze »

Dewie wrote: post #147
temuze wrote: post #35

Earlier quoted context omitted.

I think most interviews don't focus enough on systems. I expect every software engineer to know: - 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!).

Do you work with Internet/Web technologies? That list seems slanted towards that kind of gig.

I do :)

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!

Re: Lessons from a Silicon Valley job search

#196

Post by temuze »

oinksoft wrote: post #111
temuze wrote: post #35

Earlier quoted context omitted.

I think most interviews don't focus enough on systems. I expect every software engineer to know: - 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!).

It's funny how the things you know well always happen to be the bare minimum of what you expect from others. Then you learn something else and hopefully realize that yourself of yesteryear still managed to write good, maintainable software, but that your current self would consider the old self a charlatan. Lists like these reflect your own experience. I care more if an engineer can quickly grasp the "big ideas": May…

Yeah, but low level systems stuff isn't anything that's going to change anytime soon. My operating systems professor had been teaching that class for years!

If you write code, you should know what your code is running on. You should understand some of the layers of abstraction or at least be curious about them! Even if it's not related to your job, you shouldn't take the magic underneath for granted.

I see a big correlation between programmers who take a lot of this stuff for granted with cargo cult programmers - people who tend to think of things as "if I do x, y comes out" instead of "if I do x, this will trigger y, which causes z".

Re: Lessons from a Silicon Valley job search

#197

Post by melindajb »

I'm not a programmer, but...I would want to work with this programmer in a heart beat. Smart, respectful, strong boundaries but not a jerk. A lot to learn from him for everyone on Hacker News, not just the devs.

Congrats to him on the new job and the H1B visa and to Stripe for hiring him. He seems to really deserve it.

Re: Lessons from a Silicon Valley job search

#198

Post by logicallee »

Terr_ wrote: post #163
logicallee wrote: post #150

Earlier quoted context omitted.

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

You're completely missing the point. Yes, "seller" is a good word, but there are dozens of other paradigms for selling. 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?

I'm not missing anything. You quoted literally one line:

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

Re: Lessons from a Silicon Valley job search

#199

Post by MichaelGG »

randomdata wrote: post #90
MichaelGG wrote: post #72

Earlier quoted context omitted.

I highly doubt that someone that does not know what binary search is, that cannot think for a minute and come up with a small implementation, is going to "google and quickly learn" algorithms and the related thinking. The issue isn't if you can write on simple binary search (considering such a search is a intro-to-programming task[1], that should be a given), but if you have an understanding of the topic in general.…

I don't think it is difficult as you make it sound. The most difficult part is finding the term "binary search", but even that is not very difficult. All you have to do is generalize your problem and state it to Google. Binary search will almost invariably come up in the results. It even works for algorithms that are far more obscure.

My point isn't that if you don't know what binary search is then you're going to have a hard time doing a lot of algorithm searches. Just like if you didn't know what a linked list was, or a hashtable. Writing a hashtable or reasoning out the properties of a linked list, is not the kind of thing you should need to look up. It should be easy to talk it out during an interview.

These are basics. Same for strings, too. A programmer should be able to decisively explain how strings work in their language. Where do you draw the line? Arrays are just another data structure, is it OK if they don't know the properties of arrays since they can look it up?

Re: Lessons from a Silicon Valley job search

#200

Post by recursive »

rhizome wrote: post #193
recursive wrote: post #184

Earlier quoted context omitted.

There are things built into some standard libraries that are able to be combined in a way that produces a list intersection, but that are O(n^2). I prefer working in high level languages as much as the next person, but there's no substitute for knowing basic algorithms and data structures.

I just demonstrated a substitute for knowing basic algorithms and data structures.

Yes, you just demonstrated an example of a case where a developer is not hurt by not understanding algorithms or runtime complexity.

Here's one where they are: In python, the in operator works on both lists and sets. For one, large numbers of elements will perform very quickly. For the other, it will perform very slowly. If a developer doesn't understand how they work, and where it's appropriate to use each, they can still do something completely terrible without even straying away from basic APIs.

Post reply on HN