8 ms·

Coding Interview Cheatsheet

294 points by yangshun 9y ago

cpsharp 9y ago
Probabaly the most concise list of useful tips I've seen since I started interviewing at the big four. Yes to all.
- eradicatethots 9y ago
  You must be a super genius good boy
codeformore 9y ago
I wrote two articles about general tactics for coding interviews. The first is the importance of giving interesting answers, rather than those that are strictly correct: https://codeformore.com/technical-interviews-interesting-is-normally-more-important-than-right/ https://codeformore.com/technical-interviews-interesting-is-... The second is about showing your working -- showing the process that you use to approach a technical problem and reason through it: https://codeformore.com/technical-interviews-show-working/ https://codeformore.com/technical-interviews-show-working/
kevmo314 9y ago
> Defensive coding. Check for nulls, empty collections, etc. While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.
- munchor 9y ago
  Which is why the best thing is to ask. I always tell my candidates that the most important thing is how they approach the problem and not how careful they are with their coding. However, if the interviewer doesn't explain that, the best thing is not to do "Defensive Coding" as per the linked article, but instead to _ask_.
  - eradicatethots 9y ago
    I think it’s be better if interviewers and interviewees wrote code like they would in the job - no excessive commenting/checking ... just write effective, clean concise code and minimize time wasted In reality it might be risky to do this, but I’d like to see that change.
- abhishekpathak 9y ago
  Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing a short comment (# check for null) during the flow and then revisiting that part later.
  - bostik 9y ago
    I'm somewhat of two minds here, to be honest. First, depending on the situation I can find myself practicing "Paranoid Programming". It's an approach I picked up in my C days when I had to deal with network protocol code. Essentially: switch-case with every conceivable error condition handled and then the happy path as the final, unlikely edge case (Also: "default" case always triggered an error.) On the other hand it's a really depressing way to write code. When 80% or more of your dispatcher logic is dedicated to error handling, following the actual logic can be really cumbersome. On the positive side, once you are in the proper code, you have far less edge cases to worry about.
- yangshun 9y ago
  Thank you for the feedback, I have tweaked the wording accordingly (:
  - user5994461 9y ago
    Just my 2 cents: It would be nice to start all the don't sentences with "Don't ..." Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.
- SomeStupidPoint 9y ago
  I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.) So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc. This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code). This has worked out reasonably for me.
  - tome 9y ago
    > Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly Does it? Why?
    - SomeStupidPoint 9y ago
      An actual example of this concept coming up: I had a question about something with a distance formula, and the choice to either explicitly check the length of the points coming in, which were a list of coordinates, (either to ensure a particular dimension or a matching dimension) or another option to iterate over the components, which has a sane "dimension extension" behavior. It wasn't until I looked up the available floating point math functions that I knew their limits and could decide on how to implement the dimensionality handling. So in that case, my thought process went: Figure out the math -> Figure out how to apply it, eg map to a list of pairs of points (which also constrains math implementation) -> implement guarding on input to match contract
- dominotw 9y ago
  >if you just mention "assume the parameter is not null", it's more than sufficient to me. I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.
  - cakes 9y ago
    I usually am explicit in saying something along the lines of "Can it be assumed that I know how to do argument null checking, if possible, and not pollute the whiteboard?" and I've gotten a "Yes" and then after writing the function on the whiteboard: "Well what about <something relating to argument nullability>?"...so you should ask but YMMV
theprotocol 9y ago
>Stay calm and composed. Ironically, reading this makes me hyperaware. >Sound enthusiastic! Speak with a smile and you will naturally sound more engaging. In my experience, some people force this and it comes off a bit creepy. I've had better luck not thinking about this. IMHO don't treat the social side the same way you treat the technical side (i.e. preparation similar to homework). The social side should not be overly deliberate. Don't overthink it, just be polite.
- eradicatethots 9y ago
  You’re going to have a real working relationship with these people. I don’t think it makes sense to have a working relationship where you’re concerned so much about appearances. Don’t need to treat interviewers like they’re hypersensitive to your social behavior.
- heidar 9y ago
  You're right, I feel like a lot of stuff on this list will just cause overthinking. Just be yourself, don't be weird.
