3 ms·
A) Give them a "take away" project... or bring them into the office to DO a project. Make it simple. Have them write "login". Don't be specific, tell them the e
by zer00eyz 11y ago
A) Give them a "take away" project... or bring them into the office to DO a project. Make it simple. Have them write "login". Don't be specific, tell them the exercise meant to be vague. Tell them that there are some things they may want to "hint at" or be a skeleton. If they are back end, you want just the api... front end just the UI (they can create static json for responses). Do they encrypt, did they leave hooks in for password reset, were they writing code that was going to be hard to I18N?
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.
- mywittyname 11y agoCurious, how often does this work for your company? 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.
- imsofuture 11y agoI've had really great experience hiring technical roles with 'homework'. Both product engineering + technical support. Each time, I've made sure that anyone completing the assignment is compensated with a $50 or $100 Amazon gift card (depending on the task). I don't think I've had anyone choose to not participate. I'm also happy to compensate people that make a solid effort and realize they are in over their head and gracefully bow out (specifically that's only happened when hiring borderline technical roles, like support -- no project is nightmarishly difficult). 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.
- geebee 11y agoI refused to do a take-home interview exam for the first time a couple of months ago. I don't think a $100 gift certificate would have made much of a difference. The opportunity was a decent one but I've just had very bad experiences with take-homes in the past (spent a lot of time, didn't hear back for a month, got a one-sentence rejection from a recruiter, never talked to a developer). I might consider doing it later in the process, when I have a stronger sense that the exam will be taken seriously and given proper consideration. I'm just not willing to put this kind of time into what may simply be "screening". I think Gayle Laakman McDowell's comments on this subject were good: http://www.gayle.com/blog/2013/09/18/companies-who-give-candidates-homework-assignments-knock-it-off 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).
- busterarm 11y ago> A) Make it simple. Have them write "login". Don't be specific, tell them the exercise meant to be vague. 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.
- s3b 10y agoYou really shouldn't fire someone after just 90 days. Maybe you should try moving the person into a different role/team before firing. Or at least give them some more time. 90 days is way too little time to pick up new skills and domain knowledge.