Use Project-based Interviews Instead of “GitHub”
ejohn.org
ejohn.org
They do have the flaw that they might not weed out candidates that are really slow (since they can generally take as much time as they want on a take-home project). They also don't weed out candidates who are willing to have someone else help them significantly with the project.
As such, I've found take-home projects useful in addition to an onsite interview. At a previous company, we would follow up a take-home project with an onsite interview involving a couple 1-hour "code this using any tools/resources you want with no one looking over your shoulder" questions to prove that they didn't cheat on the take-home and that they can get things done in a reasonable timeframe. I always felt it was a pretty useful way of evaluating programmer skill without stupid whiteboard coding.
Asking questions about the work produced is a good way to identify people who cheated. Ask questions about why and what was your intent with this.
- Phone screen with our HR rep to figure out if you're even remotely what we're looking for - Takehome challenge to make sure you can code - Engineer reviews the challenge and, if good, calls you to discuss the challenge and discuss your experience in depth. - If good, come onsite to meet the team, do a couple 1-hour use-anything challenges, and answer a few higher level long-form questions. - Offer.
If you want to hire me but want to see some real-world work first, give me an 8 hour contract and a fair wage.
The issue is that you're working for a prospective company while not being compensated for it.
If only there was a website where one could upload and source code one had written for fun. Perhaps even with repo history. Like a hub of git activity or something.
Then employers could simply browse this website rather than demanding these annoying project interviews.
Additionally the legality of OSS commits is technically still kind of grey for a lot of people with generic "your code belongs to the company" in their contract with their employer.
See also filters like college degrees and past experience, both of which also provide evidence you know what you are doing and put you miles ahead of people without them. Should we also not look at past experience and education?
I do not disagree on the value of looking at OSS, I just feel that requiring it is going to cause you to pre-emptively filter your candidate list.
Now if that is what you want there is nothing wrong with that, it just may not be obvious that is what you are doing.
Note that I am assuming you are looking for complex work, github is great for seeing if they can at least program, but I would trust a quick whiteboard problem more for that level of technical aptitude.
(Shameless plug: I am looking, if anyone is after a decent Python programmer. Email in profile.)
It goes roughly from whiteboard problems to sitting at a computer with them over your shoulder to a couple hours before the interview to a full week of work. Everyone knows the lightest form is necessary the big question is how much you can get from increasing the complexity before people get annoyed.
The large/hot companies have no problem finding enough candidates to jump through their hoops and, wisely or foolishly, many startups are content to sit on unfilled positions until they find someone they think meets their criteria. So only a subset of sellers have the leverage many think they do.
When hiring a designer, part of the interview process is showing things that you have done. It doesn't matter if they're real or not, only that you were the one who created them. You also talk about 'your process' when designing those things.
Much the same, I believe that hiring an engineer should be about showing your portfolio and talking to your 'process', whatever that may be. It's a far more interesting way to get to know a person, how they reason and what they're capable of.
Design is an artistically creative process. Takes talent, I wouldn't hire a designer if I don't perceive the work they've made as beautiful.
But hiring an engineer, there are certain things you can overlook in favour of their capacity to actually build something. I can overlook their code quality, but only because we have a boarding process in which one of the things we make sure a new engineer understands is our quality standard in writing code, the systems we use to enforce that standard from code reviews to pre-commit hooks and lint checking.
An engineer has the capacity to adapt to these changes of both quality and process.
IMHO, you can't teach a designer who isn't talented how to make beautiful things. Albeit beauty is subjective, but there's still a common ground upon which the majority will perceive this piece of art work as beautiful.
I'm very much NOT interested in code quality from an engineer. I very much AM interested in how an engineer thinks and approaches solving a problem.
One way to start that conversation is to have a code portfolio that they can talk to. Why did you do this? What were thinking about when you did that? Did you start writing some code then refactor? Did you think about the problem for 3 days before you started writing? Do you diagram on paper? Did you model the data structures before you modeled the application itself?
These are the sorts of questions I'm interested in when I hire someone; They're also the sorts of questions I want someone who is hiring me to be interested in.
Using your words:
To me, writing code is an artistically creative process as well, which takes talent. I wouldn't hire an engineer if I don't perceive their thinking as beautiful
The process for creativity doesn't change just because the expression changes. Compare the process of writing code with that of painting and you'll find a lot more similarities than differences.
PG even wrote a book about it.
If I'm are hiring an engineer, the last thing I'll consider is how well is their code because that can be enhanced (albeit to a certain level, as per pionar's comment which I also agree with)
If you are hiring a designer, then that's likely the main aspect you'll be looking at, how beautiful/creative their work/solutions are.
Likewise, you can't teach a developer who doesn't "get it" how to make beautiful things in code.
I made this iPhone app(https://github.com/jyothepro/tictactoe) but they rejected me. Reason for rejection was not very clear. I felt I wasted my time :(
And I have a feeling that I'm gambling - in terms of allocating time vs what I'll get. That's why paid projects make more sense - with defined goals.
In the OP's case - tic tac toe game is completed? playable? that's it - he gets paid, no matter if they don't hire him for some other reasons.
Not so sure about that. I looked at parent's code submission. In particular, his game logic looks like this - https://github.com/jyothepro/tictactoe/blob/master/TicTacToe...
This is unduly verbose & has newbie programmer written all over it.
Here, I just wrote up the same tictactoe over lunch in the repl - https://gist.github.com/krishnanraman/7591435
Without much thought into optimiziation, refactoring etc., its about 20 lines of actual code. Random TicTacToe is a very simple game. Even if you take that Scala & translate line by line into Objective-C, you shouldn't see an exponential explosion from 20 lines to 400+ lines for game logic alone.
Even I dint spend any time in refactoring or optimization as this is just a hack to get past a job interview.
When an interviewer gives you tasks like this do they expect optimized and refactored code?
I've written a ton of code in my career, and 99% of it is wholly owned by the companies who I wrote it in the employ of, and I don't have the legal right to show it to anyone much less put it on public display. Some people would say the answer to that is doing OSS/other projects in my spare time... but I have hobbies, and other interests, and don't want to spend my whole life writing code.
Give me an opportunity at no cost to you and low (time) cost to me to show what I can do, and we will both be in a better position to evaluate each other.
However, I've given that issue a lot of thought, and I've changed my mind in that there is something really really nice about it: it gives unemployed programmers a lot of breathing room.
You may think that it's really easy to get hired, and in the top-5 cities it might be, but in other markets even very qualified people can't get interviews lined up quickly.
If I were to get laid off tomorrow, I would love the fact that there are employers who, after an initial screen, would take me in for a week at contractor's rates to evaluate me.
1. I would get paid, and after being laid off that would be a tremendous relief.
2. It is much easier to get in the door. Employers always worry that the person they are bringing on won't cut it and will have to be let go. With this test, it is very easy for both sides to try it out without worrying about an expensive "divorce."
And what about unit tests? If they give you a problem to code on a whiteboard, do they want to see TDD red green refactor cycles?
And is this the only problem they want you to work on in the hour or is there another one coming when you finish?