Do code tests work well? Is there some saas product that can help test engineers? Some other method i've never heard of?
Big companies whiteboard because that's how it started, everyone who works there knows how to whiteboard, and you can argue that it's correlated with skills used in development. They don't have time to pair program. They can afford to throw away people who could be good based on their arbitrary metrics.
Startups can make innovating around hiring a selling point to candidates. They can talk to candidates about what sort of process would best demonstrate their skills and be in their comfort zone. They can look at non traditional candidates based on github accounts or OS contributions. They want people who can deliver.
Google's hiring innovations are more likely to be small steps. By being agile, startups can get ahead of them.
As to what best practices are, behavioral interviews that ask people what they would do in a particular situation are correlated with job skills. So is actual work, so paying someone to work for you, or perhaps even volunteering to help them with something by pairing, may give you insight into them.
If one can read the language, and know what it does, the errors are pretty obvious. If the prospect doesn't know it, they're not able to talk to it, and the bullshit meter goes off pretty quick if they try faking it.
A non-technical person screening a technical person is generally not a good idea. It doesn't matter what prepackaged barrage of tests you put them through, or what saas product you make them sign up for. Most engineers know how to sound like they know what they're talking about, and how to craft their past experiences to sound relevant to your position. Only another engineer can tell if all that talk is meaningful or not.
This leaves many startups in a rough position: How does a CEO screen their tech co-founder? How do front-end developers screen a backend guy? And this is where your network comes in. Call in favors, ask around. Find someone who is employed doing the job you're hiring for (or ideally a more senior version of it), and ask them to do the screen for you. Don't give in to the temptation to screen them yourself (if you're not technical), there's really no point in it.
Have you done this during interviews with applicants? Have you received feedback from applicants?
The white board is a terrible way to get a sense of a persons ability to code. Does your design team ask candidates to come in and "design" on the whiteboard? Why would you pull an engineer that far out of context to see what they do.
I have seen interviewers bring in "code samples", sometimes with bugs in them. "Read this and tell me what you think it does" becomes a great question, or what is this for. Syntax highlighted code printed in color may speed this exercise along but isn't required.
References help, but really your calling someone they expect to give them a golden review. Linked in is your friend here, some "outreach" may get you a different perspective than the people they have listed.
B)Short of someone being lazy, or unwilling to learn, there is more than a bit of bullshit in "corporate culture". There have been several occasions in my career where I heard that my immediate boss didn't want to hire me as I would be a "bad culture fit", usually followed by a promotion. Culture is code for "status quo".
Lastly: Talk to your HR department about terminating bad employees after 90 days. No matter what you do, sometimes you just get it wrong, and getting that person out is better than dragging it out.
EDIT: I should have mentioned that rather than focus on "culture" you should be finding out if the person cares about your product.
Given a task without well-defined requirements would be a big red flag for me about the organizational structure of the company. I might even look for the door out of habit. I would definitely try to hammer out requirements verbally before writing any code and if there were resistance I would just thank you and leave. I'm interviewing you too, after all.
How you write 'login' depends entirely upon the context of what for. There's nothing 'simple' about it. Maybe it's an intranet site and you can authenticate via LDAP. Maybe you need to authenticate some legacy devices that only support specific character sets and field lengths. I guarantee that's not the answer you're expecting though. Your question doesn't give as much credit to breadth of experience as much as it does to "do you know how to roll your own secure auth?"/CRUD-fu. I'd rather hire somebody that knows (or thinks about) what pitfalls to look out for than how to implement something they can reference online.
That said, it's pretty much par for what I've encountered so far in this industry, but I'm interviewing looking for something _better_ not the same.
> Lastly: Talk to your HR department about terminating bad employees after 90 days.
Please don't wait 90 days to fire me if I'm a bad employee. You're basically guaranteeing that I don't get to work at other places I was far along the interview/offer process at when I was applying the last time. You're guaranteeing that I start my application pipeline from scratch and at disadvantage. If you feel buyer's remorse, make that decision immediately please. The best people always find a way to kick ass right away, even if it's in training.
Anytime I'm given non-trivial homework for a job interview, I decline because there are a dozen other companies that can determine my competence in a few hours of interviews.
I understand that hiring is risky for startups, but this approach seems excessive for what it is supposed to determine. It seems like you could get nearly all the same principal information about a person's talent by giving them an even more simple assignment, like writing a method to determine if two dates overlap.
A lot of what you're looking for is to see if a developer follows industry best-practices. It's just as easy to ask them, "what are some security/design considerations that need to be accounted for when creating a login page." You get the same information but in much less time.
I understand your time is valuable, and so is mine. I would like to see how you work, on your own time, in a low-pressure environment. The information I receive from that is easily worth $100. Plus, if we do proceed to further interviews, we have a fantastic non-theoretical project to discuss.
I think Gayle Laakman McDowell's comments on this subject were good:
http://www.gayle.com/blog/2013/09/18/companies-who-give-cand...
The problem here is that take homes allow companies to externalize the inefficiencies of the interview process - they may demand many hours of a candidate's time while dismissing that candidate in five minutes. The $100 gift card may make this a bit better, but it's still a bargain for the company (I'm certainly not surprised you consider the information easily worth $100).
Good things to check for:
how open minded are they? - Do they stubbornly stick with a certain way of doing things? - How readily will they apply someone else’s feedback? - Do they insist on doing things their way? - Do they think all code written by others is crap? - How much do they bristle at someone else’s code style vs working with it?
How well can they communicate with non-technical people? - How do they talk about their interactions with product managers/marketing/sales/customer service/etc? - Do they blame any issues on customers or colleagues being "idiots"?
Can they talk through a past problem they solved? Can they talk through the whole context of a problem they solved? - do they understand the customer problem they were solving and why it was important? - can they speak to multiple approaches that were considered and what their drawbacks were? - A great one is, did they go down a wrong path and learn something?
- Some other things to assess are - do they focus on the right problems to solve? Do they have a history of building systems that are more complicated than they need to be? Do they over-optimize areas where it’s not necessary or do they have a sense of where potential bottlenecks might lie; how to find them; when the right time is to worry about them?
If they can talk through a past problem they solved in detail, that’s a super great sign. The more detail they can get into and help you understand, the better. If they just start gushing technical details, they’re either nervous, or they had a very siloed role in developing the solution. I personally prefer engineers who can get invested in the context of a problem.
When it comes to coding in an interview I’ve found that very simple coding problems can surface all the info I need about their coding proficiency. - if the problem is simple, they’ll be able to just “stream” the code from their head on either a whiteboard or a machine. - experienced developers will even manage to talk through edge cases and workarounds - if they struggle with this challenge, then they’re not going to do better with a more complicated problem. - for experienced devs I’ll want to see that they’re proficient with the syntax of at least one language (if they don’t remember a specific method name, that’s ok - problems that can be solved by a google search shouldn’t be held against them)
- springing a complex coding question in front of them and expecting a perfect solution on the spot is a lot to ask for. “Real” solutions to complex problems will be debated and built upon by multiple people. If you go through this exercise, focus on how they tackle the discussion itself.
- I avoid brain teasers and puzzles. There’s plenty of good developers who can solve a real-world problem well but suck at solving technical brain teasers.
- In any interview, its important to take notice of how nervous the interviewee is. Some people may be able to handle interviews better than others. When you’re nitpicking their answers later on, keep this in mind. Some candidates might blank out on an otherwise simple problem; some might ramble on and seem disorganized. I’ve seen too many candidates get turned down because of a few specific details they mishandled due to nerves.
We do 3 things of which the first 2 are standard.
* CV screen * Phone screen, asking what, why, what is missing on CV * Interview -> starting by a presentation done by the candidate, then classic discussion/interview
The 3rd step is what is uncommon, we always ask a potential candidate to present a bit of code. Their own if possible, open source otherwise. The candidate selects the code and makes a small presentation powerpoint style or walk through.
We always learn a lot of this. What code was selected? What do they like/dislike about. Do they have opinions, and do they consider tradeoffs are they willing to read other peoples code?
I think that for us, having some kind of taste in code and be willing to work with and improve code written by others is a crucial part of our job. We can't afford rewrites, we are willing to do migrations.
For the interviewing team it is always nice to have such a small presentation because we always learn something new. It is never a waste of time! The candidates seem to enjoy it too because they have something concrete to talk about. In our very limited sample since doing this we have had less stuttering/sweating by potentials. White board coding just didn't work for us.
Then of course we have the 15 minute selling of the organisation/job to the candidate. No point in interviewing a great candidate and then lose them because you can't sell them on working for you. For that reason one of the developers will be waiting at reception for the candidate, and will walk them in, offer a coffee/thee/water show the conference room and tries to make the candidate as comfortable/relaxed as possible. Key is we try to show to the candidate that we appreciate their time.
For a candidate, you will not spend more than 3 hours total in the process. 30 minutes phone screen. 60 minutes interview with some extra time 60 minutes admin/contract details
Between each step there is a go no go decision and we normally make that the same day.
A no-go in the phone call might be 6 years of experience but never used CVS/Git or similar. Interview no-go tends to be voicing out loud that you are not willing to dig into a problem. e.g. DB perf issue, won't touch it DBA job.
Contract issues is when we can't afford you ;(
Of course we hire once every 18 months on average because we are a small team working on a very stable project.
Of course this is under Swiss law so there will be a probationary period but we have not used it in the last 10 years and I hope that continues. There is at will employment here but as in the US what is 'at will' can become a very expensive legal issue if not handled well. Also the negative morale on a small team on letting people go without a clear why is terrible.
Thing is we don't have 100's of candidates nor 10's of positions so what works for us might not work for you. So we tend to get 50 CV's, with 10 potentials, and 2 clear candidates in that pile.
Of yes, we always check at least one of the character references people put on their CV. But never someone in their current work environment (unless we know that will be OK, e.g. people leaving due to fixed term contracts at research institutes)
I wish that more companies would do this.
The only real problem occurs when the audience attending is not interested in the interview process. I have had it be the case where I felt like my entire presentation was dismissed. It takes a lot of time to write a good presentation and I think that it's worth it to invest that time as long as the audience is willing to participate.
But I also think that a team not interested in your presentation is rarely a team you want to work with.