munchor 9y ago
One thing that's missing here is video camera feed. As an interviewer, I don't turn on my webcam and I don't expect the candidate to do it (although they can if they want to). However, I've heard different people have different opinions on this. It's definitely something that could go on this list for phone interviews. Of course, intra-US interviews are usually done over the phone but when the interviews are across countries, tools such as Google Hangouts are normally used.
- eradicatethots 9y ago
  Personally would not even look at the webcam, so it’s less awkward when I’m not expected to.
- codingvelocity 9y ago
  This seems quite odd to me. I work with people remotely and on site, and it's amazing how much better communication is when both parties turn their webcam on. Body language conveys things that tone, and words don't
  - tome 9y ago
    > communication is when both parties turn their webcam on Not least because the individuals concerned can't goof off doing something else at the same time.
- yangshun 9y ago
  Indeed this is something that deserves a mention in the list. Have added it!
- maaaats 9y ago
  I'd like to know beforehand when people call me if video is expected or not. A friend of mine ended up answering with video, but the interviewer only used voice. Then felt it was too late to turn the webcam of, and ended up in a weird one-way session making the experience even more stressful.
uday999 9y ago
Visit now Our Facebook Page http://yobuilder.com/5ilS http://yobuilder.com/5ilS Join WhatsApp Group https://chat.whatsapp.com/5eKlJkbcGCnJOU0NRob9YO https://chat.whatsapp.com/5eKlJkbcGCnJOU0NRob9YO Subscribe YouTube channel http://yobuilder.com/7pM5 http://yobuilder.com/7pM5
uday999 9y ago
Visit now Our Facebook Page http://yobuilder.com/5ilS http://yobuilder.com/5ilS Join WhatsApp Group https://chat.whatsapp.com/5eKlJkbcGCnJOU0NRob9YO https://chat.whatsapp.com/5eKlJkbcGCnJOU0NRob9YO Subscribe YouTube channel http://yobuilder.com/7pM5 http://yobuilder.com/7pM5 PLEASE Visit
pavlov 9y ago
I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.
- eradicatethots 9y ago
  I agree with you but I’m sure this will be flagged unless you tone it down
- Melchizedek 9y ago
  I suspect part of the cause is the prevalence of asperger-like personalities in the IT-field. No emotionally mature adult would conduct an interview like that, unless forced to. It would be completely unacceptable in any other professional field.
  - Zach_the_Lizard 9y ago
    I have to conduct these interviews and it kills me inside every time. I hated it as a candidate, but a year or two ago when I interviewed the questions were a bit easier and expectations were slightly lower. Now with the rise of Top Coder, Leetcode, etc. many candidates have practiced problems to death and can recite almost entirely from memory complex problems. The bar is raising all the time as a result. It's not enough to convey the idea on a whiteboard with reasonable code, maybe a semicolon missing. Now we're more or less expecting 100% compilable code, passing suites of test cases, and sometimes even multiple problems solved in 45 minutes. It's tailor made for coding competition contestants and crammers. And then they get on interview loops and hiring committees I'm dreading my next job search.
    - FLUX-YOU 9y ago
      >The bar is raising all the time as a result. I don't get why it would be that way. Your work's complexity isn't moving as fast as Top Coder, Leetcode, etc., so why is the interview's difficulty pinned to the difficulty on those websites? If you guys are taking on new practices and doing more difficult things, then that makes more sense.
stablemap 9y ago
This document is new but here’s a discussion of the repo from a couple weeks ago: https://news.ycombinator.com/item?id=15341566 https://news.ycombinator.com/item?id=15341566
raverbashing 9y ago
> There were times I had to restart Chrome to get Hangouts to work again. Yes, this seems to be a generalized problem
watwut 9y ago
> Immediately announce that you are done coding. Why?
- Fargren 9y ago
  Because if you immediately announce that you are done coding, you cannot do any of the other things on the list, which are all good ideas. After you've done them all, you should announce you are ready. It's probably a good idea to tell the interviewer what you are doing, don't just stand there looking at your code in silence if you can avoid it.
everdimension 9y ago
Isn't all this just common sense? It basically says "be a nice person to communicate with". But split up into a huge table of checks and crosses.
- arielm 9y ago
  Yes, but you’d be surprised how many candidates either get too nervous or are too shy to do most of these. Phone interviews are hard to begin with but you also have a lot of flexibility so it’s less stressful, but in-person interviews with real programming on a computer can put many into a really stressed state.
