Live data from Hacker News

Lessons from a Silicon Valley job search

robertheaton.com

261–270 of 289 posts

Re: Lessons from a Silicon Valley job search

#261

I'm not a programmer, but...I would want to work with this programmer in a heart beat. Smart, respectful, strong boundaries but not a jerk. A lot to learn from him for everyone on Hacker News, not just the devs. Congrats to him on the new job and the H1B visa and to Stripe for hiring him. He seems to really deserve it.

And he's 25. I know that's not super young but he speaks with a tone that makes me think he is more experienced than his age would let on.

Re: Lessons from a Silicon Valley job search

#262
post #89

Earlier quoted context omitted.

The thing is, that 0.1% would probably be better off just looking for a Math PhD. I suspect it is much easier to teach a mathematician C (Or Python/Haskell/OCaml/Java) than a programmer real math.

The problem is that Math PhDs tend to be arrogant and think that programming is for monkeys and they are above that. Code that they produce tends to be sub-par and under-tested (because they are above writing unit-tests). Source: worked with multiple Math PhDs. Have a few friends who are Math PhD working on some esoteric problems that I could not understand.

They can do the algorithms, but they don't engineer, imho.

Re: Lessons from a Silicon Valley job search

#263

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

> Im constantly surprised that none of the resumes I get mention anything about the applicants character or professional demeanor.

What in the actual fuck. What do you expect to see? "I am clean and not a raging asshole"?

Re: Lessons from a Silicon Valley job search

#264

Earlier quoted context omitted.

There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. For many software roles I'd much rather have someone who can write clear, maintainable, and performant code first, with deep knowledge of CS fundamentals only a requirement depending on the nature of the role and product.

There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. Augh, PTSD trigger.

The one thing that you have to remember is that no one wants to write bad, unmaintainable code.

Re: Lessons from a Silicon Valley job search

#265
post #211

I built an app for tracking job applications... amazing how many people just do this on a spreadsheet (as per point 2.3 of the post), which is fine, but I needed an excuse to build something, so http://applyee.com

nice... i recoil at spreadsheets for similar tasks too but must confess that i usually find a text file with a couple special delimiters sufficient / am lazy enough to convince myself that such a text file is sufficient. both could just as well be imported into a database/app later, but i find that text is more free-form and easier to work with than spreadsheets. decided not to open source it?

Curious what you find wrong about using a spreadsheet for this? I've used it a couple of times in the past when I had lots of applications and interviews going and found it worked rather well. It doesn't really use spreadsheet capabilities (except for adding up number of interviews or success rate maybe) but I didn't find anything wrong with it.

Re: Lessons from a Silicon Valley job search

#266

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

Have you ever had to wrestle with the consequences of the complexity of analyzing a not-so-simple-and-well-researched data structure for which no generic implementation exists in any language?

Re: Lessons from a Silicon Valley job search

#267

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

Algorithmic trivia questions are designed to bias an "objective" recruitment process towards recent graduates who have just revised all that stuff for their exams. It's a way to sneak ageism past HR.

Re: Lessons from a Silicon Valley job search

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

> “If I type https://google.com into my browser and press enter, what happens?”

well, it closes the circuit in the enter key causing the electrons to move...

Re: Lessons from a Silicon Valley job search

#269
post #225

Earlier quoted context omitted.

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

Who said anything about trivia? Asking trivia is pointless and any company dumb and/or lazy enough to base their interviews on trivia deserves the bad hires.

While we're at it, who said anything about monads and bloom filters? The former aren't really data structures or algorithms, the latter would hardly qualify as "the most fundamental data structures".

Also, I don't remember saying anything about the irrelevance of writing readable code and flexible-yet-specific tests.

In short, you're certainly disagreeing, but apparently not with me.

Re: Lessons from a Silicon Valley job search

#270

Earlier quoted context omitted.

Again, what's the point of having a tool you never use? I have had to implement a sort once in 10 years of professional programming, it was in IE6's painfully slow js to fix a slow table sort. More than most. I didn't do a CS degree, the people around me with CS degrees didn't know the answer. I googled it. After the 15 minutes it took to find and implement it I mentioned it to one of the CS people, he promptly reele…

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 seems to me that people with 10+ years of experience have more empirical evidence what is actually needed/useful. Your comment and other similar ones sound to me as textbook material which is abstract and correct in principle but not exactly how it is when you spend some time in industry.
Post reply on HN