The “perfect” code interview

You’ve probably been there — Interviewing a potential developer. Most people (both sides of the table) dread this situation, and with most interview “processes”, its no fucking wonder. (Yeah, I went there kids, strap in.)

A disclaimer

Interviewing is different for every person & company, there is no such thing as a “perfect” strategy for an interview. Tricks filter out the baddies, and also some goodies too, so let’s try to come up with something more accurate.

Bad things about code interviews

  • Tests/tasks given often consist of non-realistic scenarios that you’ll probably never encounter — Write a game? Whattt?
  • Programming isn’t theatre or performance, “on demand” isn’t how your job works
  • Stress compounds in the mind of the interviewee; You wonder what your interviewer is thinking, about trying to stay cool and collected… anything other than the task at hand

The rundown

  • The developer in question has a github account — cool. You can see their interests, and the fact that they’re engaging with the community around them. How well do they do? Do they write tests for open source? Pull requests? Communication? Code quality?
  • Find a project of theirs, perhaps a favourite / most actively contributed to.
  • Setup a remote meeting time, connect with them beforehand on skype, google hangouts, or whatever you can use to screenshare with them. Keep it simple.
  • Now, the project: Are there any bugs/issues listed? If there aren’t, come up with a new feature idea. Pitch it to the developer.
  • Talk through the bug or idea, and ask them to spend 20 minutes fixing the bug, or implementing the feature.

Why this is awesome

  • They’re using code that they’re familiar with
  • You get to see their workflow
  • You get to talk over creative ways of addressing the changes required
  • They’re using their computer, the project, editor, bashrc, autocompletes — everything is ready to go
  • You’ve demonstrated that you understand (and perhaps value) their work.

I’ve already said that no technique is perfect, but this technique could be fantastic for situations where you feel that this person can code, but you want to understand how they communicate, deal with real requirements and generally work (toolchain, process, ideals & methodology).

You’re a professional, someone has given you the job of figuring out who cuts the mustard, so you better get good at it. Do you have a better idea?

Rad links from around the web #1

I spend every minute of the day looking at amazing things that other people are doing on the web. Studio buddy Glen helped convince me to compile a list.

Its Friday! Break out the beer & Tumblr!

Yesterday I (finally!) released Gallery CSS, which is a simple gallery carousel — Normally, there isn’t anything particularly interesting about carousels, except this one is written using only CSS (no JavaScript, no dependencies).

Writing Gallery CSS was a total experiment, I didn’t want to have to use jQuery, and some “do everything” plugin. So I sat down and forced myself to find a working solution. Through this process, I’d inadvertently learnt a lot of tiny details… which I think is what every good open source project does.

I took those learnings and recorded a 40 minute, 720p screencast, it covers build tools, process, css animation & transitions, and some other rad tips along the way. Not bad, right?

So begins my experiment: Open source for free, $19 screencast to learn what I had to know to put it together.

Go get yourself a copy! (Please)

Yesterday I (finally!) released Gallery CSS, which is a simple gallery carousel — Normally, there isn’t anything particularly interesting about carousels, except this one is written using only CSS (no JavaScript, no dependencies).

Writing Gallery CSS was a total experiment, I didn’t want to have to use jQuery, and some “do everything” plugin. So I sat down and forced myself to find a working solution. Through this process, I’d inadvertently learnt a lot of tiny details… which I think is what every good open source project does.

I took those learnings and recorded a 40 minute, 720p screencast, it covers build tools, process, css animation & transitions, and some other rad tips along the way. Not bad, right?

So begins my experiment: Open source for free, $19 screencast to learn what I had to know to put it together.

Go get yourself a copy! (Please)

Recently I worked with Art Processors to create the “Replay” feature for The State Library of New South Wales’ “Curio” — Essentially, you get to see which exhibits you viewed at the gallery after you’ve left (you’re geotagged through the building as you explore).

One particular part of this build proved difficult, I thought it may be worth sharing — The polygonally (is that a word?) masked images:

To get this effect to work on webkit browsers, I was able to use the proprietary webkit feature: -webkit-mask-image, with an SVG polygon image.

In Firefox (or browsers that actually handle SVG well) — I hand modified the SVG polygon image, adding a clipPath that also contained a copy of the original polygon.

I also added some IDs so that the clipPath and original polygon could be referenced separately, then it was just a matter of changing the CSS so webkit would reference the polygon and Firefox would use the clipPath.

For some extra icing, I added a transition: all .25s so that the mask-size would be animated when changed.

Curio was a blast to put together, I can’t wait to see what ArtPro come up with next time.