4 ms·

In pretty much all of my interviews, there were always three phases: 1. The interviewer asks about my portfolio, previous projects etc 2. The interviewer asks

In pretty much all of my interviews, there were always three phases: 1. The interviewer asks about my portfolio, previous projects etc 2. The interviewer asks obscure technical questions. I've been asked, more than once, about the structure of .NET assemblies and MSIL. 3. The interviewer asks some abstract "outside the box" question, usually involving bit twiddling (they seem to like that) They usually like the portfolio, and I usually screw up on the technical & outside the box questions. I always feel like saying "Look, here's the work I've done, you can see its quality. This is real life work I'm showing you here, not some obscure part of some technology neither I nor you care about. Hire me on that!" I've never understood why a good portfolio isn't enough to get you hired to most places. Oh well.

zainny 13y ago
This is so so true in my experience as well. I think I've got a really rich portfolio of software I've built (and shipped) yet whenever I've interviewed anywhere it is barely a talking point (even if I try to steer conversation in that direction)...instead, it all comes down to answering some esoteric technical question almost completely unrelated to the domain I'll be working in. The way most companies hire developers today is a complete and utter fucking travesty.
- benjamincburns 13y ago
  Reviewing your portfolio at a level which would show prowess in technical detail requires a lot of time. Answering a few bit twiddling questions dosen't, and they're almost always required to be asked to all candidates as a matter of policy. That said, if your portfolio very very easy to browse it'll definitely score you some points. Just make sure you've got the average person from the movie Wall-e in mind when you're considering how to make it "easy to browse." I'm responsible for a lot of technical interviews where I work. I think we've got a good process down. We have a simple "walk me through your resume" phone screen, then we send them two programming problems that take a few hours to complete, and then we bring them in for an on-site. If you pass the first phone screen and if you submit good-faith solutions to the problems, you're pretty much guaranteed an on-site. The first of the two problems is more of an infrastructure type problem with an extensibility requirement. It involves looking for files in a directory and carrying out some simple pluggable actions on them. The second one involves writing a custom, optimized data structure. The naïve solution is very quick and easy to implement, but our performance threshold for the sample dataset requires a more advanced solution. Almost everybody gets the infrastructure one w/o any problems. We mostly use it to look at their code style and how they'd structure an extensible program. Almost nobody submits a solution to the second problem that comes in below the maximum time specified in the performance threshold. This is okay, as the goal of the second interview is to discuss these solutions and the problem solving process that went into them in depth. We hire a bunch of people who've gone on to perform well who didn't submit optimal solutions, and although it's rare, we've declined to hire people who did submit an optimal solution. It's the conversation we have that's important, not the code.
- duaneb 13y ago
  To be blunt, you're most likely nothing special—you're probably applying against similarly skilled candidates, so it's much more about weeding out the false positives than it is at getting any particular candidate.
mccolin 13y ago
Having been on both sides of the interview a number of times, I can say the primary reason I've asked the "phase three" question is more to gauge how you think and how we work together. The problem itself isn't the most important part.

zainny 13y ago

This is so so true in my experience as well. I think I've got a really rich portfolio of software I've built (and shipped) yet whenever I've interviewed anywhere it is barely a talking point (even if I try to steer conversation in that direction)...instead, it all comes down to answering some esoteric technical question almost completely unrelated to the domain I'll be working in. The way most companies hire developers today is a complete and utter fucking travesty.

benjamincburns 13y ago
Reviewing your portfolio at a level which would show prowess in technical detail requires a lot of time. Answering a few bit twiddling questions dosen't, and they're almost always required to be asked to all candidates as a matter of policy. That said, if your portfolio very very easy to browse it'll definitely score you some points. Just make sure you've got the average person from the movie Wall-e in mind when you're considering how to make it "easy to browse." I'm responsible for a lot of technical interviews where I work. I think we've got a good process down. We have a simple "walk me through your resume" phone screen, then we send them two programming problems that take a few hours to complete, and then we bring them in for an on-site. If you pass the first phone screen and if you submit good-faith solutions to the problems, you're pretty much guaranteed an on-site. The first of the two problems is more of an infrastructure type problem with an extensibility requirement. It involves looking for files in a directory and carrying out some simple pluggable actions on them. The second one involves writing a custom, optimized data structure. The naïve solution is very quick and easy to implement, but our performance threshold for the sample dataset requires a more advanced solution. Almost everybody gets the infrastructure one w/o any problems. We mostly use it to look at their code style and how they'd structure an extensible program. Almost nobody submits a solution to the second problem that comes in below the maximum time specified in the performance threshold. This is okay, as the goal of the second interview is to discuss these solutions and the problem solving process that went into them in depth. We hire a bunch of people who've gone on to perform well who didn't submit optimal solutions, and although it's rare, we've declined to hire people who did submit an optimal solution. It's the conversation we have that's important, not the code.
duaneb 13y ago
To be blunt, you're most likely nothing special—you're probably applying against similarly skilled candidates, so it's much more about weeding out the false positives than it is at getting any particular candidate.

mccolin 13y ago

Having been on both sides of the interview a number of times, I can say the primary reason I've asked the "phase three" question is more to gauge how you think and how we work together. The problem itself isn't the most important part.