4 ms·

I never had test anxiety growing up and didn't really empathize with why someone would (sympathized obviously). But solving a problem in FRONT of someone as the

I never had test anxiety growing up and didn't really empathize with why someone would (sympathized obviously). But solving a problem in FRONT of someone as they are evaluating me (rather than a normal collaboration) triggers a panic. The only thing that helped reduce the panic is repeated drills, which take a lot of time.

WalterSear 5y ago
IMHO, you can't really drill for technical interviews. The landscape is way too large for one to be fresh on whatever they ask you to do.
- wombat-man 5y ago
  learning some tips and tricks has made it all a lot less spooky. I hate that it's like this but it is kind of about that nowadays, for certain companies anyway. I guess they assume you have unlimited time to study, so if know enough it shouldn't be too hard. But if you are just walking in there cold as an experienced applicant, you can end up having a really bad time.
  - WalterSear 5y ago
    I have over a decade of programming experience. I've completed almost 10% of Leetcode's problem set. I've done dozens of technical interviews. I prep for days, specifically for every interview, and they invariably go about as bad as the first one.
    - joelbluminator 5y ago
      I can empathize. The only interviews where I think "huh, this went reasonably well" are basically online tests. Almost never when I interview in front of a person / live screen and do white boarding. The bad news is my chances of getting into FAANG are very slim. The good news there are tons of companies who aren't FAANG.
      - WalterSear 5y ago
        The only interviews I have a reasonable chance of passing are take home tests. I'm a good coder, not a performing monkey.
        joelbluminator 5y ago
        Take homes are probably the best way to test actual coding abilities. I had a pretty good online coding test done by Microsoft actually, it was 2 hours of building an API; no trick questions, no big-o, just write a bunch of code. It wasn't easy but it felt as if they're actually testing what I do for a living. I passed it and it didn't go to the follow up - which would have probably been a shitty whiteboard interview but I'm not sure. Now that I think about it maybe I should have gone to that interview ...
    - wombat-man 5y ago
      I feel you man. I'd suggest Elements of Programming Interviews in your preferred language. It does a really good job in my opinion of walking you through a lot of common tricks. I'm not really grinding through a lot of problems but doing a problem wrong, and then reading a well written explanation of the solution is a lot better for me in terms of learning. The study guide picks a good selection of problems for you to optimize for time. Some of the mathy/low level problems are bullshit that nobody would ever actually ask though. I felt like I got a good run through of some of the data structures that I just don't typically use in Java, and how they can be extremely useful in a coding interview. LC problems are not always well written and a lot of times you just have to hope someone took the time to write out a good solution. A lot of times they just paste their code and expect you to get it.
    - oneepic 5y ago
      Maybe I missed it, but what do you think is/are the reason(s) they go so bad? Time pressure? Having an interviewer watching and judging? Etc. For me personally, my brain goes completely blank at the problem statement, pretty much in the dark without a flashlight, and I have to work everything out by hand and hope that my code actually ends up being correct and reasonable. It's scary but I've ended up doing well.
- oneepic 5y ago
  I disagree because: 1) you don't have to know everything, only the topics they happen to ask. You are rolling the dice, but part of the time you'll be lucky. Besides, after reviewing for a few months (also did 4 yr degree in CS) I felt really strong in the algo topics. That said, I started half of my recent Google interviews thinking "how the fuck do I solve this? is this where I fail?" 2) Aside from the topics, you can absolutely drill the process. Drill a basic flow like understand/clarify the question, do examples, mention a brute-force, etc. when you do LC problems.
  - SomeCallMeTim 5y ago
    And for 1)--a good interviewer won't actually mark you down for not knowing some fact, or not being able to think of some trick. I've passed interviews where I've just said, "Hey, I don't know [that particular thing]. How should it work?" or "I'd Google the exact algorithm for X; I'll pretend I wrote that and call it here..." or similar. Good interviewers want you to pass, and aren't just giving you a test of arbitrary programming trivia.
    - polynox 5y ago
      This is a lie at least as it corresponds to bigtech hiring today. > "I'd Google the exact algorithm for X" This is a fail in the interviewer's book. Read: "Could not produce an algorithm with less than O(n)" or "lacks familiarity with fundamental data structures"
      - SomeCallMeTim 5y ago
        I passed an Amazon interview by saying almost exactly that, so given Amazon is one of the FAANG companies? I can back up my statement.
    - WalterSear 5y ago
      Technical interviews are about culling the incoming applicants on the assumption that passing many good hires is preferable to letting one bad hire through. So, IME, no matter how well intentioned an interviewer may be, they aren't ultimately looking for a reason to pass you - they are looking for any way to differentiate between candidates. Lip service is certainly paid to 'everyone has to look things up', and doing a quick search won't necessarily count against you, but, IME, the hesitation and doubt that caused you to look things up will. With so little material with which to evaluate a candidate, absolutely everything that doesn't impress them is going to count against you.
