Coding Interviews are Broken

Very true for the majority of development jobs. What we're interviewed and examined on is rarely what we'll be doing day-to-day.

Most developers I know would rather index their knowledge than commit the entire thing to memory. Knowing more of what is possible is better than knowing specifically how to accomplish it. I'm one of these developers myself. I find the only things I do remember in detail are my early days coding fundamentals. Perhaps then it's only recently that I have been an indexer of information rather than to consume the entire thing in detail.

I don't know if interview methodologies will change though. We tend to follow what happens upstream rather than explore new ways ourselves.
 
Flojo said:
Click to expand...

Well, that’s mostly a load of nonsense.

Where he is right: Don’t ask advanced algorithms if the job is going to be front end design, or in general, completely unrelated to the day-to-day job.

Where he is wrong:
- Google does not ask you to regurgitate rote learned algorithms, and getting the answer “right” is not their primary concern.
- Algorithm performance is actually a good indicator for many jobs even if the day to day isn’t actually writing algorithms: it demonstrates clarity of thought, communication, ability to incorporate feedback, intelligence, performance and personality under pressure, rigor, process, humility, etc.
- “Fixing your last bug” as a question usually has issues relating to missing context, IP, generally isn’t well contained enough, and can hardly be used as a baseline since it changes, and it can be leaked too easily (there is a specific answer, whereas the algo question has many answers and an entire tree of iterative exploration).

Always good to know though, that someone with no work experience fully understands what one of the the most successful companies in the world is doing wrong...
 
cguy said:
Always good to know though, that someone with no work experience fully understands what one of the the most successful companies in the world are doing wrong...
Click to expand...
:laugh:
 
I ran numerous Outcome Based Interviews and trained and mentored junior developers. I've actually walked out of an interview that was basically a neat way for the senior architect to show his skill. And told him that. The HR rep didn't know where to look.
 
I'll be honest: I've interviewed quite a few people before and I don't think I've "cracked" it yet. I think I hate doing interviews.

Having a conversation with somebody I don't mind. It's easy enough to pick up an obvious dud and after a chat over a coffee or beer you'll have a better idea of the person you are hiring.

Technical skill questions I'm not too sure about. I recently had to dumb down an entry test for grads and some are still failing. It's high school stuff in my opinion so obviously I'm struggling with realistic expectations :p

Coffee and beer people: that's the way interviews should go. Probation will sort out the rest.
 
Last edited:
Hamster said:
I'll be honest: I've interviewed quite a few people before and I don't think I've "cracked" it yet. I think I hate doing interviews.

Having a conversation with somebody I don't mind. It's easy enough to pick up an obvious dud and after a chat over a coffee or beer you'll have a better idea of the person you are hiring.

Technical skill questions I'm not too sure about. I recently had to dumb down an entry test for grads and some are still failing. It's high school stuff in my opinion so obviously I'm struggling with realistic expectations :p

Coffee and beer people: that's the way interviews should go. Probation will sort out the rest.
Click to expand...

I agree. Beer/Coffee interviews always seem to work better at least in the environment I’m in now
 
Hamster said:
I'll be honest: I've interviewed quite a few people before and I don't think I've "cracked" it yet. I think I hate doing interviews.

Having a conversation with somebody I don't mind. It's easy enough to pick up an obvious dud and after a chat over a coffee or beer you'll have a better idea of the person you are hiring.

Technical skill questions I'm not too sure about. I recently had to dumb down an entry test for grads and some are still failing. It's high school stuff in my opinion so obviously I'm struggling with realistic expectations :p

Coffee and beer people: that's the way interviews should go. Probation will sort out the rest.
Click to expand...

Definitely agree on the probation for junior hires. We typically have internships and also have a rotation program - new hires work for a few months in different groups, and at the end of their rotation the group that liked them best will get them (or rarely, they will be let go).

We will always have an "informal" lunch with the candidate to get some sort of "away from the interview" sense of things. The problem with the beer/coffee approaches is that it does tend to introduce personal biases - where I work now, we really only use it to look for big red flags. People tend to want people who are more like them, and who they can communicate well with - and while the latter point is obviously important (with some caveats), the former one should not be. The caveat mentioned is that often "good communication" turns into "is more like me".

