541–550 of 552 posts
Earlier quoted context omitted.
Are you in a position to name company names? Most everybody I interview with does this (at a minimum). I'd love to interview at a company that has a smarter system in place.
See http://sockpuppet.org/blog/2015/03/06/the-hiring-post/ and Matasano.
There's a reason I asked MCRed. He has a unique perspective on this that I value.
Earlier quoted context omitted.
If you're a top ten percent programmer who charges $137/hr then this whole discussion probably isn't oriented at you. By definition, most programmers are not in the top ten percent. They make money by sitting down and writing code, not by projecting confidence and machismo. So why shouldn't they prove their abilities and evaluate the company and it's general environment by sitting down and actually coding? I'm very o…
Actually, $137/hr is pretty cheap..
Earlier quoted context omitted.
"whiteboard hazing" there are two types of whiteboarding questions. The kind that's a perfectly reasonable thing to ask (i've had people ask me to develop some simple system... which I think is reasonable, because i'll do that as part of the job) but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.
The best argument for whiteboard algorithm questions is that they (to some degree) filter out people who think that whiteboard questions are "an exercise in memorization". I mean, whether or not the company actually values the underlying non-memorization skill is another question (as someone who is very strong in that skill, I think that most companies/roles do not have a use for that, and should not test for that).…
I feel the same way about algorithm puzzle type interviews.
Earlier quoted context omitted.
"whiteboard hazing" there are two types of whiteboarding questions. The kind that's a perfectly reasonable thing to ask (i've had people ask me to develop some simple system... which I think is reasonable, because i'll do that as part of the job) but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.
When you figure out how you can memorize your way through Google's interview process, please give me some advice. I study algorithms constantly out of interest, and still only managed to do well enough that they gave me another try a week later. Do I think algorithm questions predict how well you do on a job? No. However I certainly don't think they are just memorization unless you mean memorizing run time of various…
Personally I prefer (as both interviewer and interviewee) a weekend project style format -- pick your IDE, language, have time flexibility, etc.
Earlier quoted context omitted.
>IQ tests are well known to have a disparate impact on some protected classes, so you are treading on extremely thin ice to use one. Really? I mean, I know that the racists have been going on about how some races are dumber than others for as long as the idea of race has existed... but is this an idea that would be taken seriously by the courts?
Absolutely. The concept is known as disparate impact. A test which results in members protected classes being less likely to be selected is not allowed unless you can demonstrate that the test is connected to job performance. There is a famous case from the 70's where the company wasn't even allowed to require a high-school diploma: https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co .
Say a company needs good testers. I would find it very hard to sell myself as a passionate tester. Instead I would say something that's actually interesting to me like AI or machine learning.
In order for something to be interesting, it has to be somewhat unknown. How can you be interested in something you have completely mastered and know everything about. It just becomes process for you.
Earlier quoted context omitted.
For purposes of discussion, let's take it as a given that a work-hire tests are the best way to screen candidates. The effort required to administer an on-site work-hire test is non-zero, therefore I cannot administer such a test to every applicant. I therefore need a way to determine who to bring on-site, in order to administer such a test. I cannot phone screen every single applicant due to the cost involved. That…
I do. I was going to bail from this thread, but it sounds like you see the great potential that this idea can have, if it can work. The truth is that it works. Okay then, one last try: Set up a system that can spin up a droplet for a remote candidate. Any time a candidate expresses interest in your company, spin up an instance and email them a link to it. What does the link do? That depends on your company. Are you m…
We've evolved the same process in my own startup - in the last 2 months we've hired 5 remote programmers in Vietnam and India by giving them 2 rounds of remote work-sample tasks (a simple web app), then ending off with a text or voice interview. We ended up retaining 2 out of 5 of them (both Vietnamese, incidentally) who demonstrated a higher level of ability after they started.
The retention rate is low, so we've been tightening up the process. What we've found is that we probably needed to raise the bar a little by asking candidates to design and architect a feature (DB-backend-frontend) during the chat interview. That would have given us a better insight into their code structuring and teamwork/communication skills.
We've just brought on a 3rd hire (Vietnamese again) who passed our improved interview, and I have a good feeling that the process works very well to weed out candidates who don't have the needed level of ability and scrupulousness.
The best of our hires didn't attend college or have much relevant experience, but was clearly very capable and possessed great initiative. We're really glad to have managed to hire him. Another guy is finishing his 3rd year of college.
In summary, I think remote work-sample tests are fantastic, and I hope you're right that they're the key to winning :)
Earlier quoted context omitted.
Unfortunately, tinkering in your off-hours is a key way for programmers to keep their skills current. The industry changes rapidly and the skills that were most marketable over the past 10 years are not the same as those that will be most marketable over the next 10. If you're not changing jobs constantly, the rate of tech change at your workplace is unlikely to be enough to keep your skills marketable. So you need t…
Why is this not true in other professions? Why don't hospitals give preference to surgeons who like to dissect frogs in their spare time or build better scalpels on their garage workbench?