Yeah, but B5Geek's is a pretty entry-level thing. I've encountered whiteboard tests where you have to recreate an algorithm that someone spent their PhD thesis creating. It seems like a good way to find "geniuses", but it just isn't practical.
In a lot of ways, it's a matter of identity crisis for software developers. We're all, industry included, not quite sure whether we're mechanics, carpenters, architects or scientists.
I've taken a whiteboard test that asked me to come up with an algorithm that was difficult for me. I got the job even though my solution was horribly inefficient (and I knew it), and the interviewer later told me that the point wasn't to see what algorithm I knew - it was to see if I acted like an ass when I didn't know stuff.
Not sure that's a good test either. When tasked to figure out something as part of a job, by a manager one knows and trusts, who takes feedback of "I don't know how to do this but I will investigate it", a person may act one way, whereas being tasked with someone's PhD thesis by a stranger on an interview may lead to a very different response.
I know I am far less tolerant of bullshit interviews than I once was, and would have far fewer qualms vocalizing what I'm thinking - "I don't know. If I saw this in real life I'd check Google, because it reads exactly like the sort of contrived problem used in interviews and thus is well documented, and likely solved quickly by those who have memorized it. I am not one of those. I'll take a stab at it now if you just want to see how I reason through it, but if coming up with an efficient, correct implementation is part of your criteria we can probably save both of us the trouble" - is that considered acting like an ass?
True. Testing for sysadmins is easier: you're after a way of thinking. So a competence test ("can you do what you claimed?") with a freeform "keep notes on your thinking along the way" is quite informative. You still need to interview, of course.
I confess I don't know how I'd apply this to developers. They pass fizzbuzz, OK - what do you do next?
> I confess I don't know how I'd apply this to developers. They pass fizzbuzz, OK - what do you do next?
I know what I would do, just have a 10 minute conversation with them about technology. I can easily figure out just where a person is in regards to their development as a programmer just by listening to them talk about what they're paying attention to in the tech landscape. If they don't blink when I mention Hacker News, I know they're on the right track. Do they know what Go is, or Haskell? Do they have an opinion about Node.js?
These criteria are intended to gauge motivation and enthusiasm in the absence of an impressive track record. If they're capable but not highly motivated, then that's fine so long as you're only hiring them to do stuff inside their comfort zone. We have a Microsoft guy just like that. If they're motivated but not capable, then with coaching they'll be able to do anything. The best way to discover someone's motivation is to get a gander at what they're thinking about when they aren't working.
If you're looking for someone who is motivated and capable, you can eventually find someone like that, but you'll have a hell of a time keeping them. Developers have so many options these days that you need to have at least 3 of: competitive salary, decent perks, fun work environment, a glamorous field; in order to hold on to them for longer than a year.
Most companies are lucky to manage one, if they're very lucky two. Since salary is often the easiest thing to manipulate and honestly the most important to the employee, err on the side of paying too much. It's expensive but not having competent developers is far more expensive.
Not infallible - I could talk tech near-perfectly (I am a native speaker of BS), but I am most definitely not a coder pretty much at all - but a good start.
Also, using HN and its fads as a measure of motivation sounds a little elitist. There are really awesome and motivated coders out there who couldn't care less about politics, mainstream tech media news articles, gadgets, Apple-does-this, Google-does-that, cool new language or JS toy of the week... these coders are likely focused on their code instead.
Programming is a wide field, there's much more to it than the front page discussions on HN can cover.
Of course, if you're looking for a Web developer to make "cool new stuff" for the latest fadgets..
You make light of web development, but that's driving the enormous demand for programmers in recent years and all of our salaries. I bumped my pay $20K when I took this job and I'm now asking for $30K more after a year. Most fields calcify after a few years and salaries level off as the managers do their thing. But making "cool new stuff" and the "latest fadgets" is still really hard. It might be the fashion industry, but business is booming.
Speaking as an iOS developer who's had a hand in hiring, it's the same as the "slightly broken Apache and Tomcat" scenario someone posted for sysadmins. We ship people a slightly broken app with a few common-yet-googleable problems, then ask them to build a tiny thing on top of that and ship it back to us.
The ability to solve common problems acts as a good proxy for experience, If they can't google how to fix a retain cycle or a broken constraint, we know they probably don't know what they're talking about.
The ability to build a good, small system on top of the broken app acts as a good proxy for development talent. If they can't easily set up a dead-simple delegate to do an asynchronous web call, they can't hack as a mobile developer.
Most importantly, if they don't care enough about the job to take two hours to whip up a super-simple app, then we don't have to waste our time interviewing them.
For iOS developers I found that a good test was to download and parse some XML or JSON API of a web service and display the result in a UITableView. . It' surprising how many people can't accomplish this.
For developers that have the academics, but not the experience, I've always said that the industry needs to adopt the apprenticeship programs that other trades have. Where you do a mixture of work for the company, and trade schooling run by the industry to teach you the specific skills you need.
For example, an IBEW apprentice will do a lot of gruntwork on the job site. Pulling wire, for instance. But they'll get exposed to how things are done, to trade industry expectations, and what a project looks like from start to end. Part of the week, they spend in a classroom learning the specifics of their trade. Not just the high level theory, but the nitty gritty, based on real world applications and problems. This apprenticeship lasts from 2-5 years depending.
I don't see why this model wouldn't work really well with programming.
Apprenticeship requires a constant stream of mentors. I'm not sure there is an ample supply of professional programmers who would be interested in taking on the responsibility of mentoring in addition to their full-time jobs.
It really depends what those professionals are used to. I did an Apprenticeship as Software Developer in Switzerland. That is, 1 year of school followed by 3 years alternating between the company and the school. So once you start at the company you already have a viable amount of knowledge in programming, databases, networking, etc and supposed to be able to work on your own.
You don't get constant mentoring at the company, but can ask one of the developers or fellow apprentices when you're stuck with one of the tasks you get assigned. Or for example, any time a developer had a small task that he felt, I couldn't do by myself, or it was too time critical he just asked me to sit beside him and watch, listen and take notes while he did the work.
How it works is different in any company but the outcome should be the same: real world experience on real projects with real clients and their time/budget constraints.
That means, once your finished and a professional yourself, it
isn't a question of interest but a completely normal thing to help out the apprentices. Because that's how you got to the point where you are.
We may laugh, but starting in technical support gives you an idea of how your users are using your product, if your documentation is accurate and helpful, what the pain points for people not in the department you are destined for are, and gives you an idea of how the product works.
It also quickly weeds out the people who can't effectively communicate before they get to the programming team.
We've been rotating the sysadmins through customer service. Not taking calls (our CS calls tend to be long and detailed, and a n00b isn't going to help), but being there for the CS people. It's been marvellously instructive. It also cheers the CS people that someone cares. Now we need to get the devs doing the same.
When did block release training or work experience start getting called co-op given that in various areas of the world a coop co-op means a cooperative like Mondragon.
I have only seen it (co-op) used in the last few years.
Algorithm tests only measure the number of man hours the candidates spend on career cup daily. Or how good they are rote memorizing things.
There are many ways to check how good a candidate is at doing their actual work. For instance you can take a candidate to a code review and see what kind of inputs they contribute to the discussion. This alone will give you good deal of idea on how well they understand code and quality. There are other ways, like say asking them to write unit test cases for a class- That would give a lot of idea on how they think with regards to breaking and fixing things.
One more way I have after doing basic checks is pair programming, or picking a totally new problem and working with the candidate to see how they think, how they work and how good their communication skills are.
There are many other ways too. Recently I've been given coding assignments for very practical applications, though those turn out to be a little difficult and time consuming. And at times the expectations are very high. Like asking the candidate to complete a whole application in very short times. It can be hectic with your current job, and a family. But generally those are a good indication of how good the candidate will do at their actual work.
In a lot of ways, it's a matter of identity crisis for software developers. We're all, industry included, not quite sure whether we're mechanics, carpenters, architects or scientists.