Get them to ask a question on stackoverflow without it being closed or put on hold or marked as a duplicate.
While that is probably useful in its own way I doubt it would show whether someone can write decent code or not.
How not to hire a software engineer
81–90 of 239 posts
Re: How not to hire a software engineer
#82So these kinds of posts keep showing up.
How are interviews for not-software-engineers conducted? ie. how do you interview for a business analyst role, or a sales and marketing role? I have to assume that those roles suffer from the same sorts of issues a SE job does -- that someone can talk a good game but not be able to perform in the role.
Re: How not to hire a software engineer
#83Earlier quoted context omitted.
While a lot of what you say is true, that hiring pattern leaves you exposed to the bullshit artists. I always want to see some kind of code from someone for whom coding ability matters at all. Doesn’t need to be extensive, tricky, or even written live in front of us, but when the job is more than talking, I want to see more than just talking to evaluate.
I've seen the bullshit artists. When I was early on in interviewing people ( I've been coding just less than 40 years and hiring people ~20 years ), they did surprise me when it came to coding, though I never came close to hiring one. But it turns out, I just wasn't asking the right kinds of questions to pickup on bullshit, or I would let things slide without question where they seem to have glossed over things. But…
I've been responsible for hiring 10 or so engineers in my career and everyone of them turned out to be a good hire from the company's perspective. I was always able to smell the BS pretty quickly during interviews and it's always surprised me that this seems to be such a difficult thing for some interviewers to recognize. The BS is exposed when asking for more and more detail about prior work and projects. What was the last project you worked on? What was your role specifically? Were you responsible for selecting any portions of the tech stack? If so, how did you make those decisions? What were the determining factors? And on and on. As an interviewer, if I could not get a good read on one's abilities in this way I'd question my qualifications to be conducting the interview.
Re: How not to hire a software engineer
#84I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…
I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job, but then I take it really far beyond what I actually expect them to know, to the point where a lot of the details are unknown, and the details matter a lot in determining what kinds of solutions will be successful. Do they start BS'ing me? Do they confidently walk into really nasty parts of the problem without recognizing the pitfalls? Or do they tell me they're a little stuck? Do they ask which trade-offs to make? Do they ask if they can do some Googling for prior research on the problem? Do they explain what they would try and what pitfalls they would watch our for, or how they would validate their idea? Do they ask if they can make some simplifying assumptions for practical purposes? There's a lot of right and wrong answers but really I want to see their attitude and communication.
My first couple of hires before I did this were a brilliant computer scientist and a guy with a business degree and some coding background. I was surprised to see the guy with the business degree excel because we weren't doing many CS-hard problems, and an ability to manage time, talk about the problem, and navigate the project life cycle were far more important than classic algorithm knowledge. He needed to know how to code and debug, for sure, but like most software jobs, his soft skills were a force multiplier.
I'm pretty sure this has been done with me - I was given a problem and told to come up with something like an O(n log n) solution, and I honestly couldn't do it. I tried a few different approaches but I could think of really bad pathological cases for all of them. The interviewer gave me a few suggestions which I explored and I kept exploring them and then admitted I didn't see a way forward. I thought I was bombing and then he told me I did really well. I looked up the problem and found out he had done Ph.D. research in that area, and there was no general O(n log n) solution - only solutions that could do that in most practical cases.
Re: How not to hire a software engineer
#85Bring reference books and files with you to the interview.
When you get a technical question or problem, don't say anything, just open it up, point to it, and hand it back to the interviewer.
Re: How not to hire a software engineer
#86Earlier quoted context omitted.
The key is flexibility. As you say, there is little point in asking somebody who is going to be working with compilers the best way of doing something with React or Angular. A guy I used to work with would walk through the technical skills section on candidate's CV asking for knowledge level out of 10 and then ask questions accordingly but that is trickier to do on an online platform (at least as far as I'm aware)
I recently had a job interview where I was asked about skills on my resume. Except on every question the scale would change. For example. On a scale on 1 to 7 how do you rate your self on Linux Then, On a scale of 1 to 9 how do you rate your self on AWS. It was maddening and I could couldn't give an honest answer as I kept getting confused. That is one of the many reasons I declined a second interview with that compa…
Why change the scale? that would've confused me too
I guess the interviewer thought the scale change would make you think harder about your skill level ...
Re: How not to hire a software engineer
#87Now I really want to know how I save myself before the candle burns through the rope.
Re: How not to hire a software engineer
#88My Russian-speaking readers could read about it here.
DEAD LINK.
Re: How not to hire a software engineer
#89Earlier quoted context omitted.
I've seen the bullshit artists. When I was early on in interviewing people ( I've been coding just less than 40 years and hiring people ~20 years ), they did surprise me when it came to coding, though I never came close to hiring one. But it turns out, I just wasn't asking the right kinds of questions to pickup on bullshit, or I would let things slide without question where they seem to have glossed over things. But…
I've been responsible for hiring 10 or so engineers in my career and everyone of them turned out to be a good hire from the company's perspective. I was always able to smell the BS pretty quickly during interviews and it's always surprised me that this seems to be such a difficult thing for some interviewers to recognize. The BS is exposed when asking for more and more detail about prior work and projects. What was t…
The BS artists might be 1 in 250 to 1 in 1000 candidates, so give it time and you'll run into a skilled one sooner or later.
I have made several bad hires over 25 years and probably 100 direct hires and 500 total hires where I was on the panel. It happens. Most would have been difficult to ferret out in an interview, because an interview is an inherently spotty/lossy process.
The worst hire I ever made had, in retrospect, been given the (business case) question ahead of time and had pre-written notes in his notepad. He theatrically took careful notes while I was stating the business case problem, asked if it was OK if he did some computations and composed his thoughts in his notebook before presenting the case at the whiteboard. He did just that and stood to deliver literally the most polished presentation on the case that I have ever experienced. 5/5 definitely hire.
Shows up to the job and couldn't get water out of a boot if told the instructions were printed on the bottom. Flames out in a few months and moves on to his next gig. It was only after playing things back that I realized the only way he could have pulled that off was to have pre-seeded his notebook with the solution to the business case.
Re: How not to hire a software engineer
#90I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…
I wish everyone thought that way but they don't. In today's rapid paced world if you don't know Rails (not even Ruby) but Rails, for example, and we're using it - then you ain't in... and here write this 8 hour code test so we can subjectively judge it because grading code tests to see if you don't put logic in your controllers make our egos hum.
Maybe nitpicking certain micro-design choices isn't always helpful, and maybe it doesn't need to be a task requiring 8 hours, but I believe a "work sample" of actual code is the only technique that has any research backing it as a good way to evaluate potential hires.