3 ms·

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 anywher

by 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.

by zainny 13y ago

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.