Live data from Hacker News

Lessons from a Silicon Valley job search

robertheaton.com

161–170 of 289 posts

Re: Lessons from a Silicon Valley job search

#161
post #18

> “Design the infrastructure for a link-shortener.” 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 s…

> How would you guys answer this one? 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 (protoco…

Can you recommend how to learn this? I don't work with the web or networking, and would like to shore up that part of my knowledge. Are there any good books that gives the high-level overview of it all?

Re: Lessons from a Silicon Valley job search

#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?

Re: Lessons from a Silicon Valley job search

#163
post #119

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? 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 li…

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

Re: Lessons from a Silicon Valley job search

#164

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

On your first bullet, naming functions and variables, I think that is important, sure but I think, and this may be blasphemy, that it is a little overblown. Many would make that seem like the most important thing but I think you can be a competent programmer and a valuable without being great at naming. For one, it is very subjective. You may think 10 compound words resulting in 100 character variable name, ala Java or .NET, makes perfect sense, while others think it is ridiculous. Also, I'm not sure I think "technical debt" is a real thing. If you have not dealt with complexity or algorithms then you may not be doing the kind of programming many other people are doing. Also, as a programmer, if you don't know basic algorithms and data structures, for me all the knowledge of what is hip is not a great substitute. But I can agree with a lot of what you're saying here.

Re: Lessons from a Silicon Valley job search

#165

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 don't think interviewing candidates based on basic knowledge of CS is cargo-culting Google and Facebook. I think this predates those two companies. Also, someone that implements hashCode() correctly and can't spout off how a linked list works, is a problem for me. I guess it is subjective.

Re: Lessons from a Silicon Valley job search

#166

Earlier quoted context omitted.

This is purely anecdotal however I've been doing Rails dev (and prior to that Javascript, PHP and even Matlab) for 14 years and I have only a vague grasp how most of that list works. 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 ne…

Maybe you've been lucky? Being forced down the stack seems to happen either when you need more performance, or when stuff blows up. 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.

That's not the stuff that typically goes wrong.

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.

Re: Lessons from a Silicon Valley job search

#167

As someone who has both looked for engineering jobs and also staffed engineers on my team in silicon valley, I'd suggest people to be a little less shallow about their employers. 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 ga…

I call bullshit on this one. Having a big-tech company on my resume has done nothing but send an endless stream of recruiters knocking on my door. Doesn't make getting a final offer any easier, but it has definitely improved my chances of getting the interview I want vs. just any old interview.

I always hear "Well if Google/Apple/FB are willing to hire you..."

Re: Lessons from a Silicon Valley job search

#168

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

Re: Lessons from a Silicon Valley job search

#169

> If a company is currently worth $10m, options for 0.1% are worth $10k. 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 also think that an individual employee needs to put a discount on options because you don't have the ability to diversify, your risk profile is vastly different than the investors, and the founders presumably have effective veto over exits which allows them to capture more of the value in a middle of the road outcome like a acquihire.

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.

Re: Lessons from a Silicon Valley job search

#170
post #94
post #71

If you're Mexican/Canadian, a TN Visa might be a better option than H1B since there's no annual limit. 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.…

I may be wrong, but I believe that interviewing in the US while you're on a tourist visa/ESTA (presumably your case?) constitutes "seeking immigrant status" and is unlawful. You may want to avoid posting about it in public forums where your identity can be easily traced.

You are (mostly) wrong. A job interview is a perfectly legitimate activity to undertake on a B-1 (business) status. I have done it more than once. At immigration, they ask the purpose of your trip; you say, "job interview;" and they stamp your passport with B-1 (business) rather than B-2 (tourist). It really is as simple as that.
Post reply on HN