Title: How to hire good programmers
Speakers: Jennifer Bland
For more blog posts, see the DevNexus 2018 live blogging table of contents
Propose: Stop doing at home programming challenges
- We don’t write new projects from scratch all the time at work.
- Standing up an environment/project from scratch isn’t representative.
- Being given 90 minutes to do something doesn’t count setup time and then judging them on code
- [there’s also the problem that you don’t know if someone else did it and that you are expecting them to spend a lot of time on it]
- [I like http://collabedit.com/ for a short at home exercise so can do real time and watch]
Propose: Implement short coding exercises – 10 lines or less
- Assume 90 minute interview [I have shorter interviews]
- Goal of each section is to determine level of knowledge person has on that topic
- For each chunk, ask questions.
- Type 1: Test knowledge – traditional question. ex: what is difference between x and y. Start asking basic questions and ramp up.
- Type 2: Write code – give structure and write code to do simple task. Ex: write a selector. Then make question a step harder. And so forth. [these questions are easy. I guess the target is for an entry level or junior developer?]
- Scoring – set points for different levels of answer to each question and require minimum score to hire.
Propose: Casual tech discussions
- Propose spending 30 minutes on this section.
- At lunch at a conference, know people’s names, employer, where they live, what tech stack they use, etc.
- At an interview, can find opinion. Do they have an opinion. Are they passionate. [I do this]
- Allows candidate to be open, show understanding of topic, etc.
- Goal: learn how person will fit into company
- Also open ended questions like what online resources use.
- [I thought this was going to be about having lunch with the candidate vs asking questions that are opinions.]
- What steps are in interview process other than the 90 minute interview? Post job and view resumes. HR will talk to the person first. Then spend a day and interview 5-6 people in one day. Usually half are “nos.” Then 1-2 strongest candidates and maybe someone close. Bring back the top couple and bring them back to write more code. Maybe 12 exercises in an hour where there isn’t enough time to complete all of them with half more common. You can see which ones they picked to determine strengths. Can have an offer in a a week. [that sounds like it assumes everyone is free to come in on same day]
- Have you ever tested interview process on current team? No. But comparing candidates to each other. [I tested some of my questions on some teammates to ensure they aren’t too hard]
- Do you recommend having candidates pair with current employees? Haven’t tried.
- How batch candidates? Run job ads for two weeks. Have people come in over a week. It’s the second level where they come with a day or two.
- How mitigate against people who can’t write code? Asking them to write code. Testing how they problem solve too.
Note: she works for and R&D division of Black and Decker. I imagine that gives them overall stronger candidates.
I definitely agree with not giving a 90 minute project to do at home. I agree with the concept of having people write small code and do that. In less than 10 minutes I can tell if the person knows basic Java and then get on to the harder parts of the interview including more of soft skills and interests. (I suppose that is equivalent since it is on area?] I view the basic coding question as a screen. if they fail, the interview ends, but success doesn’t mean hire. And I agree on asking open ended/opinion questions. I don’t think anyone hires based on a 90 minute take home test though; I imagine they use that as a screen like i use my < 10 minute question on the phone/collabedit.