[dx211]

A couple of years back, I was hiring some vendor developers for my team, and since I had some flexibility in the interviews that wouldn't be allowed for full-time employees, I tried an experiment: For one of the vendor candidates, I told him a day ahead of time that I'd be asking him to implement System.Collections.Hashtable in C#, with behavior equivalent to the one in .Net. The day of the interview came, and he whiteboarded it flawlessly, to a degree that I'd never seen any other candidate accomplish, and he was able to have a deep conversation about the implementation and all of its nuances. He then proceeded to bomb the rest of his interviews and didn't get the position. What this illustrates to me is that the typical programmer interview, where we come up with some weird problem and toss it to the candidate while they have no references to look at, no IDE to type into, and a 45 minute deadline looming over their head, is totally divorced from the actual work we actually really want them to do. If I need someone to implement a widget, I'd rather they took some time to research it and do it right, versus trying to crap out a solution in five minutes on a whiteboard.

[thaumasiotes]

I recently interviewed with a company that had advertised (in my paraphrase) "we've noticed that a lot of perfectly good developers do poorly in interviews for reasons that appear to be unrelated to job performance. So you can now interview with us by completing a project on your own time, and during the interview we'll talk about that".

My project was a regex matcher. I ended up getting the following feedback:

> We thought you wrote a great, very full featured regular expression matcher. It was especially impressive how much you dug into the academics behind regular languages.

> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here.

It's hard to know what to do with that. :/

[1stranger]

Wow, that really sucks. So they basically took the old process and just added more to it.

[sokoloff]

Disagree (on the second part). Rather than giving you the equivalent of a walk-up pop quiz on a random topic, they are giving you followup questions and discussions on code that the candidate wrote recently.

That seems quite a bit more representative of regular work than a pop quiz. Yes, you still need to be able to talk live about code with other developers. That's unchanged and shouldn't change, IMO.

[plonh]

Look like either bad communications or some sort of discrimination about your in person appearance, or they filled the open headcount with someone they liked better.

[robodale]

Wow, what the f_ck kind of person do they want? You showed when you can code, build a complex application that actually does something valuable. You know, understand, and can use deeper level stuff.

I get that they and every other business wants to find a team of wunderkinds that can plug right into their repo and get to work. That's the ideal.

My advice - don't sweat it.

[davnicwil]

Brilliantly put.

When I'm giving interviews I really like it when a candidate posed with a fairly complicated problem or design question pauses and actually thinks, then says something like "..well, I don't really know, I'd probably want to think about it more, but here's an idea" before putting forward their likely non-optimal but totally plausible and on-the-right-track design or solution that they thought of on the spot.

Under-confidence in an answer (straight up asking for validation i.e. is this right?) or over-confidence (expecting to shoot straight from the hip with the perfect, 'right' solution, or just a plain old bullshitter implicitly insisting that anything they say is correct) are usually red flags for an extreme personality type - always exceptions to this but as a general rule, I've found it to be true - and the happy middle ground, coupled with answers that obviously point towards a depth of knowledge and skill, is what you're looking for.

Trying to follow my own advice, I've done this myself as well when I'm the interviewee. Side benefit - if the interviewer actually is looking for a 'right answer' to complex questions out of the blue and on the spot - good for them if that's what they want but I'd want to self-select myself out of that type of expectation and working relationship. So everybody wins.

[IndianAstronaut]

I recently interviewed at Facebook and they seem to want the shoot from the hip type person who is extremely confident (borderline arrogant) about their answers. Theh drill and drill amd expect rapid fire responses.

[plonh]

That may be true for the person who interviewed you, but that isn't any sort of official standard

[IndianAstronaut]

Could be, but this was the second time I interviewed there and I have had friends interview there, and all pretty much recount a similar experience.

[Mithaldu]

Reviews at a company not following any kind of standard is a red flag in itself.

[d23]

And if they do follow too many standards, it's a red flag. Or if they follow a mix of standards and non-standards. Big red flag there. If the person is wearing nice shoes, definitely a red flag. But you don't want them to be too normal, because that could be a red flag also.

This hypersensitivity goes in both directions. One company may be worse than another at hiring, despite having an equal or better engineering department. Sometimes, you might just get bad luck. Your interviewer might not have had their coffee that day. Or their dog may have just died. Or you may get a guy who just proposed to his now-wife and is having the best day of his life. Giving a reasonable benefit-of-doubt mixed with a bit of critical thinking is probably the way to go, rather than resorting to hard and fast rules that will end up just making you conclude no company is good enough for you.

[thaumasiotes]

> One company may be worse than another at hiring, despite having an equal or better engineering department.

I don't understand this. As far as I can see, the entire goal of hiring is to have good workers, so the company with a better engineering department is better, by definition, at hiring engineers.

It might be that their hiring prowess comes in part (or in whole) from factors largely outside the hiring process specifically, something like "you get to work for Elon Musk", but their hiring is still better.

[collyw]

Just had an interview this morning. To almost all of the "how would you go about this" type questions, my answer was well, it depends on the data type / volume / customer needs.

[robodale]

Your response - totally. Similar experience: I was asked in a technical interview to use the "correct" collection class given the (very academic) sorting problem. I responded with "there is no right answer, so my answer will be the simplest one". According to them that was wrong. The "right" answer was the best performing scenario (although more complex of a solution).

So, again. "It depends".

[soham]

Well said.

That's exactly why it pays to prepare for coding interviews. If companies are not going to be thoughtful about interviewing, candidates can either reject those companies, or prepare for those interviews. My belief is that if more candidates are professionally prepared with those closed-ended questions, this will eventually force companies to be more thoughtful.

[Us: http://interviewkickstart.com]

[collyw]

When you have 15 years of general experience covering servers, databases, programming languages and other tools, its difficult to choose something to brush up on.

[soham]

Agreed, but what is my option? I can't expect companies to just talk about what I've done, take it at face value and hand me a lucrative job. Not to mention that things change in tech so often.