- mywittyname 5y ago
  Sure you can: 1. HackerRank (or similar) challenges are pretty close to what you'd find in a lot of technical interviews. 2. Searching online for "<technology> interview questions" for a few of the technologies that you're likely going to be asked about. Make sure you have good answers for the questions that pop up a lot. This helps a lot with remembering Stuff You Should Know that kind of slipped your mind (ie., angular digest cycle) because you maybe haven't seen it in a bit. 3. Write up a summary of your previous accomplishments and be sure you can call them out on the spot. A lot of what the interviewer is looking for is confidence. And preparation begets confidence.
  - moufestaphio 5y ago
    Yeah I agree with this. If you drill enough of the Coding questions, they all start to run into similar buckets, and the way you approach them improves too. Buy a whiteboard off amazon, solve them legit out loud explaining what you're doing to yourself. You will get better. The other stuff is great advice too, always try to have a summary (in your mind or on paper) of recent projects etc. And of course.. Doing interviews helps to :D
  - WalterSear 5y ago
    This is the conventional wisdom, and IME, it's minimally effective. I've followed this practice for years. I've completed almost 10% of leetcode's problem set. Interviewers should be looking for competence, not confidence.
    - mywittyname 5y ago
      Something to keep in mind is interviewers basically never receive any kind of training, and even experienced technical interviewers do it maybe once a week or so. These people are doing their best to gauge technical aptitude and culture fit from a one hour conversation. It's not easy either. If I mess up once while giving advice on a place where the candidate is stuck, I can really confuse the candidate. Plus the time cost of reviewing a person's resume to determine what questions are appropriate for them. Lastly, I can't be expected to know all the tech on someone's resume at a level that I can gauge their capabilities, I use other means to determine if what a COBOL person is telling me is accurate. So you have to kind of plan that interviewers take shortcuts (like judging confidence) and take advantage of that fact. If someone asks what are some benefits or drawbacks to a tech stack you use, have at the ready a good story about a shitty/hilarious/intersting experience you had while developing it. The experience doesn't need to be a 1-to-1 mapping either, it's a-okay to kind of nudge a question towards an answer you prepared. This is better advice than you're really appreciating. If you feel like you are doing this, but still am having trouble, it's likely that you need work in some other non-obvious aspect of interviewing. I highly suggest finding a coach or someone who can take you through mock interviews and help you find out exactly what you can do to improve your chances!
- me_im_counting 5y ago
  It's not drilling on the technical side. It's drilling the experience that produces anxiety (performing it to an interviewer).
- cloverich 5y ago
  You can. I've worked at a few startups and participated in interviews, witnessing the variety of questions asked. For most companies its a limited pool of questions and well trodden ground.

WalterSear 5y ago

IMHO, you can't really drill for technical interviews. The landscape is way too large for one to be fresh on whatever they ask you to do.

wombat-man 5y ago
learning some tips and tricks has made it all a lot less spooky. I hate that it's like this but it is kind of about that nowadays, for certain companies anyway. I guess they assume you have unlimited time to study, so if know enough it shouldn't be too hard. But if you are just walking in there cold as an experienced applicant, you can end up having a really bad time.
- WalterSear 5y ago
  I have over a decade of programming experience. I've completed almost 10% of Leetcode's problem set. I've done dozens of technical interviews. I prep for days, specifically for every interview, and they invariably go about as bad as the first one.
  - joelbluminator 5y ago
    I can empathize. The only interviews where I think "huh, this went reasonably well" are basically online tests. Almost never when I interview in front of a person / live screen and do white boarding. The bad news is my chances of getting into FAANG are very slim. The good news there are tons of companies who aren't FAANG.
    - WalterSear 5y ago
      The only interviews I have a reasonable chance of passing are take home tests. I'm a good coder, not a performing monkey.
      - joelbluminator 5y ago
        Take homes are probably the best way to test actual coding abilities. I had a pretty good online coding test done by Microsoft actually, it was 2 hours of building an API; no trick questions, no big-o, just write a bunch of code. It wasn't easy but it felt as if they're actually testing what I do for a living. I passed it and it didn't go to the follow up - which would have probably been a shitty whiteboard interview but I'm not sure. Now that I think about it maybe I should have gone to that interview ...
  - wombat-man 5y ago
    I feel you man. I'd suggest Elements of Programming Interviews in your preferred language. It does a really good job in my opinion of walking you through a lot of common tricks. I'm not really grinding through a lot of problems but doing a problem wrong, and then reading a well written explanation of the solution is a lot better for me in terms of learning. The study guide picks a good selection of problems for you to optimize for time. Some of the mathy/low level problems are bullshit that nobody would ever actually ask though. I felt like I got a good run through of some of the data structures that I just don't typically use in Java, and how they can be extremely useful in a coding interview. LC problems are not always well written and a lot of times you just have to hope someone took the time to write out a good solution. A lot of times they just paste their code and expect you to get it.
  - oneepic 5y ago
    Maybe I missed it, but what do you think is/are the reason(s) they go so bad? Time pressure? Having an interviewer watching and judging? Etc. For me personally, my brain goes completely blank at the problem statement, pretty much in the dark without a flashlight, and I have to work everything out by hand and hope that my code actually ends up being correct and reasonable. It's scary but I've ended up doing well.
