We’re growing! Which means we’re hiring developers and designers of caliber whose talents we can utilize to relieve some of the pressure upon our existing team members, as well as begin work on projects that we simply haven’t had the time to devote the proper energy to. With this in mind, we’ve started the process of pooling the intellectual might behind Sourcetoad to review resumes and come up with the herculean trials to test the mettle of our applicants.
I personally hate writing resumes. I always feel it needs more or something different to make it stand out. Reading them isn’t one of my favorite things to do either – buzzwords make my skin itch. Maybe it’s something to do with sitting in a few meetings with SEO experts several years ago and being terribly impressed with the amount of hot air. Alas, I do it because I don’t enjoy being too overwhelmed and new blood is often a good thing for a stagnating project.
Education and experience are the major players. Having a degree means you can learn and usually means you can survive the social structure of college. Assumptions are made about your ability to interact with people off of the name of your school alone. Party school? Maybe not so dedicated. Very tech heavy? Might be an antisocial type. They are again, assumptions, but at least it gives you a base point of what the person probably knows.
Self taught is the hardest to get a feel for; as it lacks the structure of a regimented education. You pick up things as you find them. Depending on your willingness to learn, you might be a walking encyclopedia or you might be someone who knows just enough to get the job done. There is no way of knowing this when you’re only looking at a piece of paper which leads into the next point…
ALWAYS HAVE A PORTFOLIO. This goes for everyone. I will interview (and probably hire) the person with a decent portfolio over someone without every single time. It’s not a hard thing to create: a simply designed website, clean and easy to navigate. Some examples of your work (working web links, pictures, public repositories) and you’re done. A couple of hours out of your day and you have something that tells more about you than a single piece of paper ever could.
Then there is the interview itself. What kind of questions should we be asking is a pretty important question in and of itself. Technology questions are important but are they really that important with the prevalence of information? Proving you know the subject matter will always be important. If you don’t know the difference between a foreach and a while loop and when to use each – that’s a problem. However, I think asking someone to memorize the manual is a bit much. Interviews shouldn’t be vocabulary quizzes. All you can ascertain from answers to those questions is if the current education system of consume-and-then-regurgitate-facts worked. Prove knowledge of the language/framework – which can be done simply by submitting a few code samples -and then move on.
Practical code questions such as, here is a sample of code, fix it or write your own solution for some problem. are in my opinion, the best way to determine practical knowledge of language/framework and one’s ability to reason respectively. Personally, I give more credit to someone who can reason through a problem, even if their practical knowledge is lacking. Coworkers and the internet can fill in the gaps of which function to use if you can figure out what you want it to do. (This is, of course, for more entry level junior positions; mid-level and senior positions need both.)
Unless you’re working alone (remotely) and the only contact you have with your coworkers is some convoluted dead drop system involving dark alleys and secret pass-phrases to get repo updates, your ability to play well with others is beyond important in a small company. It’s hard to judge this in an interview because people usually put their best foot forward in order to make a good impression. We don’t know how someone will react to a 4am outage, bringing several major systems to a screeching halt, until it happens. Sure, you can ask. But honestly, who isn’t going to answer that question with some variation of, I will be concerned and then buckle down to handle it? I’m not saying an applicant shouldn’t have shiny shoes, but don’t fake it too much. It’s a disservice to both parties: you’ll be unhappy working in an environment you might feel you have to keep up an appearance for, and we’ll feel you pulled the wool over our eyes.
Anyway those are just some thoughts.
