In grappling (Brazilian jiu-jitsu), it is very apparent from one sparring round with a person to get a sense for what they know and get a general idea for their skill/belt level. The exact belt is determined by that person's coach by measuring their skill against their personal potential.
An analogy to software would be to pair program with a person. You both get a feel for each other's strengths and weaknesses while working on a particular problem. I feel that coding interviews try to replicate this, but fall short given time constraints.
The same way you size up anyone else's aptitude, really: by making them feel comfortable, speaking with them honestly, trying to quickly figure out what excites them and asking lots of follow-up questions. When someone is eager and bright, and they've been made to feel relaxed, it's usually obvious.
Conducting a great interview is hard. It requires some mentorship and a ton of practice. Not everyone's cut out for it. But when a technical interview is led by an experienced technical person who knows how to interview well, the candidate knows they're being assessed fairly, and you get far more valuable information than you would from these coding challenges.
The best coding interview I ever did was a pair programming exercise using a laptop with one of my prospective co-workers. We worked on a problem for 45 minutes, we conversed naturally about the problem, and there was very little stress.
At the end both of us came away with an understand of the others skills and how we worked as part of team.
I've since used a similar exercise when interviewing people as I've found I get a much better sense of what the candidate can do than placing them in from of a whiteboard.
I'm interested in hearing more. I'm currently in the process of improving my interview approaches — currently a live coding session with a real-world problem involving an internal dataset.
Interviewing is assessing how a person would perform, not an actual day to day collaboration. There is a gap. You do not talk like you would to a colleague. You have a limited time and it's more one-sided to even the playing field. It's worth preparing for to overcome the gap.
It's like a dance. Your are supposed to lead deriving the solution, interviewer is supposed to follow closely and judge your performance.
If you expect to ace an interview just like that then you also need to be lucky not accidentally getting asked to stuff, which you always need to Google an answer to, basic algorithms and patterns, which you usually kind of know but could slow you down during the precious 40 minutes you have to show off your skills.
And lastly, people do prepare for these. If you do not do that, you might simply make a slightly worse impression than someone who did.
That being said, I mostly did not prepare for the coding interviews. I focused on the design and behavioral interviews.
I’ve never tried this exactly, but I wonder how “live coding” interviews might go if the interviewer was the one doing the typing/coding and the candidate’s role was to verbalize what the interviewer was doing (and why) - and also guide them to some degree.
It’d be more akin to pair-programming, which some of the interviews I’ve conducted have evolved into, depending on the strength of the candidates.
Would that capture enough to get a sense whether this person gets the gist of the code being written such that they could replicate the same output in a less contrived scenario?
As the interviewer, I approach candidates with an open-ended friendly gesture. I tell them flat out I want to assess their coding ability, but on grounds they are comfortable and familiar with.
Before the interview, I tell them to bring whatever materials they want to the interview, whether it is virtual or not. Books, notes, videos, whatever, I don’t care. The materials are to support them showing off to me, in their favorite language, with their favorite ecosystem (editor, IDE, compiler, version control, etc.), solving a typical task they address that takes up about half a page (or more) of code on a standard US letter or international A4 sheet in 12-point Courier New, 1.5 inch or 3.8 cm borders, no lines that are entirely a comment (when counting just code).
The hyper-specific layout specifications were emerged by all sorts of crazy responses I got in the early years when I started this approach.
Could be a standalone program, a function, a code fragment, a library, really anything. I’m pretty comfortable in a very wide range of coding environments, and always happy to learn new ones, so I’ve been comfortable navigating the responses I get.
I even tell people I don’t care whether it is their own code or something they literally copy and paste off the Internet. But they need to be ready to talk about it, and take it in different directions.
I tell them I’m going to ask them to teach me about the code, and ask questions to clarify for myself along the way as if I’m going to take it over and maintain it myself.
Through this approach I’m looking for the ability to communicate about code. Being able to code is table stakes and this approach quickly flushes out who cannot code at a specific level required for the position. But I work exclusively in settings where there are teams of coders, and even “lone wolf” coders must be effective at conveying what they’ve built to others in case they win the Powerball/Lotto.
I can work with a variety of levels within a certain band of coding ability. I can work with someone who isn’t familiar with my clients’ specific toolchains. I can work with poor documentation, commenting, and writing skills. What I’ve been unable to solve for so far though, is someone not only utterly incapable of communicating what they’ve coded, but completely indifferent to improving.
(I think I made a similar comment to a similar submission a while back)
I suggest this type of interview:
Both the interviewer and interviewee get a problem to solve and they work together to solve it. It should be new to both of them, so the interviewer can better assess its level of difficulty without the bias of knowing the solution beforehand. This will enable natural empathy for the candidate.
It also shows how interaction would look like in every day kind of work. You can learn a lot about another person's skill by doing pair programming.
Logistically speaking, you can whiteboard the design/code, or sit around a big screen for the coding part, with whatever tools/IDE the candidate likes to use (s/he should be writing most of the code, even if the solution/design was a common process).
How do you compensate for the fact that you don't know the codebase that well? I feel like a lot of the value of interviews is that you see how a candidate thinks through a problem that you have also thought deeply about, which gives more fruitful discussions.
Interviews are prediction machine that answer the question “will the candidate be successful (technical, design, soft skills, team integration…) in the role over time. The prediction is made with an extremely small sample, a few hours at most compared to months or year of training and employment.
Considering that, of course the interview won’t be a slice of real work - there just isn’t enough time. We try to compress the software development experience of months to an hour - so it gets lossy. That’s why, in the interview, we gloss over details that we won’t in real life.
Which is where ChatGPT’s answer really excel. Sure, it won’t really be able to design and code the system. But it can mimic knowing how to do it for the purpose of the test quite well.
Are you talking about a job interview situation, or just watching someone go about their daily work?
Are you an experienced programmer who can understand what the person you're watching is doing, or are you non-technical? If you're non-technical, I don't think you could figure out very much about someone's skills just by watching them program.
I am an instructor at a coding bootcamp and I conduct technical interviews of our applicants pretty regularly. I have recently been very concerned with tackling the idea the author first addresses: not hiring (or in my case admitting) for what people already know. Our program only has 12 weeks with the students and so what I am most concerned with is the applicant's ability to pick up new concepts quickly.
In the past we have tested students on the little bit of Ruby or Javascript they had studied to prepare for the interview. I am of the belief that that method has helped determine who knows a little bit of Ruby but not who can ramp up on complicated topics quickly during the program. My attempts to address this have led me to doing a 15 minute lesson on something totally new to the applicant and then having them answer questions based off of that lesson. So far I've found it to be useful.
Technical interviews are hard. It's easy to suck at them.
Even though interviews between companies are wildly different, there is a correlation between doing more and getting good at them.
There’s a lot of performance and interview skills involved in the talking part of an interview. It’s not just the hacker code part that benefits from training
I think evaluating the skills is not difficult within the timespan of an interview, if done right.
Let's sit down at a specific problem I am working on. Let me tell you what I'm doing with the tools that I have. Your past work was in some way similar, and you can relate to what I'm doing in some way. Either you can jump right in and take over the keyboard, or you can tell me how you solved a similar problem with your tools and frameworks. I can show you how it's done with my setup, and teach you a few things in the process - which you will easily pick up as you have related experience. You got either questions that are exciting, maybe challenging me how I am doing it, or maybe teach me just a keyboard shortcut I didn't know, proving the time and effort you spent on this. We are both excited to learn a lot in a short amount of time and I know I want you to work with us...
That assumes the interview accurately measures something useful. The more I read about this area the more I think a 1-2h pre-interview practical coding assignment, then a 1 on 1 discussion during the interview is better. You then get to understand how they think, how they design solutions, and some sense of how they interact. In other words, how they'd do the job.
Ask for code. TALK about algorithms at a high level. I have an aptitude for reading people, but my day two impressions of coding with a new person tend to lead to valid assumptions about them months later.
An analogy to software would be to pair program with a person. You both get a feel for each other's strengths and weaknesses while working on a particular problem. I feel that coding interviews try to replicate this, but fall short given time constraints.
reply