- psergeant 9y ago
  > Isn't all this just common sense? Right, but common sense isn't always directly actionable
arielm 9y ago
We do a lot of technical interviews and have seen enough candidates skip on many of these, so in that respect I like that there is a list they can reference. However, doing for the sake of following a list can come off as inexperienced/dishonest (or creepy, like one of the comments suggested). Having seen those first hand as well I can tell you I really dislike such interviews and that they always make me and whoever else is interviewing with me uncomfortable. My advice is to go through this list and reflect on your last interview. What did you do, what didn’t you do, why? And try to practice some of the things you didn’t. Also, keep in mind some of these are double edged swords. Example, speaking with enthusiasm. Don’t do it at all and you’ll be boring everyone, but do it too much and you’ll look like you can’t concentrate. Practice makes perfect, so work on it.
sethammons 9y ago
As far as a general behavior checklist, this one is fairly accurate in my interviewer experience. It is surprising how often candidates do many of the "Don'ts" in the list. In the end, I'm looking for candidates I can see myself working with. If we were to pair up on a task or project, I want to be reasonably sure I'm not going to dread the event; I should look forward to it. One example was a candidate from one of the Big 4. He was having trouble in Java (his preferred language) handling 400 and 500 level errors in an HTTP request that was part of the interview problem. I told him at the beginning that he can use whatever resources he wants, etc. I also told him that I am not a Java person but would help him where I could (we are not a Java shop). While he was reading documentation, I googled how to handle the errors, and said something along the lines of, "it looks like you should be able to do such-n-such with whatever class's method." He just said, "no." A few minutes later, still stuck, I suggested that he give it a try. "That's not how that works." We had to eventually skip the error handling to get back on track. What I got out of that part of our interaction was that he wouldn't likely be pleasant to work with. He could have said why my proposal would not work or anything beyond simply dismissing my attempt to help. I got the distinct feeling of, "this guy is kind of a jerk." He was applying for a senior developer position. Part of that role would be mentorship and leveling up your team (this was explained early on in the process, before the on site). With our limited time together, he did not convey anything of the sort. Post interview, he mentioned to our interview organizer / in-house recruiter that it was apparent I did not understand Java development. Post interview, I also took his submitted code and implemented my suggestion and it worked. In short, I think much of the post's checklist is accurate. Behavior during an interview counts. It is not just technical aptitude.
- psergeant 9y ago
  Developers seem to assume their interviewer is psychic in an interview, rather than showing their working and having an ongoing conversation
- gazarullz 9y ago
  Omg, I had someone in my team that was hired the same day as me and we would both be a no-match work-wise. All my suggestions and ideas would just be dismissed as wrong and everything that person was doing would be right without explaining the why I was on the point of depression and got me thinking more than once about quitting my job but I liked the company too much. It ended up with that person leaving. win-win.
psergeant 9y ago
> Prepare answers to the > frequently-asked questions > in an interview. One thing I've found works really well is literally to brain-dump any question at all I think I might get asked before the interview -- other than specific algorithmic. I'll spend time writing that out before the interview in prose form, and make sure I've literally said the words out loud at least once before the interview. If it's a phone interview, I can literally read out any good answers -- I'm yet to be told I sound scripted. If it's not, and I can't refer to my notes, I still find that having collated my thoughts on a subject first is pretty useful, and helps me segue into things I want to talk about.
nsxwolf 9y ago
Should add: spend effort making lots of industry friends and contacts. Tell them you’re looking for a job. Skip coding interview.
- nojvek 9y ago
  Coding interview is a very elemental part. You can deffo skip phone interview.