There are really so many other factors that going into finding good hires that "people" (i.e., bloggers, vloggers, etc.) never talk about. They myopically focus on "I was asked to code something on a white board", and then proceed to make grossly inadequate and inaccurate assumptions about what their interviewer was looking for, and why they didn't get hired.

Some of the seldom spoken about points I always consider (perhaps some of you may find this interesting/useful):
- On interviewers:
- (As a hiring manager) Make sure you know who the interviewers are, their biases, and their success rate at hiring good staff. Nobody ever seems to talk about this, but it is critical - if an interviewer has never stayed at a company for more than 4-5 years, they almost certainly have no basis to correct their own process (since they never get to see how the person they "never hire this person" succeeded, or how "X is great", proved to be the biggest hiring disaster in company history). Some interviewers are too strict, some are too lenient, some are easily fooled. Having a process (as some do) where interviewers ultimately give a number from 1-5 and then taking the average is just silly.
- Choose a variety of interviewers based on their interviewing strengths. Some are better at finding technically good people, some are better on fit, some interview junior people better, some interview senior people better, some interview researchers better, etc. In terms of the topic dimension, some interview maths people better, some interview engineers better, some interview physicists better, some interview computer scientists better, etc.

- On candidates:
- Level of interest is critical - find out what they're interested in. Most of my "whiteboard" questions will typically branch into a broader discussion of algorithms, the system/hardware they are writing for, compilers or languages, some specific application of the idea, or even a domain relevant discussion.
- Actually ask them to tell you something they found interesting. Ask them to teach you something.
- Push the candidates to a point where they can't answer the question (i.e., have a very thorough understanding of the problem - you have the advantage of advance notice). Not to see them "fail", but so that you can explain the next step, get them to confirm that they understood the problem, and then apply the new knowledge to a yet further step or another variation on the question). It's also good to see at this point, if they try learn/understand or try to evade the question.
- Find out of they're code lawyers or simple-is-beautiful types.
- Ask them for their software engineering philosophy/principles (especially if senior)
- Have a set of different questions - you don't want to test the same thing twice. No point in exploring linear algebra, if they don't know what a dot product is, etc.
- Find something in their resume to ask them about - make sure that they did the work, and see if you can get a sense of the level of detail and sophistication involved in the solution.
 
Hamster said:
I'll be honest: I've interviewed quite a few people before and I don't think I've "cracked" it yet. I think I hate doing interviews.

Having a conversation with somebody I don't mind. It's easy enough to pick up an obvious dud and after a chat over a coffee or beer you'll have a better idea of the person you are hiring.

Technical skill questions I'm not too sure about. I recently had to dumb down an entry test for grads and some are still failing. It's high school stuff in my opinion so obviously I'm struggling with realistic expectations :p

Coffee and beer people: that's the way interviews should go. Probation will sort out the rest.
Click to expand...
I'm curious. What position was this for and what questions did you ask them?
 
Arandompeer said:
I'm curious. What position was this for and what questions did you ask them?
Click to expand...

The coffee/beer interview? I've only ever been on the receiving end of those and always felt like it was "better".

My wife works for an investment bank who interviews like this, but they do 5 to 6 iterations with different 2-man teams until they are sure you are a culture fit.
 
Hamster said:
The coffee/beer interview? I've only ever been on the receiving end of those and always felt like it was "better".

My wife works for an investment bank who interviews like this, but they do 5 to 6 iterations with different 2-man teams until they are sure you are a culture fit.
Click to expand...
The technical questions for the grads
 
I'm going to study a diploma in IT but I have to do a maths bridging module this year. I did a 1 year boot camp sort of thing through college of ct but I felt it was a waste. The whole year the lecturers were frequently absent. It did give me a intro to c# programming which counts for something. I'm self-studying react and getting to node. Do you think I'm employable as a web developer? It's been 2 years out of high school and I want to be able to help out with the bills because of the current climate. If I was interviewing for a junior web developer job what would you ask me?
 
I'll add my 2c

Developers do not work under immediate and intense pressure ever (just about). Its just not part of the job.

They don't have to make under-pressure decisions about a patient dying on a table in front of them like doctors do. They don't , for the most part , stand up in front of audiences and give speeches. They're not giving orders under fire on a battleground.

