Lessons from a Silicon Valley job search

Re:Lessons from a Silicon Valley job search by sergiotapia on Wednesday March 19, 2014 @10:49AM (#7428937)

They deal is data volumes so large and so interconnected, it can't hurt to know those sort of things. Surely you agree?

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by typon on Wednesday March 19, 2014 @02:58PM (#7430885)

Unless you're being hired a PhD Senior Software Designer, there is exactly 0% chance (in 2014 anyway) that you're going to be working on improving Google's PageRank algorithm.

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by iskander on Wednesday March 19, 2014 @11:28PM (#7433645)

I was a lowly software engineering intern at Google and spent most of my summer writing MapReduce jobs which would traverse (1) every document in a large index of the web or (2) every book Google has scanned. Even worse, I sometimes needed to compute correlations between pieces of text in the documents. So, not only was the input size huge, the work per document was non-trivial. The remarkable thing about this sort of gig is how utterly unremarkable it is in a large tech company. If there's anything to Big Data beyond hype it's the commoditization of previously incomprehensibly large computations...and everyone doing computation on that scale should at least know the basic language of reasoning about time/space/communication complexity. You don't necessarily need to know the official jargon (though it helps to concisely describe ideas), but you should at least be able to think about how much extra work your program does for each additional input item (and how much extra storage it needs, and how network bandwidth it will eat up).

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by rhizome on Wednesday March 19, 2014 @01:32PM (#7430327)

Except the thing is that these companies already have established internal libraries and tooling that implement "these sort of things," to a large degree and insulate the business needs from new hires such that any given hire's O(n) skills are not going to touch them until they get put on the task.

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by doctorcroc on Wednesday March 19, 2014 @11:05AM (#7429076)

Agree, but what you described is something that can be googled and quickly learned, whereas all the intangibles op listed should be second-nature.

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by MichaelGG on Wednesday March 19, 2014 @12:52PM (#7430007)

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.

When your project calls for a certain performance bound, will you flail around or have some idea what you're looking for?

1: "Guess my number between 1 and 100!"

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by randomdata on Wednesday March 19, 2014 @01:16PM (#7430217)

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.

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by MichaelGG on Wednesday March 19, 2014 @07:37PM (#7432668)

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?

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by randomdata on Thursday March 20, 2014 @02:26AM (#7434192)

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

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by softr on Thursday March 20, 2014 @03:18AM (#7434294)

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.

[ Parent | on HN ]

Re:Lessons from a Silicon Valley job search by randomdata on Thursday March 20, 2014 @09:10AM (#7435271)

> You can't solve a problem if you don't know what a particular algorithm do for you.

I'm sure anyone who is a CS researcher would disagree with you, but I'm probably taking your point out of context.

> I have seen java developers knowing only ArrayList and nothing else in the collection.

And I have seen a full-fledged computer science graduate, from a top school for CS, use MS Access for everything, including projects that had nothing to do with databases, because he didn't know how to use any other tools, and didn't appear to have the know-how to take full advantage of that specific environment. Bad programmers are bad programmers.

> In numerous forums, people ask for code because they don't know what the problem is. In which case, even search can't help.

Technically speaking, isn't that still a search? The only difference to using Google is that the results are indexed by humans instead of machines. I think this further emphasizes that most people really can recognize when they need a new tool and can find the right one on demand with very little trouble.

And, like I said, I am willing to believe that it is a skill that is acquired. Skills, by nature, come with varying degrees of ability. Perhaps the least skillful stand out most predominantly in your mind? The best are probably so good at it that you don't even realize that they are doing it.

[ Parent | on HN ]