tzhenghao 9y ago
A couple small touches that have helped me power through these interviews: - Food intake prior to the interview. If I get phone interviews later in the day, especially after lunch, I avoid eating heavy and greasy food that can put me in a food coma. It has negatively impacted my performance in a couple of interviews back during my college days. Controlling my caffeine consumption before an interview helps too. I had a pretty bad "crash" in one of my onsites. - If I'm expected to do puzzle questions, it's best for me to warm up 45 mins before the interview just to get my mind in a problem solving state.
raisyer 9y ago
"Ask about your interview performance. It can get awkward." Maybe it's just me, but I always find that to ask for/give feedback is better(if asked), as recruiters almost never respond if you have not cleared the round and if there is opportunity to give feedback so that candidate has an idea on what to work on. Also I have found that when asking for feedback, it can lead to interesting discussions which might make the interviewer change his/her mind. This of course is personal preference...
- gregmac 9y ago
  One of the problems is you are not likely to get truly honest feedback. That opens things up to dispute, and that puts the interviewer in an awkward position: if they cannot articulate a point properly, even if valid, the interviewee is left feeling they should have "passed". In the worst case, they could claim the interviewer was prejudiced against them and file a labor dispute or lawsuit. It's also often highly subjective, for example: "I don't think you demonstrated the depth of knowledge in (technology x) we're looking for in this position" "Well I've developed several applications that work, so clearly I do know it" What you can do along the way is ask questions like "Would you like me to elaborate on that?" or "did I answer your question adequately?" if you get the sense you may not have. For code, the list on the page is actually decent - ask up front about the assumptions, how much you should focus on defensive coding, etc.
reddit_clone 9y ago
I would rather coding interviews went like this. Give the candidates a non-trivial problem, which might take a few days to complete. Everything documented and checked into github. Call them for interviews and review design/code with them. Make sure it was not all copy-pasta and someone else didn't write it for them. To make sure of that, introduce a slight variation in spec and ask them to do it on the spot. This way, you get to review their entire development process, How they approach problems, code quality, unit tests, code performance , usage of source control system, CI/CD usage etc. At this point you will know for sure if you want them or not (They might also know they want to work for you or not .. :-). )
- asdojasdosadsa 9y ago
  I second this. I have some anxiety issues and someone looking at me while coding _the whole "answer"_ would be a really horrifying experience. My anxiety issue has nothing to do with how good I am with coding, it's just about confronting people and socializing with them
- deleted 9y ago
  [deleted]
- lithos 9y ago
  Sounds like a great way to filter people who have other responsibilities, or are an attractive enough candidate to be busy interviewing for other firms.
  - gervase 9y ago
    Really puts the "free" in freelancer, too.
  - darth_mastah 9y ago
    Absolutely. I second that. I would be willing to spend a couple of hours on an interview task, which could give the interviewer an idea about my skills, but more than that I would see as an overkill. Besides, in my view, showing some OS repos on GitHub can be a good alternative.
paulus_magnus2 9y ago
This fixes the wrong problem. Has anyone seen a whiteboard managing interview for IT managers?

294 points by yangshun 9y ago

cpsharp 9y ago

Probabaly the most concise list of useful tips I've seen since I started interviewing at the big four. Yes to all.

eradicatethots 9y ago
You must be a super genius good boy

codeformore 9y ago

I wrote two articles about general tactics for coding interviews. The first is the importance of giving interesting answers, rather than those that are strictly correct: https://codeformore.com/technical-interviews-interesting-is-normally-more-important-than-right/ https://codeformore.com/technical-interviews-interesting-is-... The second is about showing your working -- showing the process that you use to approach a technical problem and reason through it: https://codeformore.com/technical-interviews-show-working/ https://codeformore.com/technical-interviews-show-working/

kevmo314 9y ago

> Defensive coding. Check for nulls, empty collections, etc. While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.

munchor 9y ago
Which is why the best thing is to ask. I always tell my candidates that the most important thing is how they approach the problem and not how careful they are with their coding. However, if the interviewer doesn't explain that, the best thing is not to do "Defensive Coding" as per the linked article, but instead to _ask_.
- eradicatethots 9y ago
  I think it’s be better if interviewers and interviewees wrote code like they would in the job - no excessive commenting/checking ... just write effective, clean concise code and minimize time wasted In reality it might be risky to do this, but I’d like to see that change.
