3 ms·

Don't do it. Silicon Valley is more favorable for the inexperienced, in part because they are a blank slate that can be more easily coached. His interviewing sk

Don't do it. Silicon Valley is more favorable for the inexperienced, in part because they are a blank slate that can be more easily coached. His interviewing skills could be too notch regardless of number of years of professional experience. On top of that, there is a huge bias with interviewers to expect much more interview performance from those with more years of experience. The local industry favors the young in so many ways. Also, don't forget about the cost of living. With 140k per year salary, about 10 percent of that (for me) was money that didn't go to taxes or bills. I have 15 years of experience (and I look young). It's definitely a different kind of experience, so if you're feeling adventurous, do it! Just don't expect it to be fun, and be sure to do your own homework on whether there is a realistic market for a company's product if it's a startup (especially if it is Pre-Series-B). And, for the love of all that is good, don't work for any CEO under age 25. They are probably not the next Mark Zuckerberg.

candiodari 9y ago
If you want those offers, most of those companies are more than happy to fly you out for an onsite interview. Get 3 San Francisco weekends out of your onsites, and see if you can get this kind of pay. Practice basic algorithms. The guys at these firms aren't nearly as smart as they think they are so you can comfortably stop after part III of the "Introduction to Algorithms" (the R. Rivest one) book (which is about 1/3 of the actual book, but like half the text is exercises, so in total this is like maybe 150 normal pages of theory, which you can condense down to 3 really dense ones, which is a good exercise by itself. Make sure to have actually written those data structures in C++ or Java (Python if you must), with tests, and if you want to ace, with benchmarks. Of course you could super-plus ace and get to part 6 or so) And yes, the "real" way to learn software engineering is not a good way to ace these interviews. The author and maintainer of 10 years of a VM system you guys all know about, who codes and designs circles around the best engineer you've ever heard of failed the big G interview (also good enough that using some connections managed to get that reversed and an offer extended anyway). Like most jobs, it's not about actual ability, it's about knowing the "magical" bit of theory that doesn't matter in practice, but is effectively a lock on the door. Every last bit of it you can find extensive explanations on youtube for. Don't get distracted :). There's also a free coursera course. If you don't want to follow the time schema on coursera, download the course videos on piratebay. Oh and for academic CS candidates. Please do remember: Stanford is a LISP school, not a Haskell school. If in any book you're training for these interviews with you see the words "dependant typing", you immediately slam the book shut and make SURE you don't open it again until after the interview. Sad, but you use that stuff, your interviewer won't understand and you'll get dinged. Yes, really. Don't go into theory that you can tell your interviewer doesn't know about beyond "oh yes, I know about some stuff relating to x". DO NOT talk for 40 minutes about advanced theory your interviewer doesn't understand. Oh and one last thing. Give a small amount of thought to how you appear to others. You might be the best engineer on the planet, but if your interviewers all write that on the feedback form, they'll pass on you. You may have 10 years of experience and get interviewed by a 2 months hire (usually 2 years, but 2 months can happen). If you proceed to shout at the guy about how his person being there disrespects you ... things won't go well. Be friendly, be approachable. Talk about your cat, but for 5 minutes at most (not for 50). Also, you can get a small plus next to your name by asking to get referred.
- ChicagoDave 9y ago
  I’d fail all of these interviews. I have never worked like an “engineer”. My brain takes information from many channels, I let it congeal, then I create solutions. This means that I’m terrible at algorithms and patterns, but highly creative with real-world solutions. I believe companies need both kinds of technical people (drone and creative), but I’ve only been in a few places that actually understand that.
  - candiodari 9y ago
    The only solutions you need to come up with are things that closely resemble the answers to questions in the book I mentioned.

candiodari 9y ago

If you want those offers, most of those companies are more than happy to fly you out for an onsite interview. Get 3 San Francisco weekends out of your onsites, and see if you can get this kind of pay. Practice basic algorithms. The guys at these firms aren't nearly as smart as they think they are so you can comfortably stop after part III of the "Introduction to Algorithms" (the R. Rivest one) book (which is about 1/3 of the actual book, but like half the text is exercises, so in total this is like maybe 150 normal pages of theory, which you can condense down to 3 really dense ones, which is a good exercise by itself. Make sure to have actually written those data structures in C++ or Java (Python if you must), with tests, and if you want to ace, with benchmarks. Of course you could super-plus ace and get to part 6 or so) And yes, the "real" way to learn software engineering is not a good way to ace these interviews. The author and maintainer of 10 years of a VM system you guys all know about, who codes and designs circles around the best engineer you've ever heard of failed the big G interview (also good enough that using some connections managed to get that reversed and an offer extended anyway). Like most jobs, it's not about actual ability, it's about knowing the "magical" bit of theory that doesn't matter in practice, but is effectively a lock on the door. Every last bit of it you can find extensive explanations on youtube for. Don't get distracted :). There's also a free coursera course. If you don't want to follow the time schema on coursera, download the course videos on piratebay. Oh and for academic CS candidates. Please do remember: Stanford is a LISP school, not a Haskell school. If in any book you're training for these interviews with you see the words "dependant typing", you immediately slam the book shut and make SURE you don't open it again until after the interview. Sad, but you use that stuff, your interviewer won't understand and you'll get dinged. Yes, really. Don't go into theory that you can tell your interviewer doesn't know about beyond "oh yes, I know about some stuff relating to x". DO NOT talk for 40 minutes about advanced theory your interviewer doesn't understand. Oh and one last thing. Give a small amount of thought to how you appear to others. You might be the best engineer on the planet, but if your interviewers all write that on the feedback form, they'll pass on you. You may have 10 years of experience and get interviewed by a 2 months hire (usually 2 years, but 2 months can happen). If you proceed to shout at the guy about how his person being there disrespects you ... things won't go well. Be friendly, be approachable. Talk about your cat, but for 5 minutes at most (not for 50). Also, you can get a small plus next to your name by asking to get referred.

ChicagoDave 9y ago
I’d fail all of these interviews. I have never worked like an “engineer”. My brain takes information from many channels, I let it congeal, then I create solutions. This means that I’m terrible at algorithms and patterns, but highly creative with real-world solutions. I believe companies need both kinds of technical people (drone and creative), but I’ve only been in a few places that actually understand that.
- candiodari 9y ago
  The only solutions you need to come up with are things that closely resemble the answers to questions in the book I mentioned.