4 ms·

I don't want to turn this to a flame war but please. I've went through all FAAG (no engineering for N in EU). The interviews apart from never-ending seem to be

I don't want to turn this to a flame war but please. I've went through all FAAG (no engineering for N in EU). The interviews apart from never-ending seem to be stacking odds towards fresh graduates. Why else do all of them insist so much on grad level things such as complexities, basic algorithms etc? Regardless. I refreshed all that and more. But still there always seems to be a guy somewhere in this long way that will throw the odd question (open 'the Linux programmer interface' at a random page and shoot). I mean it is very easy to find a quirky question to ask and then use my flawed or 'I don't remember this off hand (but I can damn sure find it and understand it in 5 mins if you let me) to throw me out of the window. I've seen the same play at least 6 times (wannabe startups emulate this hiring process - if google does it then it must be correct). OTOH dunno - perhaps I just don't cut it. Perhaps the competition has been turbocharging while I was working. Dunno.

texasbigdata 6y ago
Or there were 30 people applying, it was hard to differentiate, so they kept asking marginal questions.
- nonines 6y ago
  That's the good scenario but after so many times one starts to wonder.
jakearmitage 6y ago
> but I can damn sure find it and understand it in 5 mins if you let me Precisely this. That's one of the key things from our "experience" and "seniority". We've seen things, we know how to be pragmatic and learn/relearn X to finish Y and deliver value. I'm yet to see an interview that covers this. I'm clinging to my current job because I'm not sure I can face the job market in my current age.
- urthen 6y ago
  I've done coding interviews for nearly 10 years now where I present a coding problem, but I never expect syntax correctness. I'll explicitly say I don't care if the function signatures are right or you remember the exact method to call on a given class or whatever; so long as I can tell what you're trying to make the program do. I have to look basic stuff up online every day anyway because nobody can remember it all, I'm not going to knock a candidate for that. Other than basic filtering questions so I can see if someone is trying to fake their way through an interview, I never ask functional specifics. Even then it's usually just to make sure they at least basically know everything they claim to on their resume - if you don't claim to know JS, I'm not going to ask you about what bind() does, but if you rate yourself a 10/10 JS expert, you should probably have a good answer. Interviews should be about your thought process and how well you can solve real world problems, not trivia about how well you've memorized an API. I don't understand why so many other interviewers (Even at companies I've worked for) ask coding "gotchas" and reject candidates because they don't remember the semantics of some obscure language feature.
  - nonines 6y ago
    To be fair most of the interviewers seemed to work along these lines that you describe. (That's why I managed to get quite close quite a few times - I was never big on memory so it's impossible get the details on WB). Yet, if the string of interviews is too long (and it is) the probability of hitting a "reef" is really big. And it seems that either you get a unanimous "yes" or you fail.
mabbo 6y ago
> insist so much on grad level things such as complexities, basic algorithms etc Because they matter. Basic level complexities, algorithms, data structures, are all important for being a developer. That's why it's part of the undergraduate curriculum! You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. > open 'the Linux programmer interface' at a random page and shoot Yeah, the heck with that interviewer. I mean, if you're interviewing for a low level systems dev job then I can see making sure the dev has some basic familiarity with important functions, but it's hard to see that making sense on a general developer interview. I hope that wasn't my company.
- mrbgty 6y ago
  > You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. That one time a year when it's critical, I would want someone who is likely to engage on the rest of the team to come up with a solid solution together and spend at least a day thinking about it. This isn't how interviews work so if you think you're selecting for that one time a year when its critical at the expense of the rest of the year, I don't think you're getting what you think you are. For quick workarounds to deal with a critical error while allowing time to solve it properly, I think an experienced person may have an edge.
  - mabbo 6y ago
    I see your point, but interviews are tame compared to the real world. It's not about "Can the candidate solve this mission critical problem we'll spend a week on, in an hour?". It's more like "Can the candidate recognize a graph problem?". If they can't even tell that this is a graph problem, how are they going to know that today is the day we need to ask someone for help, and think about this very hard? An example: Many times I've asked something like Word Ladder[0] to a candidate, and they can't tell that this is a shortest path problem, nor use the common tools to solve such things. Even with hinting and helping as much as I can, sometimes they just don't have those tools in their toolbox. And my job is to find out whether they do or not. [0]https://leetcode.com/problems/word-ladder/ https://leetcode.com/problems/word-ladder/ and no, I don't use this exact question.
yowlingcat 6y ago
Sorry that your experience went poorly, but I'd still recommend not giving up. As someone who was trying for the better part of four years and finally made my way in a few years ago, here are a couple of my thoughts: 1) Utilize leverage and numbers. Reputable 1st party company recruiters as well as hiring marketplaces like Hired[1], and TripleByte[2] and AngelList[3] could become trusty tools for you. It'll be hard to get in front of recruiters at BigCos there, so you'll also want to make sure your LinkedIn[4] is up to date. Get a premium account and actively get in touch with BigCo recruiters. Connect with them and see how many are willing to have an unstructured conversation with you about your location in your career, your goals, and the possibility of working at BigCo. I know recruiters get a bad rap, but the competent ones are worth their weight in gold and most importantly are paid to put you into the process. You want to get in front of as many companies as possible. There is very likely an upper limit on the amount of "nos" you'll have to hear before you get at least one yes. But, it takes a lot of time and energy to go through the ringer with more companies, even if it does work to your advantage. The most recent time I went through the process, there were a good 50 companies I had initial conversations with, maybe 20 were I got to the phone screen stage, 5 that I got to on-site and 2 offers. And, this time was easier than last time, which was even worse. The drop-off there was brutal, and I knew that for any given company, there was probably a 96% chance I was spending my time on something that ultimately wouldn't pan out. But I was also honing my interviewing technique and "was going to miss the shots I didn't take". Keep at it. Even with a 96% failure rate, after 50 shots, there's only a 12% chance that you don't get at least 1 offer. 2) BigCo FAANG recruiting processes reflect BigCo processes in general in that they're meant to minimize false positives, not false negatives. The upshot of this for you is that there can be a lot of luck involved with your interview. But another upshot if this is that your interview is so structured and well known that it is very doable to prepare directly for the interview -- even if you're preparing[5][6] in a way that is a little synthetic and doesn't really reflect your job experience. Try doing a mock interview with someone who works at a FAANG that covers an algorithm section and a system design section. See how well you genuinely do. Every time I'm back on the market interviewing, I'm surprised at how hard this stuff is and how much I need to ramp up my interviewing skills again. I don't expect that to ever change. 2) It's normal to have interviews completely tank because of bad luck. Sometimes this can happen across every BigCo you apply to. It happens. It took several years and stages of being on the market for me to finally end up at one after wanting to be there for a while. Don't give up. 3) Behavioral interview performance becomes increasingly important. One technique I used was to put all of my major projects I did on a spreadsheet, left to right over time, and then figure out the company values and add snippets top to bottom for the relevant projects about the ways that project reflected a specific company value. This sounds corny and artificial, but it made it much easier for me to give prepared, pointed, real examples of my proven ability to add value to the company. 4) Startup interviews are more freeform than big company interviews for better and worse. At worst, you'll have the worst part of BigCo interviews with none of the competence. At best, you'll have a process that feels thoroughly modernized and personalized -- you'll probably work through some kind of a problem or collaborative design exercise together with one of the few engineers at the company (or the CTO), and based on how well you gel, you get hired. You'll be as much interviewing them for whether you want to work with them as vice versa. Or, you'll be hired to consult and if that goes well they'll want to bring you on full time. These kinds of gigs can be great because you are likely to be the most quality, experienced talent that they can get access to by a long shot, and the door is open for you to take a leadership role here. From that role, the door is open for you to take on a leadership role at a BigCo if that's what you want long term. BigCos love hiring talent that has been proven by the crucible of success at startups that they otherwise would have passed on when that talent wasn't necessarily "proven" to that level yet. You can probably guess why. 5) Consulting is a great play for those who are very experienced. You can sell your experience and not your fungible labor. But it does take the development of sales and positioning skills. I've never had success here but I've seen friends who have. My take? The pattern I see with friends who are successful on this route is they don't do it alone. They take on opportunities with other folks they've worked well with in the past. Companies love this because they thoroughly cut out an organizational integration risk, which is of putting together two otherwise productive individuals that clash destructively rather than coordinate. Let me be the first to say please don't undersell yourself. Having been a hiring manager at a seed stage startup before my current role, I absolutely would have jumped on any candidates that fit your profile. In fact, I tried to, multiple times, and saw my firm passed over for a competing offer from another firm. [1]https://hired.com/ https://hired.com/ [2]https://triplebyte.com/ https://triplebyte.com/ [3]https://angel.co/ https://angel.co/ [4]https://www.linkedin.com/ https://www.linkedin.com/ [5]http://www.crackingthecodinginterview.com/ http://www.crackingthecodinginterview.com/ [6]https://www.rooftopslushie.com/ https://www.rooftopslushie.com/

texasbigdata 6y ago

Or there were 30 people applying, it was hard to differentiate, so they kept asking marginal questions.

nonines 6y ago
That's the good scenario but after so many times one starts to wonder.

jakearmitage 6y ago

> but I can damn sure find it and understand it in 5 mins if you let me Precisely this. That's one of the key things from our "experience" and "seniority". We've seen things, we know how to be pragmatic and learn/relearn X to finish Y and deliver value. I'm yet to see an interview that covers this. I'm clinging to my current job because I'm not sure I can face the job market in my current age.

urthen 6y ago
I've done coding interviews for nearly 10 years now where I present a coding problem, but I never expect syntax correctness. I'll explicitly say I don't care if the function signatures are right or you remember the exact method to call on a given class or whatever; so long as I can tell what you're trying to make the program do. I have to look basic stuff up online every day anyway because nobody can remember it all, I'm not going to knock a candidate for that. Other than basic filtering questions so I can see if someone is trying to fake their way through an interview, I never ask functional specifics. Even then it's usually just to make sure they at least basically know everything they claim to on their resume - if you don't claim to know JS, I'm not going to ask you about what bind() does, but if you rate yourself a 10/10 JS expert, you should probably have a good answer. Interviews should be about your thought process and how well you can solve real world problems, not trivia about how well you've memorized an API. I don't understand why so many other interviewers (Even at companies I've worked for) ask coding "gotchas" and reject candidates because they don't remember the semantics of some obscure language feature.
- nonines 6y ago
  To be fair most of the interviewers seemed to work along these lines that you describe. (That's why I managed to get quite close quite a few times - I was never big on memory so it's impossible get the details on WB). Yet, if the string of interviews is too long (and it is) the probability of hitting a "reef" is really big. And it seems that either you get a unanimous "yes" or you fail.

mabbo 6y ago

> insist so much on grad level things such as complexities, basic algorithms etc Because they matter. Basic level complexities, algorithms, data structures, are all important for being a developer. That's why it's part of the undergraduate curriculum! You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. > open 'the Linux programmer interface' at a random page and shoot Yeah, the heck with that interviewer. I mean, if you're interviewing for a low level systems dev job then I can see making sure the dev has some basic familiarity with important functions, but it's hard to see that making sense on a general developer interview. I hope that wasn't my company.

mrbgty 6y ago
> You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. That one time a year when it's critical, I would want someone who is likely to engage on the rest of the team to come up with a solid solution together and spend at least a day thinking about it. This isn't how interviews work so if you think you're selecting for that one time a year when its critical at the expense of the rest of the year, I don't think you're getting what you think you are. For quick workarounds to deal with a critical error while allowing time to solve it properly, I think an experienced person may have an edge.
- mabbo 6y ago
  I see your point, but interviews are tame compared to the real world. It's not about "Can the candidate solve this mission critical problem we'll spend a week on, in an hour?". It's more like "Can the candidate recognize a graph problem?". If they can't even tell that this is a graph problem, how are they going to know that today is the day we need to ask someone for help, and think about this very hard? An example: Many times I've asked something like Word Ladder[0] to a candidate, and they can't tell that this is a shortest path problem, nor use the common tools to solve such things. Even with hinting and helping as much as I can, sometimes they just don't have those tools in their toolbox. And my job is to find out whether they do or not. [0]https://leetcode.com/problems/word-ladder/ https://leetcode.com/problems/word-ladder/ and no, I don't use this exact question.

yowlingcat 6y ago

Sorry that your experience went poorly, but I'd still recommend not giving up. As someone who was trying for the better part of four years and finally made my way in a few years ago, here are a couple of my thoughts: 1) Utilize leverage and numbers. Reputable 1st party company recruiters as well as hiring marketplaces like Hired[1], and TripleByte[2] and AngelList[3] could become trusty tools for you. It'll be hard to get in front of recruiters at BigCos there, so you'll also want to make sure your LinkedIn[4] is up to date. Get a premium account and actively get in touch with BigCo recruiters. Connect with them and see how many are willing to have an unstructured conversation with you about your location in your career, your goals, and the possibility of working at BigCo. I know recruiters get a bad rap, but the competent ones are worth their weight in gold and most importantly are paid to put you into the process. You want to get in front of as many companies as possible. There is very likely an upper limit on the amount of "nos" you'll have to hear before you get at least one yes. But, it takes a lot of time and energy to go through the ringer with more companies, even if it does work to your advantage. The most recent time I went through the process, there were a good 50 companies I had initial conversations with, maybe 20 were I got to the phone screen stage, 5 that I got to on-site and 2 offers. And, this time was easier than last time, which was even worse. The drop-off there was brutal, and I knew that for any given company, there was probably a 96% chance I was spending my time on something that ultimately wouldn't pan out. But I was also honing my interviewing technique and "was going to miss the shots I didn't take". Keep at it. Even with a 96% failure rate, after 50 shots, there's only a 12% chance that you don't get at least 1 offer. 2) BigCo FAANG recruiting processes reflect BigCo processes in general in that they're meant to minimize false positives, not false negatives. The upshot of this for you is that there can be a lot of luck involved with your interview. But another upshot if this is that your interview is so structured and well known that it is very doable to prepare directly for the interview -- even if you're preparing[5][6] in a way that is a little synthetic and doesn't really reflect your job experience. Try doing a mock interview with someone who works at a FAANG that covers an algorithm section and a system design section. See how well you genuinely do. Every time I'm back on the market interviewing, I'm surprised at how hard this stuff is and how much I need to ramp up my interviewing skills again. I don't expect that to ever change. 2) It's normal to have interviews completely tank because of bad luck. Sometimes this can happen across every BigCo you apply to. It happens. It took several years and stages of being on the market for me to finally end up at one after wanting to be there for a while. Don't give up. 3) Behavioral interview performance becomes increasingly important. One technique I used was to put all of my major projects I did on a spreadsheet, left to right over time, and then figure out the company values and add snippets top to bottom for the relevant projects about the ways that project reflected a specific company value. This sounds corny and artificial, but it made it much easier for me to give prepared, pointed, real examples of my proven ability to add value to the company. 4) Startup interviews are more freeform than big company interviews for better and worse. At worst, you'll have the worst part of BigCo interviews with none of the competence. At best, you'll have a process that feels thoroughly modernized and personalized -- you'll probably work through some kind of a problem or collaborative design exercise together with one of the few engineers at the company (or the CTO), and based on how well you gel, you get hired. You'll be as much interviewing them for whether you want to work with them as vice versa. Or, you'll be hired to consult and if that goes well they'll want to bring you on full time. These kinds of gigs can be great because you are likely to be the most quality, experienced talent that they can get access to by a long shot, and the door is open for you to take a leadership role here. From that role, the door is open for you to take on a leadership role at a BigCo if that's what you want long term. BigCos love hiring talent that has been proven by the crucible of success at startups that they otherwise would have passed on when that talent wasn't necessarily "proven" to that level yet. You can probably guess why. 5) Consulting is a great play for those who are very experienced. You can sell your experience and not your fungible labor. But it does take the development of sales and positioning skills. I've never had success here but I've seen friends who have. My take? The pattern I see with friends who are successful on this route is they don't do it alone. They take on opportunities with other folks they've worked well with in the past. Companies love this because they thoroughly cut out an organizational integration risk, which is of putting together two otherwise productive individuals that clash destructively rather than coordinate. Let me be the first to say please don't undersell yourself. Having been a hiring manager at a seed stage startup before my current role, I absolutely would have jumped on any candidates that fit your profile. In fact, I tried to, multiple times, and saw my firm passed over for a competing offer from another firm. [1]https://hired.com/ https://hired.com/ [2]https://triplebyte.com/ https://triplebyte.com/ [3]https://angel.co/ https://angel.co/ [4]https://www.linkedin.com/ https://www.linkedin.com/ [5]http://www.crackingthecodinginterview.com/ http://www.crackingthecodinginterview.com/ [6]https://www.rooftopslushie.com/ https://www.rooftopslushie.com/