abhishekpathak 9y ago
Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing a short comment (# check for null) during the flow and then revisiting that part later.
- bostik 9y ago
  I'm somewhat of two minds here, to be honest. First, depending on the situation I can find myself practicing "Paranoid Programming". It's an approach I picked up in my C days when I had to deal with network protocol code. Essentially: switch-case with every conceivable error condition handled and then the happy path as the final, unlikely edge case (Also: "default" case always triggered an error.) On the other hand it's a really depressing way to write code. When 80% or more of your dispatcher logic is dedicated to error handling, following the actual logic can be really cumbersome. On the positive side, once you are in the proper code, you have far less edge cases to worry about.
yangshun 9y ago
Thank you for the feedback, I have tweaked the wording accordingly (:
- user5994461 9y ago
  Just my 2 cents: It would be nice to start all the don't sentences with "Don't ..." Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.
SomeStupidPoint 9y ago
I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.) So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc. This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code). This has worked out reasonably for me.
- tome 9y ago
  > Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly Does it? Why?
  - SomeStupidPoint 9y ago
    An actual example of this concept coming up: I had a question about something with a distance formula, and the choice to either explicitly check the length of the points coming in, which were a list of coordinates, (either to ensure a particular dimension or a matching dimension) or another option to iterate over the components, which has a sane "dimension extension" behavior. It wasn't until I looked up the available floating point math functions that I knew their limits and could decide on how to implement the dimensionality handling. So in that case, my thought process went: Figure out the math -> Figure out how to apply it, eg map to a list of pairs of points (which also constrains math implementation) -> implement guarding on input to match contract
dominotw 9y ago
>if you just mention "assume the parameter is not null", it's more than sufficient to me. I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.
- cakes 9y ago
  I usually am explicit in saying something along the lines of "Can it be assumed that I know how to do argument null checking, if possible, and not pollute the whiteboard?" and I've gotten a "Yes" and then after writing the function on the whiteboard: "Well what about <something relating to argument nullability>?"...so you should ask but YMMV

theprotocol 9y ago

>Stay calm and composed. Ironically, reading this makes me hyperaware. >Sound enthusiastic! Speak with a smile and you will naturally sound more engaging. In my experience, some people force this and it comes off a bit creepy. I've had better luck not thinking about this. IMHO don't treat the social side the same way you treat the technical side (i.e. preparation similar to homework). The social side should not be overly deliberate. Don't overthink it, just be polite.

eradicatethots 9y ago
You’re going to have a real working relationship with these people. I don’t think it makes sense to have a working relationship where you’re concerned so much about appearances. Don’t need to treat interviewers like they’re hypersensitive to your social behavior.
heidar 9y ago
You're right, I feel like a lot of stuff on this list will just cause overthinking. Just be yourself, don't be weird.

munchor 9y ago

One thing that's missing here is video camera feed. As an interviewer, I don't turn on my webcam and I don't expect the candidate to do it (although they can if they want to). However, I've heard different people have different opinions on this. It's definitely something that could go on this list for phone interviews. Of course, intra-US interviews are usually done over the phone but when the interviews are across countries, tools such as Google Hangouts are normally used.

eradicatethots 9y ago
Personally would not even look at the webcam, so it’s less awkward when I’m not expected to.
codingvelocity 9y ago
This seems quite odd to me. I work with people remotely and on site, and it's amazing how much better communication is when both parties turn their webcam on. Body language conveys things that tone, and words don't
- tome 9y ago
  > communication is when both parties turn their webcam on Not least because the individuals concerned can't goof off doing something else at the same time.
yangshun 9y ago
Indeed this is something that deserves a mention in the list. Have added it!
maaaats 9y ago
I'd like to know beforehand when people call me if video is expected or not. A friend of mine ended up answering with video, but the interviewer only used voice. Then felt it was too late to turn the webcam of, and ended up in a weird one-way session making the experience even more stressful.

uday999 9y ago

Visit now Our Facebook Page http://yobuilder.com/5ilS http://yobuilder.com/5ilS Join WhatsApp Group https://chat.whatsapp.com/5eKlJkbcGCnJOU0NRob9YO https://chat.whatsapp.com/5eKlJkbcGCnJOU0NRob9YO Subscribe YouTube channel http://yobuilder.com/7pM5 http://yobuilder.com/7pM5

uday999 9y ago

pavlov 9y ago

I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.

