1–10 of 21 posts
Do code tests work well? Is there some saas product that can help test engineers? Some other method i've never heard of?
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.
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…
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.
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)
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…
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.
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…
Curious, 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 abo…
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.
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.
Take your candidate to a computer, ask the programmer what he/she is working on. Have the candidate sit down and continue the work for ten minutes. If it works, hire him/her.