Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from a Silicon Valley job search

robertheaton.com

Post reply on HN
Print view View original

221–230 of 289 posts

Re: Lessons from a Silicon Valley job search

#221

Post by thedufer »

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…

> In 13,000 hours I have had to wrestle with the consequences of O(n) complexity

That is what I would expect someone who has had to wrestle with big-O problems but didn't recognize them to say. I honestly don't know what you're working on if its actually true. I had a time complexity issue just this week. On front-end code, no less. I probably work on an issue involving time complexity once a month, if not more often.

Re: Lessons from a Silicon Valley job search

#222

Post by thedufer »

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

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…

> Also, I'm not sure I think "technical debt" is a real thing.

Can you explain what you mean by this? Are you not familiar with the term, or do you not believe it exists?

Re: Lessons from a Silicon Valley job search

#223

Post by rhizome »

recursive wrote: post #217
rhizome wrote: post #202

Earlier quoted context omitted.

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.

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

Re: Lessons from a Silicon Valley job search

#224

Post by thedufer »

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…

Working at a big-name tech company definitely makes you more marketable. It won't help you much, if at all, in the interview, but it will absolutely help you get your foot in the door. "If Google hired him, he's worth an interview" is a fairly rational thing to say, and a lot of employers say it.

So if your resume is lacking, that's not a bad reason to take a job. If your resume is already getting you interviews regularly, a job at Google might not help you much in your next job search.

Re: Lessons from a Silicon Valley job search

#225

Post by donw »

CodeMage wrote: post #187
spiralpolitik wrote: post #138

Earlier quoted context omitted.

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…

> You need people who know how to find the answer to such questions. You can't look for an answer if you don't know what question to ask. This has to do with that whole "conscious competence learning matrix" stuff, more entertainingly described by Steve Schwartz as "shit you know, shit you know you don't know and shit you don't know you don't know" [1]. The purpose of interview questions about algorithms and data str…

I disagree.

Asking algorithm trivia questions will tell you nothing about whether or not the candidate can apply that knowledge in the real world.

A large part of what I do involves coming into teams that are struggling with delivery, and helping them get back onto the path of productivity.

More than once, I have had developers that could (and have) leave and easily pass a Google interview. They knew more about computer science than I probably ever will.

And in many of these cases, the code they wrote was actively harmful. Unreadable, tangled messes, that nobody else on the team could unwind.

Knowing how and when to use monads, or bloom filters, or any number of other fun tools separates the supermen from the mere humans.

But before you need to care about that, there are more fundamental concepts that matter. Like being able to write readable code that conveys intent, knowing how to write tests that are flexible yet specific, and so on.

Re: Lessons from a Silicon Valley job search

#226

Post by mgkimsal »

RogerL wrote: post #160
mgkimsal wrote: post #78

Earlier quoted context omitted.

"For the most part, barring a minority of highly specialized high-level positions, engineering ability trumps computer science knowledge." +1

That is what gets me about these interview questions. I know a lot of very clever people. I am carefully differentiating 'clever' from 'smart', by the way. So many that are superficially fast and smart about solving whiteboard problems are terrible at all the things that actually seem to matter when it comes to creating value: * Keeping a project on budget and schedule * being able to create a budget * managing peopl…

+1, and a bit more.

Yes... I ran a small group where we all got too inward focused being clever in our code and optimizations, all the while ignoring (for various reasons) that we had less income each month, and eventually folded.

I've since seen this firsthand at a couple other companies, on the inside and outside, where engineering types get way too focused on trying to hyperoptimize for a theoretically possible scenario X, while ignoring real world tickets that are costing them customers daily. They don't seem to realize that... when enough days pass, and enough customers leave, there is no more money to pay them.

Having lived through a couple failures (personal and professional), it's probably easier for me to spot these behaviors (again, because I used to do it myself). In my case, I wish I'd had someone early on beat that out of me - I simply wasn't aware of what was going on. As much as you can say "people have to learn for themselves", I don't believe that's the right attitude to take when the fate of a dept or company rides on what you're doing - too many other lives are involved.

This is in reaction to your 'budget' stuff above - I don't expect people to be Excel/Quickbooks/Peachtree gurus nor CPAs, but understand that you have to get stuff out, on time, and sometimes have to choose your battles and put out less than optimal code, then have a plan to address the known shortcomings.

I agree too on the CS adapting to engineering being more rare than engineering adapting to CS.

Re: Lessons from a Silicon Valley job search

#227

Post by iskander »

typon wrote: post #129
sergiotapia wrote: post #11

Earlier quoted context omitted.

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

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.

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

Re: Lessons from a Silicon Valley job search

#228

Post by fayyazkl »

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…

Depending upon what sort of industry and scale you write code for, very often, it is a HUGE part.

I accept the point that over optimizing is the root of all evil and the rest of the philosophy along those lines. But knowing algorithms and data structures inside out, because where and when you have to choose what - i doubt one can be called a programmer without all that.

And i would say again, i am yet to find some body renowned, who has made their mark as a programmer, and doesn't regard all of this stuff high enough.

Having said all that, if you work in a high level language and develop client facing / application layer desktop/web related stuff - and not involving too much scaling, you won't need these things most of the times. But if not, you can't live with out these.

Lastly, since college and probably since learning to program, the best of the breed usually were the guys who went on to acm and top coder kinda stuff. It is true that building products is not synonymous, but it definitely plays an undeniable part albeit i must agree that it is slightly over valued, nothing else.

Re: Lessons from a Silicon Valley job search

#229

Post by fayyazkl »

jussij wrote: post #210
fayyazkl wrote: post #207

Earlier quoted context omitted.

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

I sort of agree to most. Being able to write recurrence out of master theorem is never kind of thing really needed here. Even if you know conceptually the running time of a loop (nested ones etc.) and be able to apply that practically is sufficient.

Ah... yeah for the design statement :) i can't say much beyond that for most of the companies with established practices - you have to write a design document, often down to the level of writing data structures and function names - run through debates with others to justify your choices BEFORE you can even start to write first line of code.

I understand this partially because of being in Embedded, C/C+ domain where you can literally shoot yourself in the foot due to wrong choices and often product models are different.

E.g. at one place that i worked, code reviews and conventions were very rigid, some what more than say Linux kernel, because the product was an RTOS and associated stacks, which were sold to companies WITH SOURCE since the customers were actually developers developing end applications using our APIs. So even one comment not written according to company's coding convention often won't pass a peer code review - but i believe this is a pure exception rather than the norm.

Re: Lessons from a Silicon Valley job search

#230

Post by thedufer »

randomthought wrote: post #194
aboveandbeyond wrote: post #67

Earlier quoted context omitted.

It's actually O(1). It's (N * (N+1))/2

what about (n (n+1)/2) n^2 ? .

He interpreted it as "the time complexity of computing the sum of the numbers from 1 to n", which using the formula you just gave takes O(1) time.
Post reply on HN