4 ms·

Facebook reaches out to me every few months and don't have a degree. I don't have the time or patience to study for their fresh-out-of-cs-grad style interview p

Facebook reaches out to me every few months and don't have a degree. I don't have the time or patience to study for their fresh-out-of-cs-grad style interview process though so only go with companies that test for what actually happens on the job vs in a text book, of which there are plenty.

akhilcacharya 9y ago
You can't beat the RSUs
- autotune 9y ago
  Even if true you can still beat a hundred other things like not having to be on-call, base pay, location (remote vs Manlo Park/ManFrancisco or being senior enough for their alternate locations), and lack of Test Driven Development (feel free to prove me wrong here). It's far easier to get a fat base pay somewhere sensible that knows how to manage a remote team, where you can then live in a low COL area or with better housing and cultural options, than to deal with bureaucratic nonsense for the chance of cashing out a few extra dollars in a few years in a high COL area where you don't have a life outside of work for that time, IMHO.
- fizwhiz 9y ago
  (cough) Google (cough)
wutbrodo 9y ago
Honestly, my best guess for why this kind of interview is used is that it's just an intelligence test. It's worked extremely well for me: I'm very upfront about the fact that I don't expect them to _know_ anything (it would probably be tough for me to do something as simple as Dijkstra's on a whiteboard under time pressure), but that I want to see how they think. I recently had a guy with an incredibly impressive resume and a couple decades of experience, and I gave him the same interview. He clearly thought he did badly since he couldn't go through the white board coding as smoothly as a recent cs grad would, but in my book he got a 9/10, because he was obviously good at clearly thinking about creative problem solving. Now I can't speak to whether large companies universally treat these interviews the way I do, but as a sample of one, when I conducted interviews for Google I certainly did. You shouldn't let your assumptions about the interview process color your decisions so heavily.
- autotune 9y ago
  Yeah and that's fine, you probably get enough candidates willing to grind through it anyway if you're at The Big 4. Interviewing is a two-way street though so obviously I am going to have it color my decision process. I want to know what challenges actually happen on the job and if I can solve those challenges, and if you ask me to code up a shortest path algorithm on a whiteboard but that never appears on the job, then it seems like a pointless test to me. Compare this to other companies, both large and small who have asked more reasonable challenges such as; "set up MySQL master/slave replication," "write a script that parses a text file in Python," "build a 2-tier architecture through terraform," "troubleshoot these issues on a broken server." Obviously these aren't as fancy as "implement an algorithm on a whiteboard," but it shows me as a candidate/potential candidate what type of problems to expect on the job. As a DevOps person I don't believe in whiteboarding for interviews, nor do I believe it should be a thing for devs, but if a company prefers to interview with this method like Facebook and Google (have received study material for both), I'll continue to focus on the companies who are practical about interviewing instead as it's worked out fine so far for my career path.
  - wutbrodo 9y ago
    > Compare this to other companies, both large and small who have asked more reasonable challenges such as; "set up MySQL master/slave replication," "write a script that parses a text file in Python," "build a 2-tier architecture through terraform," "troubleshoot these issues on a broken server." See to me, these are _terrible_ interview questions because they reward memorization and rote knowledge and completely leave aside the kind of creative problem-solving skills that I've always needed from my employees and colleagues. I've had the misfortune to work with people hired by the process you describe, and they tend to suck pretty hard. If you want cogs that can't adapt beyond their very narrow comfort zone, you've just described exactly how to get them. I agree with your description of the two-way street, but I generally take care of that by leaving time for the candidate to ask questions, generally guided a little by me to give them an idea of the stack we work on, what kind of problems generally need solving, etc. (In fact, I warned the 9/10 guy that I described above that he may not be challenged enough by the work that we'd likely have for him).

akhilcacharya 9y ago

You can't beat the RSUs

autotune 9y ago
Even if true you can still beat a hundred other things like not having to be on-call, base pay, location (remote vs Manlo Park/ManFrancisco or being senior enough for their alternate locations), and lack of Test Driven Development (feel free to prove me wrong here). It's far easier to get a fat base pay somewhere sensible that knows how to manage a remote team, where you can then live in a low COL area or with better housing and cultural options, than to deal with bureaucratic nonsense for the chance of cashing out a few extra dollars in a few years in a high COL area where you don't have a life outside of work for that time, IMHO.
fizwhiz 9y ago
(cough) Google (cough)

wutbrodo 9y ago

Honestly, my best guess for why this kind of interview is used is that it's just an intelligence test. It's worked extremely well for me: I'm very upfront about the fact that I don't expect them to _know_ anything (it would probably be tough for me to do something as simple as Dijkstra's on a whiteboard under time pressure), but that I want to see how they think. I recently had a guy with an incredibly impressive resume and a couple decades of experience, and I gave him the same interview. He clearly thought he did badly since he couldn't go through the white board coding as smoothly as a recent cs grad would, but in my book he got a 9/10, because he was obviously good at clearly thinking about creative problem solving. Now I can't speak to whether large companies universally treat these interviews the way I do, but as a sample of one, when I conducted interviews for Google I certainly did. You shouldn't let your assumptions about the interview process color your decisions so heavily.

autotune 9y ago
Yeah and that's fine, you probably get enough candidates willing to grind through it anyway if you're at The Big 4. Interviewing is a two-way street though so obviously I am going to have it color my decision process. I want to know what challenges actually happen on the job and if I can solve those challenges, and if you ask me to code up a shortest path algorithm on a whiteboard but that never appears on the job, then it seems like a pointless test to me. Compare this to other companies, both large and small who have asked more reasonable challenges such as; "set up MySQL master/slave replication," "write a script that parses a text file in Python," "build a 2-tier architecture through terraform," "troubleshoot these issues on a broken server." Obviously these aren't as fancy as "implement an algorithm on a whiteboard," but it shows me as a candidate/potential candidate what type of problems to expect on the job. As a DevOps person I don't believe in whiteboarding for interviews, nor do I believe it should be a thing for devs, but if a company prefers to interview with this method like Facebook and Google (have received study material for both), I'll continue to focus on the companies who are practical about interviewing instead as it's worked out fine so far for my career path.
- wutbrodo 9y ago
  > Compare this to other companies, both large and small who have asked more reasonable challenges such as; "set up MySQL master/slave replication," "write a script that parses a text file in Python," "build a 2-tier architecture through terraform," "troubleshoot these issues on a broken server." See to me, these are _terrible_ interview questions because they reward memorization and rote knowledge and completely leave aside the kind of creative problem-solving skills that I've always needed from my employees and colleagues. I've had the misfortune to work with people hired by the process you describe, and they tend to suck pretty hard. If you want cogs that can't adapt beyond their very narrow comfort zone, you've just described exactly how to get them. I agree with your description of the two-way street, but I generally take care of that by leaving time for the candidate to ask questions, generally guided a little by me to give them an idea of the stack we work on, what kind of problems generally need solving, etc. (In fact, I warned the 9/10 guy that I described above that he may not be challenged enough by the work that we'd likely have for him).