Although in most cases if the second guy you talk to is perfect, you may still need to look a bit more to be sure.
By seeing the quality of the work that they did and the test cases that they wrote up we had a much better idea as to how they work and what they would produce.
This common Kata experience between the candates gave us much more specific questions that we could ask about the problem, the solutions, their challenges, and their triumphs.
Also agree with asking what they do in their spare time... if they tinker... good, side projects... good.
- the applicant worked for one of the big four (Google, Apple, FB, Microsoft). If these companies gave the applicant a GO at some point, maybe you should too.
- the applicant is self-driven and develop non-work related software. Side projects, etc.
- the applicant brings new skills on top of your requirements (e.g. design, other industries, mobile, etc.)
- last but not least, you should value the experience a lot. Someone who worked 5-10 years on a bunch of different projects will save you a lot of time and money. You could have a genius/fresh out of college, if something goes wrong or requires certain skills they don't teach you at school, the lack of experience will drag you down. Don't hesitate to pay a premium up front and save money in a long run.
Good luck!
Be careful about that; said people are no longer at those companies for a reason. Often that reason is innocuous but there are people who slip through their hiring process and get washed out later.
The other thing to know is there's a lot more process at those giant companies, with good reason; "move fast and break things" doesn't work when you're making OSes or globally used search engines. Some people with long tenure there wind up more adept at managing process than the technical stuff.
- Why you didn't get promoted?
- Are you not landing any job interviews? Because I know you get tones of emails from recruiters
- Are you still learning new things? Do you want to learn new things?
In terms of processes at the big companies, you're looking for smart people... Processes don't tell me if you're smart or not. It's just you dealing with rules like any other human being.
It is not specific to any language and it gives a grade on many many relevant aspects of everyday programming (IDE, automatic build, framework, data structure...)
I asked the dev how he'd feel if he completed the project and the customer said, 'Nah, not interested, thanks anyway.'
His response: 'As long as I get a paycheck, who cares.'
Not sure exactly why, but that just doesn't sit well with me.
What is the developer supposed to say about a project that was instigated without their input and without the input of the potential users and is presented up front as a six month slog before reality doubles or triples it? Would, "When it's canceled, I'll mope for a month and come in hung over everyday while looking for another job" be a more inspiring answer?
A better question might have been, what do you think about this idea?
Your point of concern should be with management, not the developer. But you only talk about the developer?
Sometimes their projects work out. Sometimes they don't. I definitely feel bad when they don't, but I also do the practical thing and keep moving forward with my life.
There comes a point, after years of experience, where you just have to shrug your shoulders and accept that you aren't the one running your clients' show. You can provide feedback. You can be there when they need you. You can do everything in your power to make it a success.
But it's not your thing until you own equity in it. The emotional separation is 100% justified.
First: actually read the resume and letter. Learn about the experience this person has. Unless you're hiring out of a bootcamp, the candidate has worked on something and you should not be walking in blind. (If he or she hasn't articulated it in the resume and letter, then I wouldn't expect to have initiated an meeting.)
I don't use challenges, homework, riddles, quizzes, etc. anymore. Again, we're not starting from scratch. I hear it and wonder, "Do you really think I haven't yet figured out the difference between fifo and lifo?" (Or, "Here's a little, 5-minute challenge. Just a little date math." Oops. Forgot the leap second.)
I focus on problem decomposition. I ask about problems that the person has worked on. I talk about my own systems and have him or her opine on it. We brainstorm. These discussions get into things like:
* What was the situation? Why was it a problem? Was the solution obvious? Was is tricky to intuit, or was it a lot of work to implement?
* What were your constraints? Were they natural or derived? (Perhaps it was a very-low-resource environment, or there was real-time requirement, or it needed resistance to a type of attack, or it required strict regulatory compliance.)
* What was the mental model and how did the individual arrive at it? Did it change during implementation?
This structure has worked for me at most levels of hiring. I can ask a very junior person who, say, writes SQL to generate reports to talk about a particularly challenging report, or one that is particularly elegant. If he says, "I changed the order of operations to get the rows down from 4 quadrillion to 400,000" then I know that, conceptually, he knows about cardinality.
I can ask a director to talk about a project that he ran with a remote team in the same way. If the drop has to happen in sync and you have people in 4 time zones spanning 10 hours, did he wake people up or did he use some kind of technological orchestration?
Also, I think it's worth noting that quite a few very good programmers do not keep very public profiles, so I really don't trust the greenness of a github profile.
>I don't use challenges, homework, riddles, quizzes, etc. anymore.
Unless you don't get many resumes, I find it hard to believe that this is a good hiring flow for you at all. A lot of people who agree with me will often say that nobody has time to be reading hundreds or thousands of resumes, but I'll take it one step further: unless you are rigorously verifying the information on resumes, resumes are basically useless.
It is way too easy to lie on a resume. I don't mean mere embellishment or exaggeration. I mean straight-up lying. I looked at your profile. You have an impressive resume. What would stop me from copying your resume and submitting it as mine? Your impressive positions would be harder to fake, so I'd just lower all the CTO, head, VP, and chief titles to lower level titles.
Let's take this even further. Let's pretend that you actually call the references for the positions on all the resumes that you read. What's stopping an applicant from giving you a friend's number and having them pretend to be their former manager/employer? One could argue that the same sort of deceit works for challenges, quizzes, etc., but there's the additional barrier of at least knowing a decent enough programmer who can take the challenge or quiz for you.
They are saying, in my opinion, that it is important to step away from the S.O.P. because by doing so we gain the clarity of insight from treating them not as cogs to fill a gear ratio, but as human beings that bring an enormous range of abilities that, for various reasons, may not communicate unless one allows them to, hence the example of a root reduction in the db search space.
Sure, you can copy a resume and you might get a phone call, but I suspect we're not going to have a very good conversation.
Regardless, hold your developers accountable to results. Manage by output not man hours.
If within 6 months you don't feel they're a good fit, move on.
- development time
- execution time
- memory constraints
A good programmer should be able to respond to changing needs. They should be able to see the best solution for the current situation. They know what technical debt they are incurring and should identify it in their solution.
Also, if this is a small team then personality should play a large part in your decision. One person can really ruin a productive team. Does the person respond to your feedback well? Where do they show cracks in their facade? Do they explain themselves clearly? Can they think in the abstract or do they always speak in terms of their domain? Will you be able to give them high level directives or will you have to talk them through line level code? Can they do things the way you do things or do they have to change the world when they are out of their comfort zone? Do they feel a desire to throw code out when they don't understand it or can they work with existing code? Do they use phrases like "it's broken" or other catch all phrases that indicate they don't understand something and are unwilling to learn it? Do they ask for clarification or do they make assumptions and quietly go down the wrong path? When they do ask for clarification, is it at a level consistent with their title and experience? I can go on, but I might save it for a blog post. I have learned a lot from having to staff and lead a team and the above have been some of the points that have distinguished the producers from the consumers.
Cheers and choose wisely.
* Make them do a task that is both relevant and realistic with respect to what you do.
* Leave 'natural' traps in the task - code problems that have tripped you up in the past and see if the candidate falls into the same trap or spots it.
* Ask the candidate to clean up their code near the end and watch what they do.