How I Interview
rkoutnik.com
How I Interview
1–10 of 129 posts
Re: How I Interview
#2This methodology may correctly filter the candidates the author is seeking, but if this made up the bulk of any interview I attended, it would probably turn me off the role.
FWIW, when I attend an interview, as either party, I want to have a discussion, a bit of back-and-forth, and crucially to determine if it's likely we'd be able to get on, day to day. Coding competency is not the only important thing. And anyway, it can easily be established via a bit of white-boarding, conversation, and preparatory reviews of any existing work they have online. If you are in doubt, then maybe pair on a fun little algorithm,... something that's not solved, and not dull. Something original would be best.
Being given a pre-packaged task to complete feels very procedural and bland...
Re: How I Interview
#3Interesting points. Like the idea of the giving a developer actual development tasks.
This is how I interview - We have a bitbucket set up with a project very similar to our current site. We simply ask everyone who applies to get the code from Bitbucket and install it locally. And then fix a simple bug. Most developers who are well versed in the basics are able to install the code in 2-4 hours. People new to something specific are stuck for a day. It helps us weed out people who are a) Not comfortable reading code b) Not hungry enough to ask questions or google a little bit if they do not understand c) Not able to debug and fix simple issues.
So far all developers who have lasted that test have been good technically. Its another challenge to keep them motivated over long periods of time.
Re: How I Interview
#4This methodology may correctly filter the candidates the author is seeking, but if this made up the bulk of any interview I attended, it would probably turn me off the role. FWIW, when I attend an interview, as either party, I want to have a discussion, a bit of back-and-forth, and crucially to determine if it's likely we'd be able to get on, day to day. Coding competency is not the only important thing. And anyway,…
> Being given a pre-packaged task to complete feels very procedural and bland...
This part is important:
> Having a consistent test also allows me to compare candidates easily and without bias.
Also, I think most people would care more about the content of the exercise, rather than whether it is prepackaged or not.
Re: How I Interview
#5I had an interview like this recently. A "live coding" exercise after (in their words) two excellent phone screens.
The test was to implement a class which would be run through a bunch of unit tests. Simple right? It turned out to be a disaster.
First was the choice of language. They offered to take it in JS, Ruby, Python, or Java. I'm a .NET developer whose competent with JS, but I really could be better at it. I asked to take it in C# but they refused and said it's not about specific language knowledge. So I did in in JS. I turned out to be almost completely about JS specifics and quirks. Because I've been learning JS recently, I've had the fortune of having to avoid the bad parts. When asked to recite them I struggled. This part is obviously my fault but if I had been allowed to perform in C#, I would have done a hell of a lot better.
Second was the environment. I have very limited exposure to programming on a Macbook and I spent the first few minutes struggling to translate all of my shortcuts. During a timed test it was pretty disheartening to not be able to type as fast as I could. I haven't used Sublime before but the default theme was near unreadable and I was allowed to switch it after a few minutes. The third was the test framework. I really wasn't familiar with how Jasmine worked in the browser, and it showed. Again, my fault. But taking 5 minutes to familiarize me with their setup would have made things go much, much better for me.
Before I get jumped on for blaming them for my poor performance, this was for a test automation role. I explicitly said that my JS/Jasmine/etc. skills were not that great and they still brought me on site.
Honestly, I would have preferred the whiteboard. Each test took up nearly the entire period, leaving very short time for talks about what I really care about - culture. I have a Github with a bunch of good projects. I've been employed as a developer for a while now. I can obviously program well. Drop the bullshit and lets talk.
Re: How I Interview
#6Would be funny to come into an interview as the candidate and give the employer pre-packaged tasks to complete to evaluate them on, to decide if I as the candidate actually want to work there.
Re: How I Interview
#7"You wouldn't evaluate a chef's ability to cook by depriving them of saucepans, why cut off Google?"
Depriving of recipe books is perhaps a better analogy? I think depriving of saucepans would be like hiding the keyboard!
That actually works pretty well, even doctors are expected to look things up if they get stuck. Why should programmers be any different? SO is extremely useful for funny edge cases in software that someone else spent an afternoon trying to figure out.
Re: How I Interview
#8This methodology may correctly filter the candidates the author is seeking, but if this made up the bulk of any interview I attended, it would probably turn me off the role. FWIW, when I attend an interview, as either party, I want to have a discussion, a bit of back-and-forth, and crucially to determine if it's likely we'd be able to get on, day to day. Coding competency is not the only important thing. And anyway,…
> Being given a pre-packaged task to complete feels very procedural and bland... This part is important: > Having a consistent test also allows me to compare candidates easily and without bias. Also, I think most people would care more about the content of the exercise, rather than whether it is prepackaged or not.
I get that. I just would rather not feel like a monkey being prodded whenever I attend an interview. An interview being repeatable (for comparative purposes) brings no value to the candidate.
Re: How I Interview
#9Completely am on-board with the descriptions of false positive/negative
I agree that this seems like a good way to establish someone's technical competence. I do wonder though from the interviewee's side what the optimal time to spend on one person is. It's kind of like dating right? (Well what I imagine dating would be like if I lived in a big city) You have concurrent first impressions with maybe second and third follow ups before you seal the deal. This may be a bit like asking for a relationship on the first date.
Demonstrating ability in this manner works for more junior people who maybe don't have a github or other personal projects, but I'd consider discussing and reviewing those more valuable.
Re: How I Interview
#10I was really liking this piece, but one inherent flaw of the example given is that I've already implemented minesweeper in javascript once a couple years ago for a programming challenge, so I'd have a major advantage over most candidates.
For example, I immediately recalled I solved the problem of mine placement with a 1 liner like:
var cells = ('*'.repeat(mineCount) + ' '.repeat(size - mineCount)).split("").sort(function() { return math.rand() - .5; });