Most good development work I've ever done is in a quiet , uninterrupted space where I don't have to show progress every few seconds. I don't have someone watching over me with an expectant look on their face. I don't have the pressure of coming up with solutions to problems RIGHT NOW or else something bad will happen (like failing an interview). The fight or flight response generated by an interview is NOT , I believe , good for development.

Development is careful , considered , and thought out. Things I don't have a solution at breakfast may well be something I have a solution for after lunch after it mulls over in my brain and I do something else. I don't want to see how my developers "think on their feet" because they won't ever be doing that.

In interviews , especially whiteboard interviews , you put the candidate under this pressure , and expect them to perform the same as they would if they weren't under pressure. And it won't happen.

If you ask questions which require heavy thinking to solve right in front of you, you're going to get much less out of them than you otherwise would and you won't be able to get a grip on their ability. Instead , what you might get is an understanding of their ability to think under pressure , which is useless in most real-world scenarios.

Discussions are better , and anything that requires their opinion or philosophy is better , because they'll have already established their viewpoints on something and won't have to think as much about applying them to the current environment.

Some years ago , I embarrassed myself by blanking out on a VERY simple recursion question which I stared at for 5 mins in a mild panic without being able to solve. After the interview was over , I relooked at it and cranked out the right code in 45 secs. I saved face a bit by solving some more complicated problems later on in the interview , but I'm pretty sure the interviewer thought I was a moron until that point.

I'm in favour of a time box test , where you give a candidate 2-3 questions to do with plenty of time to do them in. Then , you leave the room , give the candidate some breathing space and chance to focus on the problem without the eyeballing of the interviewer , and check in every so often. Hopefully this alleviates much of the pressure. Once done , you can then pull up your whiteboard and discuss and branch off.
 
We use TestDome during our interview process, and I think it's one of the best ways to determine if someone is good enough.
You can choose questions from a list, or write your own. It's a mix of theory, logical reasoning type stuff, and coding. You can set the amount of extra time you allow over and above the time limit.
The coding questions have unit tests that are run against the answers, so the candidate knows when it works or doesn't.
They do it at home or wherever and as such they are allowed to use their IDE of choice as well as google, so it's pretty much the environment they would be working in when on the job.
 
Usually a lurker but here's my 2c..

The software development industry has an ego problem and sometimes I feel that interviewers use it as a means to show off.

Look, companies need a reliable way to filter junk but I don't think asking someone (whether they have years of experience or not) to implement a red-black tree is a good way of doing that. Purely basing hires off Codility/LeetCode/Test Dome results as well is just lazy in my opinion and its usually someone in HR with zero tech knowledge who has a baseline and if you fail, you're immediately taken off the list. I've seen and heard of cases where a "genius" is hired who knows "Introduction to Algorithms" off by heart and subsequently destroys the morale of the team because he's incapable of working with others.

Interviewing requires the right balance and often companies get it wrong because their hiring process is broken or run by people who don't know what they're doing.
 
Arandompeer said:
I'm going to study a diploma in IT but I have to do a maths bridging module this year. I did a 1 year boot camp sort of thing through college of ct but I felt it was a waste. The whole year the lecturers were frequently absent. It did give me a intro to c# programming which counts for something. I'm self-studying react and getting to node. Do you think I'm employable as a web developer? It's been 2 years out of high school and I want to be able to help out with the bills because of the current climate. If I was interviewing for a junior web developer job what would you ask me?
Click to expand...

”Can I see your portfolio?”
 
Somewhat related to this, and the difficulty in assessing the real day to day performance/capability of candidates, we have done away with 3 month probation.

All our staff start on a 3 month fixed contract. If after those 3 months we are happy and they are happy, we move to a permanent employment contract.
I am very clear with my expectations up front what is required to be a developer here.
Candidates that don’t want to do this process don’t get offers.
Most of our hires move to perm after 3 months.
 
_kabal_ said:
Somewhat related to this, and the difficulty in assessing the real day to day performance/capability of candidates, we have done away with 3 month probation.

All our staff start on a 3 month fixed contract. If after those 3 months we are happy and they are happy, we move to a permanent employment contract.
I am very clear with my expectations up front what is required to be a developer here.
Candidates that don’t want to do this process don’t get offers.
Most of our hires move to perm after 3 months.
Click to expand...

Is this not similar to what a 3 month probation is for? or do you prefer not to "let go" the person during probation?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X