Lessons from a Silicon Valley job search • Hacker News Board

Re: Lessons from a Silicon Valley job search

#241

Post by recursive » Thu, Mar 20, 2014, 6:21 AM UTC

rhizome wrote: post #223

recursive wrote: post #217

Earlier quoted context omitted.

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

Of course, but neither was your point. You were rebutting that algo & bintree knowledge are unnecessary in the vast majority of companies, in favor of the pursuit of O(n) knowledge in candidates. None of your examples validated this, and "should" became merely "helpful."

I suppose I considered it reasonable to consider things that are helpful should be done.

Re: Lessons from a Silicon Valley job search

#242

Post by randomdata » Thu, Mar 20, 2014, 6:26 AM UTC

MichaelGG wrote: post #199

randomdata wrote: post #90

Earlier quoted context omitted.

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

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

I think where you are going with this is that if you don't know what binary search is, you won't recognize when you need it, which sounds quite logical, but experience has suggested it doesn't actually play out like that in the real world.

> is it OK if they don't know the properties of arrays since they can look it up?

I think so. For the vast majority of software being written, the only thing you do need to understand is the language's interface to arrays, which are usually presented as abstract collections. The idea of a collection is something that transcends beyond programming and computers and is understood by basically everyone. When the time comes that you do need a lower-level understanding, you can look it up quickly and efficiently.

A effective practice for writing efficient software is lazy loading, and I believe it works well for humans too. I might be willing to accept that it is a skill that not all people have taken the time to acquire, however.

Re: Lessons from a Silicon Valley job search

#243

Post by nbm » Thu, Mar 20, 2014, 6:35 AM UTC

jerf wrote: post #146

danellis wrote: post #68

Earlier quoted context omitted.

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

I sort of hope someday to be in an interview where they ask that question. I'm pretty sure I could go an hour straight on it. Possibly two. Obviously, they won't let me. But still, it ought to be fun... I'll probably get stopped somewhere around the CPU trying to figure out which layer of cache the kernel's event handler is in, if not before....

Come interview at Facebook for a Production Engineering position[1]. I bet you your interviewers will push you at least that far or I'll give you a free lunch[2]. Even if it's just for the interview experience.

[1] I work there and love it. My contact details on my user page. [2] I'll give you a free lunch either way. No purchase required. Void where prohibited.

Re: Lessons from a Silicon Valley job search

#244

Post by toast0 » Thu, Mar 20, 2014, 6:43 AM UTC

mattmanser wrote: post #201

ahomescu1 wrote: post #177

Earlier quoted context omitted.

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, 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 development, so you should have some idea of how things are used.

> Secondly most programs never get stressed so it was a complete waste of time.

What are you working on? Everything I've worked on that has users could go faster. It doesn't take that much complexity to get something that takes 100 ms; and making that take 50 ms instead is an easily perceptible difference.

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

You could fill volumes about the cock ups and bad code caused by completely garbage performance because people didn't stop to think about how to do things right. Simple things like reducing the number of round trips to the database, or avoiding calculations until you know you need them could be called premature optimizations or just doing the job right. Having knowledge of algorithms (and knowing what algorithms are likely to underly the abstraction layers you're using) helps you avoid writing code that will blow up.

Re: Lessons from a Silicon Valley job search

#245

Post by toast0 » Thu, Mar 20, 2014, 7:03 AM UTC

oinksoft wrote: post #234

temuze wrote: post #196

Earlier quoted context omitted.

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

Sure, but why TCP and not UDP? Why threads and not processes? Why a web server and not a mail server? Why ports instead of sockets? The list you made is a decent baseline for somebody doing web development, but a smart person programming in another domain could easily pick up any of these things.

TCP is more complex than UDP. UDP is really just I pick my local ip and port, and send to your remote ip and port, and hope you get it. TCP has handshaking, acks, flags, resets, etc; a lot more to go wrong. Anyway, understanding DNS means understanding UDP too.

I've seen a lot of things in HTTP land that I wouldn't have been able to figure out without tcpdump. The most exciting thing is that livehttpheaders doesn't always tell the whole truth. :( But also subtle things like (TCP) load balancers mungling option fields, forged reset packets (and determining from whence they may have come), weird packet corruption.

Yes, absolutely I don't expect people coming from an offline world to know the internet stuff... but who's really offline these days?

Re: Lessons from a Silicon Valley job search

#246

Post by softr » Thu, Mar 20, 2014, 7:18 AM UTC

randomdata wrote: post #242

MichaelGG wrote: post #199

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

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

Re: Lessons from a Silicon Valley job search

#247

Post by skolter1 » Thu, Mar 20, 2014, 8:32 AM UTC

anonymouse64 wrote: post #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…

I was in an identical position 3 weeks ago and I shared some of your concerns as well. I can tell you that it seems scarier than it really is once you're in it. You shouldn't be worried about getting 'stuck', I did a number of times and quite often would get hints and directions from the interviewer. Never give up, even if what you know you don't know the answer right away, let the interviewer see that you're thinking and try to engage a discussion.

And really just try to take it easy. I was also under a bit of pressure, but think of it like an experience, even if you end up not passing. It's just another company and the feedback of 5 random people.

Re: Lessons from a Silicon Valley job search

#248

Post by watwut » Thu, Mar 20, 2014, 8:45 AM UTC

temuze wrote: post #35

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…

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

Just about the only two things I ever encountered from your list are threads and web server. I work on web applications, but details of TCP, ports and ethernet are simply too low to be of any practical use.

Re: Lessons from a Silicon Valley job search

#249

Post by watwut » Thu, Mar 20, 2014, 8:58 AM UTC

conanbatt wrote: post #73

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…

I am now fairly involved in my company's interview process and Im constantly surprised that none of the resumes I get mention anything about the applicants character or professional demeanor. For all the fear of being "culturally unfit" for a company, highlighting what kind of role you play and how you interact with your coworkers is fundamental. Are you diligent and consistent with your work? Are you the kind of per…

I am hardworking and very consistent with my work. My communication with coworkers is always friendly and respectful. I am able to point out mistakes and faults without hurting the person I'm talking to.

There you go, what did you learned about me?

If you base your hiring on what people wrote about their own personality, you will hire plenty of great salesmen. They will all be able to guess what the boss might like and generate nice sounding sentences to him.

They can still be poisonous jerks. And if they do, they will be perfectly able to hide the toxic culture they created from you.

Re: Lessons from a Silicon Valley job search

#250

Post by robheaton » Thu, Mar 20, 2014, 9:29 AM UTC

MichaelDickens wrote: post #186

You applied to 25 companies and got responses from 17? That seems like an extraordinarily high response rate. Your process sounds pretty normal, but my understanding is that most people who follow a similar process get a much lower response rate. Why do you think this is?

If I was guessing, I'd say that I very consciously made my CV/cover letter/blog "intriguing". I'm an OK programmer, but at the moment my strength is probably that I have a diverse list of fairly wacky and mostly unrelated other stuff that I've done. I think this meant that a lot of companies who would otherwise have passed straightaway were at least curious enough about the guy on the other end of this application to talk.

I should point out that after a Skype or 2, most of said speculative companies did realise that whilst founding a clothing company that makes sweatshirts with pictures of fruit on them is cool, it doesn't really help you write Clojure when you don't have any functional programming experience ;)

Of course, it could just be something boring like the fact that companies really need Ruby guys at the moment.