4 ms·
I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate know
by LanceH 5y ago
I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't have a prepped list in front of me and I'm making some questions up on the fly, and the candidate should just ask for clarification. Also, that a lot of my questions are open ended, or have multiple right answers and any of them are acceptable.
It's not really a pattern of interview I expect most people can implement immediately, but it really gives a good idea of fluency. I just have to home in on what they do know. The easy questions get some momentum going and provide context for the follow ups. When they don't know an answer I'll tell them the answer. Sometimes this leads to them adding some depth beyond that answer as they know what's going on but haven't worked with it formally, or have worked with it in passing, or maybe know it by a different name.
- jrumbut 5y agoI've only ever done this style of interview and I've never hired someone who was downright awful. I also suspect it makes candidates more likely to accept because you can develop a bond and have a relatively enjoyable time in interviews like this. Several times I've had the interview process be so unpleasant I lost all interest in working for the company. I try to be considerate and withdraw so I don't waste everyone's time but once I did get an offer from a company like this.
- b3morales 5y agoVery much this. Leetcode is terrible, but the checklist of trivia suggested in the essay is equally terrible, because it's too easy for a genuinely good programmer to simply not have experience with topic X. Or, for more experienced candidates, to not have dealt with that topic for several years and not have the knowledge fresh.
- iAmAPencilYo 5y agoWould give some example questions for this? New manager here, trying to figure out hiring!
- LanceH 5y agoSure, Ruby on Rails. I literally start with something like: "You've just created a new Rails app and you change into that directory. What are some of the directories and files you find at that top level?" "What do you find in Gemfile? Gemfile.lock? What's the difference between the two?" Maybe some discussion of resolving dependencies/versions. There are numerous "right" answers to which files/directories are at the top level and I don't care which ones they get, but they'll get some and it gets the flow going. Most of them can be taken to greater depth. If I want to guide it away from views into models, at least they know the level of detail we're working at. Rails is a problem interview, too, because there is so much which is take it or leave it. There are Rails apps with no front end, and someone may have not worked with views for years, or the backend may be Api based and they haven't worked with models in the same way. I've worked on a project where 95% of the work was in the workers, and the user facing code was just nudging things between work states. So I use this to guide the conversations and draw out examples of their experiences when possible.