oneepic 5y ago
I disagree because: 1) you don't have to know everything, only the topics they happen to ask. You are rolling the dice, but part of the time you'll be lucky. Besides, after reviewing for a few months (also did 4 yr degree in CS) I felt really strong in the algo topics. That said, I started half of my recent Google interviews thinking "how the fuck do I solve this? is this where I fail?" 2) Aside from the topics, you can absolutely drill the process. Drill a basic flow like understand/clarify the question, do examples, mention a brute-force, etc. when you do LC problems.
- SomeCallMeTim 5y ago
  And for 1)--a good interviewer won't actually mark you down for not knowing some fact, or not being able to think of some trick. I've passed interviews where I've just said, "Hey, I don't know [that particular thing]. How should it work?" or "I'd Google the exact algorithm for X; I'll pretend I wrote that and call it here..." or similar. Good interviewers want you to pass, and aren't just giving you a test of arbitrary programming trivia.
  - polynox 5y ago
    This is a lie at least as it corresponds to bigtech hiring today. > "I'd Google the exact algorithm for X" This is a fail in the interviewer's book. Read: "Could not produce an algorithm with less than O(n)" or "lacks familiarity with fundamental data structures"
    - SomeCallMeTim 5y ago
      I passed an Amazon interview by saying almost exactly that, so given Amazon is one of the FAANG companies? I can back up my statement.
  - WalterSear 5y ago
    Technical interviews are about culling the incoming applicants on the assumption that passing many good hires is preferable to letting one bad hire through. So, IME, no matter how well intentioned an interviewer may be, they aren't ultimately looking for a reason to pass you - they are looking for any way to differentiate between candidates. Lip service is certainly paid to 'everyone has to look things up', and doing a quick search won't necessarily count against you, but, IME, the hesitation and doubt that caused you to look things up will. With so little material with which to evaluate a candidate, absolutely everything that doesn't impress them is going to count against you.
mywittyname 5y ago
Sure you can: 1. HackerRank (or similar) challenges are pretty close to what you'd find in a lot of technical interviews. 2. Searching online for "<technology> interview questions" for a few of the technologies that you're likely going to be asked about. Make sure you have good answers for the questions that pop up a lot. This helps a lot with remembering Stuff You Should Know that kind of slipped your mind (ie., angular digest cycle) because you maybe haven't seen it in a bit. 3. Write up a summary of your previous accomplishments and be sure you can call them out on the spot. A lot of what the interviewer is looking for is confidence. And preparation begets confidence.
- moufestaphio 5y ago
  Yeah I agree with this. If you drill enough of the Coding questions, they all start to run into similar buckets, and the way you approach them improves too. Buy a whiteboard off amazon, solve them legit out loud explaining what you're doing to yourself. You will get better. The other stuff is great advice too, always try to have a summary (in your mind or on paper) of recent projects etc. And of course.. Doing interviews helps to :D
- WalterSear 5y ago
  This is the conventional wisdom, and IME, it's minimally effective. I've followed this practice for years. I've completed almost 10% of leetcode's problem set. Interviewers should be looking for competence, not confidence.
  - mywittyname 5y ago
    Something to keep in mind is interviewers basically never receive any kind of training, and even experienced technical interviewers do it maybe once a week or so. These people are doing their best to gauge technical aptitude and culture fit from a one hour conversation. It's not easy either. If I mess up once while giving advice on a place where the candidate is stuck, I can really confuse the candidate. Plus the time cost of reviewing a person's resume to determine what questions are appropriate for them. Lastly, I can't be expected to know all the tech on someone's resume at a level that I can gauge their capabilities, I use other means to determine if what a COBOL person is telling me is accurate. So you have to kind of plan that interviewers take shortcuts (like judging confidence) and take advantage of that fact. If someone asks what are some benefits or drawbacks to a tech stack you use, have at the ready a good story about a shitty/hilarious/intersting experience you had while developing it. The experience doesn't need to be a 1-to-1 mapping either, it's a-okay to kind of nudge a question towards an answer you prepared. This is better advice than you're really appreciating. If you feel like you are doing this, but still am having trouble, it's likely that you need work in some other non-obvious aspect of interviewing. I highly suggest finding a coach or someone who can take you through mock interviews and help you find out exactly what you can do to improve your chances!
me_im_counting 5y ago
It's not drilling on the technical side. It's drilling the experience that produces anxiety (performing it to an interviewer).
cloverich 5y ago
You can. I've worked at a few startups and participated in interviews, witnessing the variety of questions asked. For most companies its a limited pool of questions and well trodden ground.