I interviewed at six top companies in Silicon Valley in six days • Hacker News Board

Re: I interviewed at six top companies in Silicon Valley in six days

#431

Post by slimshady94 » Sat, Jan 19, 2019, 2:02 AM UTC

rossdavidh wrote: post #291

When I was a new college grad, I felt trapped by the fact that everywhere I looked they wanted several years of experience, and I had none yet. How can I get experience if it's required to get the job? Now that I am 51, I feel annoyed that all of these stories of interviews involve asking questions about algorithms that rarely come up in real coding, and if they do you should NOT be rolling your own code, you should…

Reiterating my view, I feel like the interviewing grind has become akin to gymming - you go to your mental gym, build up your 'muscles' by doing pointless repetitive tasks AKA algorithms you'd never use in real life (probably like how bodybuilders would never need to deadlift 125kgs in their daily life). It doesn't directly help you do your job but you know bodybuilders have higher than average fitness levels. So in the same manner, devs grinding leetcode probably have higher 'fitness' levels (mostly a type of muscle memory for programming) than devs who don't.

Re: I interviewed at six top companies in Silicon Valley in six days

#432

Post by mrburkins » Sat, Jan 19, 2019, 2:07 AM UTC

LaserToy wrote: post #399

cornellwright wrote: post #320

Earlier quoted context omitted.

Is BFS really that hard, especially if the interviewer is willing to talk it out with you and doesn't care a lot about finding the most efficient solution possible? I've been out of college more than 10 years now, do a mix of hardware and software (so am not coding all day everyday) and I can hack together algorithms like BFS if I spend a couple of minutes thinking about it. I get that there are many awful interviewe…

Bfs is just one of examples. I can ask you a question you will not be able to answer without knowing the answer. There is a reason it took researchers years to find those optimal solutions

That always struck me as odd, testing aptitude by memorizing others hard won knowledge.

Who could really solve these problems, error free, on the spot with no prior exposure to underlying concepts?!?

Re: I interviewed at six top companies in Silicon Valley in six days

#433

Post by sjg007 » Sat, Jan 19, 2019, 2:08 AM UTC

opportune wrote: post #378

jsmeaton wrote: post #352

Earlier quoted context omitted.

Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.

Is it possible to even get into software architecture without pretty significant experience? From my experience in the workplace anybody making purely architectural decisions without having to implement them is a team lead or higher in the organizational architecture.

Yes it is possible.

Re: I interviewed at six top companies in Silicon Valley in six days

#434

Post by SamReidHughes » Sat, Jan 19, 2019, 2:08 AM UTC

theoh wrote: post #416

SamReidHughes wrote: post #372

Earlier quoted context omitted.

If you can't handle simple data structures problems you need to stay far, far away from software architecture.

That depends on what is meant by software architecture. If you mean the structuring of a system to achieve good or (particularly) consistent worst-case performance, maybe you are right. But if architecture is used to mean the design of a system to satisfy users (and present a clean, extensible, meaningful interface) then it's really a conceptual job that has more to do with design skills than optimized algorithms.

Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely.

It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.

Re: I interviewed at six top companies in Silicon Valley in six days

#435

Post by QML » Sat, Jan 19, 2019, 2:08 AM UTC

opportune wrote: post #413

LearnerHerzog wrote: post #408

Earlier quoted context omitted.

The Field of Dreams approach. "If you build it, they will come"

Really, that's not far from the truth. If you've worked at other well known "good" companies and worked on hot/important stuff, and that info is on linkedin, you will probably get approached by a google recruiter at some point. And unless you fuck up your call with them to make sure you're interested and a real person, that basically guarantees you a first round technical phone screen, which is the hardest part of ge…

Does this method still bypass the algorithms interview? It seems like it only gets your foot in the door, which is probably the harder part for most.

Re: I interviewed at six top companies in Silicon Valley in six days

#436

Post by cableshaft » Sat, Jan 19, 2019, 2:09 AM UTC

perl4ever wrote: post #245

Permit wrote: post #131

Earlier quoted context omitted.

> Companies need to admit that only trying to hire a single type of person is not going to work. Why? It's not so clear to me that it's not working right now. These companies seem to be doing completely fine. If hiring programmers who aren't good at programming puzzles is a competitive edge, I would expect to see other companies hiring these programmers and succeeding. It seems more likely to me that there is (at mos…

"If hiring programmers who aren't good at programming puzzles is a competitive edge, I would expect to see other companies hiring these programmers and succeeding." You're begging the question. Other companies do hire people who are excluded by a certain class of employer, and that's exactly why some get outraged by the types of quizzes that are used. The difference between the standards creates cognitive dissonance…

> If, by analogy, you deal in second hand cars, it's a reasonable business model to buy virtually any car so long as the price is right and you know who to sell it to.a