eradicatethots 9y ago
I agree with you but I’m sure this will be flagged unless you tone it down
Melchizedek 9y ago
I suspect part of the cause is the prevalence of asperger-like personalities in the IT-field. No emotionally mature adult would conduct an interview like that, unless forced to. It would be completely unacceptable in any other professional field.
- Zach_the_Lizard 9y ago
  I have to conduct these interviews and it kills me inside every time. I hated it as a candidate, but a year or two ago when I interviewed the questions were a bit easier and expectations were slightly lower. Now with the rise of Top Coder, Leetcode, etc. many candidates have practiced problems to death and can recite almost entirely from memory complex problems. The bar is raising all the time as a result. It's not enough to convey the idea on a whiteboard with reasonable code, maybe a semicolon missing. Now we're more or less expecting 100% compilable code, passing suites of test cases, and sometimes even multiple problems solved in 45 minutes. It's tailor made for coding competition contestants and crammers. And then they get on interview loops and hiring committees I'm dreading my next job search.
  - FLUX-YOU 9y ago
    >The bar is raising all the time as a result. I don't get why it would be that way. Your work's complexity isn't moving as fast as Top Coder, Leetcode, etc., so why is the interview's difficulty pinned to the difficulty on those websites? If you guys are taking on new practices and doing more difficult things, then that makes more sense.

stablemap 9y ago

This document is new but here’s a discussion of the repo from a couple weeks ago: https://news.ycombinator.com/item?id=15341566 https://news.ycombinator.com/item?id=15341566

raverbashing 9y ago

> There were times I had to restart Chrome to get Hangouts to work again. Yes, this seems to be a generalized problem

watwut 9y ago

> Immediately announce that you are done coding. Why?

Fargren 9y ago
Because if you immediately announce that you are done coding, you cannot do any of the other things on the list, which are all good ideas. After you've done them all, you should announce you are ready. It's probably a good idea to tell the interviewer what you are doing, don't just stand there looking at your code in silence if you can avoid it.

everdimension 9y ago

Isn't all this just common sense? It basically says "be a nice person to communicate with". But split up into a huge table of checks and crosses.

arielm 9y ago
Yes, but you’d be surprised how many candidates either get too nervous or are too shy to do most of these. Phone interviews are hard to begin with but you also have a lot of flexibility so it’s less stressful, but in-person interviews with real programming on a computer can put many into a really stressed state.
psergeant 9y ago
> Isn't all this just common sense? Right, but common sense isn't always directly actionable

arielm 9y ago

We do a lot of technical interviews and have seen enough candidates skip on many of these, so in that respect I like that there is a list they can reference. However, doing for the sake of following a list can come off as inexperienced/dishonest (or creepy, like one of the comments suggested). Having seen those first hand as well I can tell you I really dislike such interviews and that they always make me and whoever else is interviewing with me uncomfortable. My advice is to go through this list and reflect on your last interview. What did you do, what didn’t you do, why? And try to practice some of the things you didn’t. Also, keep in mind some of these are double edged swords. Example, speaking with enthusiasm. Don’t do it at all and you’ll be boring everyone, but do it too much and you’ll look like you can’t concentrate. Practice makes perfect, so work on it.

sethammons 9y ago

As far as a general behavior checklist, this one is fairly accurate in my interviewer experience. It is surprising how often candidates do many of the "Don'ts" in the list. In the end, I'm looking for candidates I can see myself working with. If we were to pair up on a task or project, I want to be reasonably sure I'm not going to dread the event; I should look forward to it. One example was a candidate from one of the Big 4. He was having trouble in Java (his preferred language) handling 400 and 500 level errors in an HTTP request that was part of the interview problem. I told him at the beginning that he can use whatever resources he wants, etc. I also told him that I am not a Java person but would help him where I could (we are not a Java shop). While he was reading documentation, I googled how to handle the errors, and said something along the lines of, "it looks like you should be able to do such-n-such with whatever class's method." He just said, "no." A few minutes later, still stuck, I suggested that he give it a try. "That's not how that works." We had to eventually skip the error handling to get back on track. What I got out of that part of our interaction was that he wouldn't likely be pleasant to work with. He could have said why my proposal would not work or anything beyond simply dismissing my attempt to help. I got the distinct feeling of, "this guy is kind of a jerk." He was applying for a senior developer position. Part of that role would be mentorship and leveling up your team (this was explained early on in the process, before the on site). With our limited time together, he did not convey anything of the sort. Post interview, he mentioned to our interview organizer / in-house recruiter that it was apparent I did not understand Java development. Post interview, I also took his submitted code and implemented my suggestion and it worked. In short, I think much of the post's checklist is accurate. Behavior during an interview counts. It is not just technical aptitude.

