Lessons from a Silicon Valley job search • Hacker News Board

Re: Lessons from a Silicon Valley job search

#201

Post by mattmanser » Wed, Mar 19, 2014, 11:40 PM UTC

ahomescu1 wrote: post #177

mattmanser wrote: post #155

Earlier quoted context omitted.

Again, what's the point of having a tool you never use? I have had to implement a sort once in 10 years of professional programming, it was in IE6's painfully slow js to fix a slow table sort. More than most. I didn't do a CS degree, the people around me with CS degrees didn't know the answer. I googled it. After the 15 minutes it took to find and implement it I mentioned it to one of the CS people, he promptly reele…

It's not about "sorting" or any particular algorithm, it's about whether you're actually considering the costs and tradeoffs of the code you're writing (which is actually a big part of software engineering), and are equipped to handle those. Now, one cost is execution time, another is memory usage, another is development time, another is maintenance effort and so on. These costs are spread across different domains, b…

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, those tools, is useless and we know it is. You could fill volumes about the cock ups and bad code caused by premature optimisations.

A for each. That's what you'll use 80% of the time, a for 20% and your algos 0%, for all intents and purposes.

Re: Lessons from a Silicon Valley job search

#202

Post by rhizome » Thu, Mar 20, 2014, 12:00 AM UTC

recursive wrote: post #200

rhizome wrote: post #193

Earlier quoted context omitted.

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…

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.

Re: Lessons from a Silicon Valley job search

#203

Post by capkutay » Thu, Mar 20, 2014, 12:03 AM UTC

jarjoura wrote: post #167

capkutay wrote: post #135

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

"Having a big-tech company on my resume has done nothing but send an endless stream of recruiters knocking on my door"

I know plenty of people who didn't work at a Google/Apple/Facebook with an endless stream of recruiters chasing them. Maybe you have the type of background they're being paid to chase after.

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

If I hired the wrong person, 'well they worked at google' is a poor explanation for the hiring mistake. I'm sure working at Google can play to your advantage for higher level career goals and some people have done amazing things at Google. I just think people are over-estimating it.

Re: Lessons from a Silicon Valley job search

#204

Post by tptacek » Thu, Mar 20, 2014, 12:06 AM UTC

rpicard wrote: post #192

tptacek wrote: post #81

Earlier quoted context omitted.

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

Hey, I'll be out there next week; I'm in SFBA all of next week.

So: see you there. :)

Re: Lessons from a Silicon Valley job search

#205

Post by chetanahuja » Thu, Mar 20, 2014, 12:07 AM UTC

pkteison wrote: post #157

petenixey wrote: post #5

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

What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome person on a team at your last job and just goof off all day and now put everything that guy did on your resume? I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can…

I'll addressing two things from your post 1) is there a better way and 2) show me the defect that you fixed.

1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company.

What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz.

2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.

Re: Lessons from a Silicon Valley job search

#206

Post by danielweber » Thu, Mar 20, 2014, 12:11 AM UTC

jw2013 wrote: 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.

Re: Lessons from a Silicon Valley job search

#207

Post by fayyazkl » Thu, Mar 20, 2014, 12:34 AM UTC

petenixey wrote: post #5

(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 matters which area / programming environment are we talking about in general.

Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability.

And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well.

But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point.

Or that your linear traversal should dramatically improve if you could code and use a hash table instead.

Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.

Re: Lessons from a Silicon Valley job search

#208

Post by fayyazkl » Thu, Mar 20, 2014, 12:47 AM UTC

mpeg wrote: post #9

sergiotapia wrote: post #8

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.

Why? Do Google or Facebook engineers live in a magical world in which they need to know off the top of their heads the big-O complexity of every possible sort function ever mentioned in an academic paper? I see this argument used time and time again, but it makes no sense to me. Surely they can just search for it when they need it too :)

You might be working in a scenario where you can't just look those things up. You have to code them through. Learning them then through general concept AND THEN implementing is too much. For instance, if you work in the embedded domain, you won't have the liberty to use public / standard / open source libraries.

Re: Lessons from a Silicon Valley job search

#209

Post by Sukotto » Thu, Mar 20, 2014, 12:55 AM UTC

pkteison wrote: post #157

petenixey wrote: post #5

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

What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome person on a team at your last job and just goof off all day and now put everything that guy did on your resume? I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can…

One way to approach this is to say something like: "I have a selection of (simplified) problems we've faced recently. They're representative of the sorts of issues you would be taking care of if you join our team. Let me walk you through them one at a time and we can discuss. We'll start just by verbally going over them, then either move to a whiteboard or to a workstation to dig into them a little deeper.

The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done."

Imho, there are only three things you really need to know about the candidate:

1) Will this person fit into the current team with the minimum of fuss?

2) Can this person do the job professionally and in a timely way?

3) Is hiring this person a financial risk we're willing to take?

Re: Lessons from a Silicon Valley job search

#210

Post by jussij » Thu, Mar 20, 2014, 1:11 AM UTC

fayyazkl wrote: post #207

petenixey wrote: post #5

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

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

I've got ~36000 hours of professional programming behind me and like you, there have been many a time where initial testing has highlighted a performance issues.

So out comes the hash table, the binary search, the double checking of the memory allocations or the some new index on the SQL table.

Now I know Big O tries to formalise these sort of things (or at least I hope that is the case), but is knowing the answers to these Big O questions that important?

Since I have Engineering degree I certainly can’t give a credible answer to a Big O question, but I have absolutely no trouble fixing sluggish code.

> But you should be able to recognize that a design

Unfortunately, at a lot of the places I've worked, not much time is ever allocated to design :(

Managers seem to want easy to read, high level, non technical design documents to take to their managers meetings and once those are approved they then want something coded ready for QA.