[ellard]

Not currently interviewing, but in the past i've failed interviews because I didn't do something that the interviewer didn't ask me to do. This would be something like expecting the interviewee to go in depth about a specific part of the problem that to the interviewee might have thought was trivial, or expecting them to do TDD in a coding exercise when the interviewer never mentioned it. I can brush off overt rudeness, but it's always rubbed me the wrong way that some interviewers expect you to read their mind.

[ryanbrunner]

I've seen the TDD one, and I hate that so much. The last time I interviewed for companies, I started asking "how do you want me to answer this? Are you looking for me to get a complete solution quickly, or write this like I was writing software I planned to maintain?", but I really shouldn't have to - putting your candidates through a guessing game of which you want is a dumb way to interview.

[flyfishnjake]

I had a recruiter suggest I do TDD during my coding interviews. When I was in the interviews, I started using TDD. It seemed like the actual interviewer was indifferent about me using TDD. He even seemed surprised, but I did it anyway because the recruiter suggested it.

Using TDD takes longer during an interview, so I didn't get as far into the problem as what I think the interviewer was expecting. I assume people that didn't use TDD performed better because they were able to get farther in the problem.

I didn't get an offer. I'm not sure if it's because of the TDD issue, but I can't think of anything else that could have contributed to the outcome. I sent my feedback to the recruiter after I was notified I didn't get an offer, and I asked for any feedback, but never heard anything.

[simonbarker87]

One of the things I’ve written in my book on coding interviews is around expectations and covering off any shortcuts/interview specific things you are doing. It’s annoying but asking: 1. Is there a specific approach or methodology you would like me to take in this test? 2. Saying stuff like “I’m going to do this in functional/OOP”, “I’ll use print for debugging”, “I won’t be using a testing library” etc with a quick explanation goes along way to ironing out these differences

[ellard]

I agree that the above is what we should do as individuals to make our own interview experience smoother. It's a shame that we have to though, considering that the interviewers all have been interviewees themselves in the past and should recognize this issue.