psergeant 9y ago
Developers seem to assume their interviewer is psychic in an interview, rather than showing their working and having an ongoing conversation
gazarullz 9y ago
Omg, I had someone in my team that was hired the same day as me and we would both be a no-match work-wise. All my suggestions and ideas would just be dismissed as wrong and everything that person was doing would be right without explaining the why I was on the point of depression and got me thinking more than once about quitting my job but I liked the company too much. It ended up with that person leaving. win-win.

psergeant 9y ago

> Prepare answers to the > frequently-asked questions > in an interview. One thing I've found works really well is literally to brain-dump any question at all I think I might get asked before the interview -- other than specific algorithmic. I'll spend time writing that out before the interview in prose form, and make sure I've literally said the words out loud at least once before the interview. If it's a phone interview, I can literally read out any good answers -- I'm yet to be told I sound scripted. If it's not, and I can't refer to my notes, I still find that having collated my thoughts on a subject first is pretty useful, and helps me segue into things I want to talk about.

nsxwolf 9y ago

Should add: spend effort making lots of industry friends and contacts. Tell them you’re looking for a job. Skip coding interview.

nojvek 9y ago
Coding interview is a very elemental part. You can deffo skip phone interview.

tzhenghao 9y ago

A couple small touches that have helped me power through these interviews: - Food intake prior to the interview. If I get phone interviews later in the day, especially after lunch, I avoid eating heavy and greasy food that can put me in a food coma. It has negatively impacted my performance in a couple of interviews back during my college days. Controlling my caffeine consumption before an interview helps too. I had a pretty bad "crash" in one of my onsites. - If I'm expected to do puzzle questions, it's best for me to warm up 45 mins before the interview just to get my mind in a problem solving state.

raisyer 9y ago

"Ask about your interview performance. It can get awkward." Maybe it's just me, but I always find that to ask for/give feedback is better(if asked), as recruiters almost never respond if you have not cleared the round and if there is opportunity to give feedback so that candidate has an idea on what to work on. Also I have found that when asking for feedback, it can lead to interesting discussions which might make the interviewer change his/her mind. This of course is personal preference...

gregmac 9y ago
One of the problems is you are not likely to get truly honest feedback. That opens things up to dispute, and that puts the interviewer in an awkward position: if they cannot articulate a point properly, even if valid, the interviewee is left feeling they should have "passed". In the worst case, they could claim the interviewer was prejudiced against them and file a labor dispute or lawsuit. It's also often highly subjective, for example: "I don't think you demonstrated the depth of knowledge in (technology x) we're looking for in this position" "Well I've developed several applications that work, so clearly I do know it" What you can do along the way is ask questions like "Would you like me to elaborate on that?" or "did I answer your question adequately?" if you get the sense you may not have. For code, the list on the page is actually decent - ask up front about the assumptions, how much you should focus on defensive coding, etc.

reddit_clone 9y ago

I would rather coding interviews went like this. Give the candidates a non-trivial problem, which might take a few days to complete. Everything documented and checked into github. Call them for interviews and review design/code with them. Make sure it was not all copy-pasta and someone else didn't write it for them. To make sure of that, introduce a slight variation in spec and ask them to do it on the spot. This way, you get to review their entire development process, How they approach problems, code quality, unit tests, code performance , usage of source control system, CI/CD usage etc. At this point you will know for sure if you want them or not (They might also know they want to work for you or not .. :-). )

asdojasdosadsa 9y ago
I second this. I have some anxiety issues and someone looking at me while coding _the whole "answer"_ would be a really horrifying experience. My anxiety issue has nothing to do with how good I am with coding, it's just about confronting people and socializing with them
deleted 9y ago
[deleted]
lithos 9y ago
Sounds like a great way to filter people who have other responsibilities, or are an attractive enough candidate to be busy interviewing for other firms.
- gervase 9y ago
  Really puts the "free" in freelancer, too.
- darth_mastah 9y ago
  Absolutely. I second that. I would be willing to spend a couple of hours on an interview task, which could give the interviewer an idea about my skills, but more than that I would see as an overkill. Besides, in my view, showing some OS repos on GitHub can be a good alternative.

paulus_magnus2 9y ago

This fixes the wrong problem. Has anyone seen a whiteboard managing interview for IT managers?