Whenever a post like this comes up I'm always curious why so much of developer interviews are focused an algorithmic performance. Is it because it can be mathematically proven while so much of what otherwise makes "good code" is subjective?
The Programming Interview Experiment
21–30 of 59 posts
Re: The Programming Interview Experiment
#22At this point in my career (professional developer since the late '90s), I am extremely picky about who I work for. The interview is a two way street, where the prospective employee also gets to ask questions to the potential employer.
In the described workflow, the candidate must spend several hours before talking to anyone in depth at a company. This scenario would simply not work for me. I will not spend hours of my time for a company that I potentially might not want to work for.
Re: The Programming Interview Experiment
#23As someone who completed grad school and went through many interviews not too longer ago - I can tell you that this type of process is a much, much more enjoyable than the typical phone + whiteboarding interviews.
I think that some companies become so intensely focused on hiring the best candidate that they sometimes lose touch with the fact that the candidates are human too. Interviewees are rational and trying to find a job that has a best fit. By taking the time to give them a project to work on, it allows them to get a taste while demonstrating that you have respect for them.
My favorite interview was where a company gave me a sample data set, and basically said "Do anything with this in python". I ultimately didn't get that job (not enough experience), but I remember that company and the guy who I went over my creation with, and now respect them more than the dozen other companies who made me feel like I was on a conveyor belt.
Re: The Programming Interview Experiment
#24This part is the key, to me: >The second thing is the strong focus on topics taken from >classroom algorithms and the lack of concern about >practical programming ability. A candidate might somehow >remember that the way to implement an optimal string >suffix matching function is to use a suffix tree, but >where is the question that gauges the ability to create, >test, and deploy a complete application in a reasonabl…
I thought that was a an unfair comparison. One is a small piece of trivial knowledge, the other is a huge amorphous amount of voodoo and experience. But I agree that practical knowledge trumps theory.
Re: The Programming Interview Experiment
#25What would happen if an interviewee 'flipped the script' - gave the interviewer a coding challenge? Maybe under the guise of assessing the skill level of his potential co-workers? Is there any way an interviewer takes the bait?
Re: The Programming Interview Experiment
#26What would happen if an interviewee 'flipped the script' - gave the interviewer a coding challenge? Maybe under the guise of assessing the skill level of his potential co-workers? Is there any way an interviewer takes the bait?
Or, what if the interviewer explicitly challenged the interviewee to come up with an interview coding challenge? And perhaps even worked the challenge, with the interviewee hinting, helping, and evaluating? Maybe it would be a good way to demonstrate complete command of a subject, or the ability to think on one's feet, or even to evaluate the candidate as a teacher/leader of younger developers?
Re: The Programming Interview Experiment
#27I had an interview once where I did not have to write a line of code - it felt very refreshing to have my capabilities respected, although I just somehow lucked out it turned out.
Interesting- I have the opposite reaction. I would (and have) refused to work for a company that doesn't ask me to code in an interview. It may be nice for me, but it means they probably didn't ask my potential coworkers to code either, and I don't want to work on a team picked like that.
Yep. Fear of failing a technical interview keeps me from applying to places and keeps me learning new stuff, but I wouldn't want a job that I could talk myself into.
Re: The Programming Interview Experiment
#28Earlier quoted context omitted.
But what if the ops engineer can pass the coding challenge? He maybe trying to change roles. Or the dev that only knows pascal - if they can pass the challenge using pascal then I'd think they could easily learn whatever coding language your team uses. Learning a language is easier than learning coding. That's what I like about coding, and about these blind challenges - it's purely skill based. If they want to apply…
It is possible that someone with little dev experience could complete our challenge. We were mostly trying to avoid wasting time: theirs to complete the challenge and ours to review it, if we thought it was extremely unlikely they’d complete it. However, when I referenced the hypothetical ops guy, I was referring more to a misalignment of goals: someone looking for a job where they’d be doing more devops stuff vs our…
> However, when I referenced the hypothetical ops guy, I was referring more to a misalignment of goals: someone looking for a job where they’d be doing more devops stuff vs our need for a dedicated developer.
If someone were looking for a devops-oriented job, why would they be applying for your non-devops-oriented position?
Re: The Programming Interview Experiment
#29This is a great post and I agree with everything you say and I am glad you guys are doing this.
I just wish you had more information about your company online (Angellist/Crunchbase etc). I think few people would be willing to put in 3-4 hours on a coding challenge unless they had a good idea about your funding, size etc.
I might have got a coding challenge from you a few weeks back but skipped it because I didn't have enough information. Ah well.. might do it this weekend.
Hope this helps!
Re: The Programming Interview Experiment
#30Why ask to see source for a project above and beyond the work-sample test you've already administered?
I think work samples are a wonderful way to screen candidates (really, the best way) but to presume that all qualified candidates will have an additional sample of code (to the scale of a "significant project," even) available upfront for you without requiring an additional commitment seems disingenuous.
You end up applying an implicit filter for "developers who feel confident and comfortable contributing to OSS and/or possess copious free time for a personal project," which probably isn't really what you were trying to select for and tends to unfairly filter out certain types of candidate.