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

21–30 of 289 posts

Re: Lessons from a Silicon Valley job search

#21

Post by tbrownaw »

davidddavidson wrote: post #12
nappy-doo wrote: post #3

sigh Unless your nomenclature is all screwed up, and you're confusing arrays and lists, finding an element in a sorted list takes O(N) time -- binary search doesn't work on lists. I do a lot of interviewing (at my company). Here's other common misconceptions lots of candidates have: * Quicksort is O(N^2) -- don't make that mistake. * There are plenty of "faster than O(NlogN) sorting algorithms, but they're all specia…

I think you are confusing your nomenclature. The term "list" does not necessarily imply that it is a linked list.

Binary search requires random access. Things that support random access can be used as lists, but not all lists support random access.

Re: Lessons from a Silicon Valley job search

#22

Post by donretag »

"Flying out to interview with a single company is easy - they pay for the flights and hotel and you use them. Interviewing with 7 companies made for a surprisingly stressful round of negotiation before I’d even arrived, as I tried to spread the cost according to who could most afford it and who was getting the most time with me."

When I last was searching for an out-of-state (albeit not California) job, every company was adamant about arranging all the flight arrangements. It was very clear they did not want me to interview at other companies during the time. Even after I agreed to pay my own way, they still insisted on paying and have me fly out immediately after the interview. The stress of multiple flights during my short interview period definitely affected my performance.

Re: Lessons from a Silicon Valley job search

#23

Post by yukichan »

> the fact that Hashes have O(1) lookup time is often a great way to speed up an algorithm.

In practice I have learned that being CPU bound will turn things around faster than paging and thus for things that involve a sufficiently high number for n I prefer to avoid hashes and O(1) "speed ups." The less I store in memory the better, especially on servers that handle lots of requests simultaneously, at least for servers that aren't meant to be a memory store like memcache or redis.

Re: Lessons from a Silicon Valley job search

#24

Post by tegeek »

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

I can do time complexity etc. I know about compilers, trees, graphs & other shit data structures and I can read academic papers on any new shit with a comfortable head. I can learn any new imperative, oop or functional language in a week.

But I still can't find a job in Google.

Re: Lessons from a Silicon Valley job search

#25

Post by MichaelTieso »

I never really know what to do during negotiation time. During the first interview, I'm usually asked how much. I'm told that I should always try to push it back for the other person to make the first offer. However in matter how hard I try, they demand that I make the first offer. I don't want to aim too high or too low in fear that I'd lose out on the opportunity.

Re: Lessons from a Silicon Valley job search

#26

Post by tbrownaw »

baby wrote: post #18

> “Design the infrastructure for a link-shortener.” I'm wondering how to answer that? * Get a short and memorizable url. * When you enter an URL hash it, put it in a hash table and use the hash for the link. > “If I type https://google.com into my browser and press enter, what happens?” How would you guys answer this one? I'm not sure I've enough knowledge to do that. I'd say: * first TLS handshake thanks to RSA to s…

There's also the DNS lookup and the CRL lookup (or is there a newer replacement to CRLs?).

Re: Lessons from a Silicon Valley job search

#27

Post by mercurial »

baby wrote: post #18

> “Design the infrastructure for a link-shortener.” I'm wondering how to answer that? * Get a short and memorizable url. * When you enter an URL hash it, put it in a hash table and use the hash for the link. > “If I type https://google.com into my browser and press enter, what happens?” How would you guys answer this one? I'm not sure I've enough knowledge to do that. I'd say: * first TLS handshake thanks to RSA to s…

No DNS resolution?

As for the link shortener infrastructure, I'd ask for more context to get a better idea of the scope. If there is not more context than that, define the scope at which you're operating (eg, "I understand 'infrastructure' as 'the structure of the service' and not as 'the physical infrastructure'" and define yourself what the URL shortener does (going with "a web service with a single endpoint" sounds reasonable to me). It's really important to understand what you're trying to achieve first, especially when faced with a real problem.

Re: Lessons from a Silicon Valley job search

#28

Post by recursive »

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

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.

You should know enough to avoid doing nested loops to find the intersection of two lists. Things like that come up on a regular basis for me, although I don't work at any tech giant.

Re: Lessons from a Silicon Valley job search

#29

Post by kevincrane »

donretag wrote: post #22

"Flying out to interview with a single company is easy - they pay for the flights and hotel and you use them. Interviewing with 7 companies made for a surprisingly stressful round of negotiation before I’d even arrived, as I tried to spread the cost according to who could most afford it and who was getting the most time with me." When I last was searching for an out-of-state (albeit not California) job, every company…

I had the opposite impression. I tried to cram 4 interviews into a week so I wasn't constantly flying away from school and every company was more than happy to pay less to fly me out. One company paid for my flight there, one for the return trip, and two lucky places got off paying nothing at all (I had places already lined up with friends nearby to crash at so no one insisted on buying hotel rooms).

Re: Lessons from a Silicon Valley job search

#30

Post by steven2012 »

How is your H1B still valid after you lost(?) your job and left the country? H1B is tied to an employer and a specific job, so I don't know how it's still active. Are you sure that your H1B hasn't expired yet? If you try to enter on an expired H1B, you might get banned from entering for 10 years (this happened to my friend 6 months ago) so make sure your immigration status is rock solid.
Post reply on HN