Live data from Hacker News

Lessons from a Silicon Valley job search

robertheaton.com

211–220 of 289 posts

Re: Lessons from a Silicon Valley job search

#211

I built an app for tracking job applications... amazing how many people just do this on a spreadsheet (as per point 2.3 of the post), which is fine, but I needed an excuse to build something, so http://applyee.com

nice... i recoil at spreadsheets for similar tasks too but must confess that i usually find a text file with a couple special delimiters sufficient / am lazy enough to convince myself that such a text file is sufficient. both could just as well be imported into a database/app later, but i find that text is more free-form and easier to work with than spreadsheets.

decided not to open source it?

Re: Lessons from a Silicon Valley job search

#212

Earlier quoted context omitted.

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

Hey, I'll be out there next week; I'm in SFBA all of next week. So: see you there. :)

Oh that's great! I was bummed that I wasn't going to get a chance to meet you after all of that interviewing.

Re: Lessons from a Silicon Valley job search

#213

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

I think this might be a case where you cross that company off the list for being unreasonable. You don't want to work in the type of environment if that's typical policy.

Re: Lessons from a Silicon Valley job search

#214

Earlier quoted context omitted.

I think you are confusing your nomenclature. The term "list" does not necessarily imply that it is a linked list.

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 important (although i suppose that it's important that it not be difficult). what i can see taking some skill/experience (which i totally don't have) is knowing a bunch of algorithms and being able to consider the time/space tradeoffs of the algorithms you already know quickly. being able to prove the time-complexity of some new algorithm is good, but, sadly, perhaps, i don't think most companies hire people to do that.

Re: Lessons from a Silicon Valley job search

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

Some links are here https://news.ycombinator.com/item?id=7325545 I really wish I had had a chance to read that before my interview. Knowing what the interviewer is going for when you are coding helps tremendously.

Thanks so much! That really helps.

Re: Lessons from a Silicon Valley job search

#216

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

re: do you know how to actually name functions and variables well (unbelievably important)

It's also subjective and can be taught. If I asked people to name some functions in an interview, what would I really learn?

Similarly, the other things you mention, while important, don't seem particularly testable. They don't give me anything I can give to the hiring committee to back up my answer.

Actually learning something real about a stranger in 45 minutes is pretty hard. Asking them to solve a problem means you can have a technical conversation in front of a whiteboard. It doesn't answer much but it does let me know whether it will be worthwhile asking the candidate to help me solve a tricky problem, or whether they'll be coming to me for help all the time. After all, ideally I'm looking to hire someone smarter than me.

Re: Lessons from a Silicon Valley job search

#217

Earlier quoted context omitted.

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…

While it seems like you're moving goalposts, this example also appears to be something a person could know without touching on nested loops or O(n) at all. Case in point, 10s of Googling produced this link: http://stackoverflow.com/questions/2831212/python-sets-vs-li... ...and I don't even use Python yet.

Is it possible to write working code without understanding O()? Definitely.

Is it helpful to understand? Definitely.

Re: Lessons from a Silicon Valley job search

#218
I actually have an interview with Google in a week or so, and I'm absolutely terrified. After some reflection, I realized that I'm not afraid of not getting the job - I like my current job and wouldn't mind staying. I'm fundamentally afraid of failure - of being unable to do well on the problems and having the interviewers think I'm stupid. It's so silly, because I'll likely never see these people again, and I should be confident enough in myself and my abilities to not let their opinions affect me at all, but there it is. What if I can't make heads or tails of the weird binary search problem they give me? What if I get confused (I ALWAYS get confused) trying to manipulate a linked list? What if I get sent home after the first one or two interviewers? What if this reflects poorly on the Googler who recommended me?

I feel like a coward for being afraid of this stuff.

Anyways, I just wanted to get that off my chest.

Re: Lessons from a Silicon Valley job search

#219
post #172

Earlier quoted context omitted.

> why do you believe it? The opposite of a seller is a buyer. Do you think an employee is better described as being a buyer? > In many ways your employer is much more like Walmart than you will can be. This is the commodity situation I mentioned. Try being a farmer for a while and see what it is like selling your crops. You'll then know exactly what I'm talking about. If you are just another person that is easily rep…

> Do you think an employee is better described as being a buyer? No, I'm asking why you see yourself as a seller-like-Walmart, which is a subtype of seller who freely offers a public fixed price in advance of negotiations (if any.) It's entirely normal to negotiate for different kinds of things in different ways... And your labor is quite different from anything Walmart sells. > If you don't even know how much your t…

> I'm asking why you see yourself as a seller-like-Walmart

I see myself as a seller, and sellers have largely chosen the fee up front model because it is more efficient.

If you need an income of $150K per year for your time, you're probably not going to find many who really wanted to offer you $200K, and you're probably going to deal with a lot of people who only want to offer you $50K. Why would you want to spend potentially months or years in talks with people who cannot afford you just to finally find the gem who wants to pay you even more? Setting your price at $150K gets you talking with people who will pay you that much.

Even if you managed to get an offer $50K above your hidden asking price, does that justify the time spent finding it when you consider average employment terms? You cannot look for work for free. It is actually quite expensive.

I will add that setting yourself apart means, well, doing that. You shouldn't even consider doing what other people are doing anyway if you agree with me on the premise of not wanting to become a commodity.

> If the company also can't price the tasks they need finished, how is anyone else (i.e. the employee) supposed to know?

Does it matter? People selling their employable services tend to price them by the hour, day, month, or year. If the project costs $100K or $1B, it doesn't really matter from your perspective, unless you are concerned about the well-being of the investing party – but that is a risk even with low costs.

Re: Lessons from a Silicon Valley job search

#220

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

For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times. Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it mat…

> i have had to worry about O(n) to choosing Hash tables, quiet a lot of times.

I know, I am constantly concerned about sorting that list of 100 items!

Post reply on HN