Very good analogy. And true. My dad used to own a used car dealership back in the day. He bought pretty much anything he could get for a good price that was in decent shape. If he only bought cars that were in perfect shape, he'd have pretty much no cars on his lot.

And I've worked for companies whose bosses are so damn picky about who they hire that they would go without hiring a single person even after conducting hundreds of interviews themselves over six months, as the rest of us were struggling to keep up with the workload.

It got so bad one time the higher ups eventually had a recruiter just pick a few people and said "Here, these are your new employees. Get them up to speed." and he just had to accept it.

Re: I interviewed at six top companies in Silicon Valley in six days

#437

Post by vonmoltke » Sat, Jan 19, 2019, 2:09 AM UTC

rock_hard wrote: post #342

rossdavidh wrote: post #291

When I was a new college grad, I felt trapped by the fact that everywhere I looked they wanted several years of experience, and I had none yet. How can I get experience if it's required to get the job? Now that I am 51, I feel annoyed that all of these stories of interviews involve asking questions about algorithms that rarely come up in real coding, and if they do you should NOT be rolling your own code, you should…

This all comes down to what the company is optimizing for. Everybody here seems to assume they are trying to filter for the good candidates...but what they are actually trying to do with these kind of interviews is filter out the bad ones! Because the damage when hiring a bad candidate is much higher than the damage from missing out on a good one!

> Because the damage when hiring a bad candidate is much higher than the damage from missing out on a good one!

I get that this is the conventional wisdom in a subset of this industry, but in my experience this "truth" does not have as much objective support as the people who keep repeating it think it does.

Re: I interviewed at six top companies in Silicon Valley in six days

#438

Post by joshuamorton » Sat, Jan 19, 2019, 2:10 AM UTC

mehrdadn wrote: post #427

joshuamorton wrote: post #418

Earlier quoted context omitted.

This is such a cop out. It took millennia to invent 0. That doesn't mean that 0 is an exceedingly difficult concept to grasp.

I don't understand your comment. Was the parent suggesting BFS (or the like) is an exceedingly difficult concept to grasp? And if we're going to claim understanding BFS is like understanding zero, then wouldn't that just mean it's just as silly to complain about a question on BFS as it is to complain about a question on zero?

Yes, my understanding is that the parent comment is complaining that since it took people with phds years to derive an algorithm for the first time, that we should never expect anyone to implement one in an interview.

But, as with a concept like 0, making the cognitive leap to understanding that there should be a way to represent the lack of something is counterintuitive (indeed, consider Tony Hoare's billion dollar mistake. The "right" way to represent the absence of an object is a hard problem). However, once you've been exposed to it, it's not particularly challenging to rederive the necessary pieces.

So yes, complaining about BFS is, imo, akin to complaining about being asked what the result of the arithmetic operation `35 - 12 - 23` is.

Re: I interviewed at six top companies in Silicon Valley in six days

#439

Post by bradleyjg » Sat, Jan 19, 2019, 2:10 AM UTC

ergothus wrote: post #311

rossdavidh wrote: post #291

When I was a new college grad, I felt trapped by the fact that everywhere I looked they wanted several years of experience, and I had none yet. How can I get experience if it's required to get the job? Now that I am 51, I feel annoyed that all of these stories of interviews involve asking questions about algorithms that rarely come up in real coding, and if they do you should NOT be rolling your own code, you should…

I share both of your concerns (while I was very lucky in getting initial experience, I know of other beginners that haven't/arent, so I'm very sympathetic.) . Started coding for work in '95. > was I wrong then? Or am I wrong now? Perhaps both. Neither, I think. The Algorithm interviews are bad for 90% of the positions out there, and experience matters much more than trivia, so you were right then. And today, everyone…

It turns out that interviewing is hard, and we don't know what works well. Most of us think "we" are the ones that can obviously see what's wrong and everyone else is interviewing poorly. Most of us are wrong.

Cowen’s Second Law: There is a literature on everything. Hiring is no different. Why do so many of us that say “of course you shouldn’t reimplement timsort, stand on the shoulder of giants” either make up an interview process based on gut feeling or cargo cult one based on what we heard google does?

Re: I interviewed at six top companies in Silicon Valley in six days

#440

Post by sn41 » Sat, Jan 19, 2019, 2:12 AM UTC

SamReidHughes wrote: post #372

jsmeaton wrote: post #352

Earlier quoted context omitted.

Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.

If you can't handle simple data structures problems you need to stay far, far away from software architecture.

Not really, not at all. Software architecture is a lot about wisdom - how to anticipate future changes. Often user interfaces need to be carefully and gently designed so that the user has no surprises. Diligence from the user should not be assumed, the user interface must emphasize tricky parts and make choices less onerous, etc. Scalability is preferrably achieved by simple code + hardware/vms rather than overoptimized code which depends on "irreplaceable" programmers - what if they fall sick, or leave the company? etc. I think all of this is experience accrued over many years, and with facing many failures.

I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.