I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
> How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
Unless the job is responding to problems and being watched while you work, the argument here is that you're not actually assessing anything that's very useful.
Most engineers/developers, for example, spend a lot of time thinking about a problem or trying out their ideas (many of which quickly get thrown out). If you do this in most programming interviews, you're going to fail them.
The problem as I see it is the difficulty in posing a problem that's interview-sized and still relevant to their actual workflow. I don't know how much whiteboard algorithm time you spend during your day to day, but for me it's vanishingly small.
What is relevant in my day to day is dumb shit like "What do you name things?" "How do you control access to classes internals?" "How do you construct an API?" "How do you communicate your designs to people living outside your head?"
Virtually none of which you can get done on a whiteboard with a problem set that you can define in five minutes or so.
A good start would be talking with them like they were professionals: asking for advice, listening to their answers, debating their answers if you disagree so they have a chance to respond and possibly change your mind. Or, you could just have them jump through hoops and do tricks like trained monkeys.
It's not a realistic assessment of skills though. You don't write code on a whiteboard for work, you do it in an environment you have setup to let you work most efficiently. You have the option to look up things you can't quite remember, do some research to see if there is anything you missed, take a quick break to clear your head, etc...
Plus, too often it devolves into a game of algorithm trivia with the interviewer. Gotta prove how smart* you are.
"So what have you been working on?" "Oh I was the lead engineer on our new backend system. Built it on top of X, built a custom foobar because we needed to scale Y functionality blah blah blah" "Oh cool, cool. We actually are looking at building something similar. Well anyway enough of this obviously useless information exchange, here's a question about graph searches".
*smart may be substituted for grinding out leetcode questions for weeks beforehand, at the interviewees discretion.
While I fully agree with the author that coding interview questions are not great, I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve.
I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the candidate and the company.
Maybe company's are "lazy" for sticking with archaic methods that are not always fair to the candidate, but when the author claims that companies are simply "too lazy to figure out how to interview people effectively", I feel he is trivializing a very difficult problem to solve.
I think there's a business opportunity here. Imagine something like ETS's system for administering the GRE: Come into a location in your city at a particular date/time, sit down at a computer pre-loaded with various editors / IDEs for common languages, and run through an 4-hour coding exercise specified by the hiring organization, and, at the end, your code is provided to the hiring organization for examination. Internet access is freely permitted but it is fully logged and reviewable by the hiring organization. A proctor is present to keep an eye out for cheating and to resolve any technical difficulties. This reduces the pressure to something not much higher than working in a regular office.
Bear in mind that this is for the coding part, which people seem to have the most difficulty doing on a whiteboard under pressure. There would still need to be a conventional behavioral interview as well.
Triplebyte seems to angled toward doing pre-screening; the hiring organization still does a full interview loop afterward. What I proposed would be more along the line of handling the mechanics of administering a coding interview for a hiring organization while allowing their hiring manager & HR full control and also making the candidate as unstressed as reasonably possible.
Honestly this sounds terrible. I would never take a proctored test for an interview. Might as well just send the company a copy of your grades from some computer tech class in school, because that is basically what you're proposing.
I will happily spend a few hours preparing an open source project and presenting what I've created as part of a final interview.
Relying on testing alone is going to get you good test takers. A great team needs a mix of of skills- technical experts, business minded folks, and motivated leaders. I don't have the magic answer but I'm sure that proctored testing is the wrong answer.
> I would never take a proctored test for an interview. ... Relying on testing alone is going to get you good test takers.
A conventional interview is basically a set of tests already. A conventional whiteboard coding interview segment is a proctored test, with the interviewer serving double duty as the proctor.
This proposal aims to reduce the stress by having an impartial proctor instead of an interviewer looking over one's shoulder as you code.
Is it possible to lower the cost of failure? Quarantine new hires and let them go quickly if they don't work out. Have a bunch of "ready-made" tasks ready for them. For senior hires, talk for a bunch of hours.
> I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve.
Only because the formulation of the problem is wrong in a manner that precludes the solution; you can't fix the programming interview because an interview is not, no matter what you do to it, a good way to assess practical programming skill. It might be a useful way to assess other skills that are relevant to the work of someone being hired as for a job that involves programming, but not the programming part.
My experience is that knowing who's a good programmer is like knowing what's art: you know one when you see one. That's why I don't get the coding interview.
Just an everyday conversation with a coder will give you a better idea whether he's any good or not, and it will do this without stressing him out or impugning his integrity (which is exactly what you're doing when you ask someone a bunch of trick questions on a subject they've already claimed expert knowledge on in their resume).
There's always a set of programmers who sound erudite because they are erudite. It's typically not that easy to fake being erudite, so it naturally follows that programmers who sound and behave like they're competent are usually competent.
A simple strategy would to always select from that pool. It might even be a relatively optimal strategy too if you account the time and effort to interview people.
However, my experience has show me that assumption has been wrong on a number of occasions. People have both surprised me and disappointed me. I wish I could say it's been the rare case, but it's happened a lot more than I would have liked.
I've considered I'm not the best judge of people, but I can't help but notice a lot of my colleagues aren't the best either. Some are and I envy their talents to notice some set of heuristics I haven't picked up yet.
It's not about being erudite, or knowing lots of things.
What you pick up on when you're having a conversation with another programmer about writing code is whether or not they give a crap about their craft and doing it well, and what kinds of things they think about and worry about in their code and the code they work with.
The really good programmers are the ones who want to make the world of software a better place, without concern for ego or who wrote what.
Whenever I've had a problem with a hire, it has never been a competence problem. If I gave those people code problems, they would have knocked them out of the park, I still would have hired them, and I still would have had the problem.
I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any certainty if I'm successful or not.
About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that type of pressure. She was very experienced and my discussions with her really seemed to indicate she learns quickly and would probably be a decent fit. The only reason we didn't hire her was I found another woman who was a better fit.
Since then, I've tried a lot of things. Lately, I've been putting the emphasis that we allocate some time to pair program. We simply get in a room to make something together and we may take turns with the keyboard. I actually go out of my way to tell people this is not a coding test, but rather a play date. I emphasize I don't expect them to know everything and I even half-joke I deduct points for not asking questions.
Some people have told me they really like this approach, the others haven't commented one way or the other, but I'm still skeptical about my method. Most seem to relax well enough, but there are always people who may be more than competent who simply don't manage to relax in a realtime environment.
Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time.
I'd love to know what HN readers think. Do your interview processes penalize tortoises or other people who don't simply fit a mold? Do you have a good system that takes into account the diversity of people's talents?
I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever.
This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with.
If you're concerned they'll cheat and have their friends do it for them - you needn't be. As long as the interviewer is knowledgeable enough to ask good questions (e.g. "Why did you use that auth strategy?" or "What performance problems do you anticipate?") you'll quickly be able to tell if they fully understand the problem space. That's a much more useful test than asking someone to implement a red/black tree.
Going to an interview is already a time-consuming affair that requires taking time off from your current job, but at least you know the interviewer is somewhat serious because they are willing to spend their own time interviewing you.
With a "homework assignment" it is possible for the interviewer to throw a much wider net, and that is why as an job hunter I would not waste my time with it.
What about letting people provide code they've already written? It might take more effort to come up with good questions, but the answers should be more interesting.
I'm going to go against the grain and say homework assignments work for me. If I know that I would perform better at them instead of a whiteboard code test then I would take the time. But I think you can see the bias here, the people that are interested in taking a homework assignment over in person interviews are ones that prefer them.
I would like to add the reason I continue to use my current method is that it creates so many diverse points of data (using that term loosely) because so much happens in the hour we're together.
There is something incredibly revealing when it comes to collaboration, especially if the objective is slightly open-ended. People have very different styles of approaching ideas and a lot of the time, it's revealed when the objective hasn't been overconstrained. Simply asking people, "What would you do here?" and "What's your approach?" in a non-judgemental way that actually conveys you're interested in their ideas goes a long way. Also, phrasing your questions so they come off as genuinely curious rather than pointed goes a long way.
Most of all, letting people take you somewhere you didn't expect to go is an interesting way to learn about someone. When your agenda is open enough to allow a person to solve a problem with tools or ideas they're comfortable with, it can be eye opening.
However, if I see them doing something where I feel like I improve it, I offer to show them a trick and this gives me a tiny peek to see how they learn. Do they get it right away? Do they ask good questions?
I think all those things are important aspects of collaboration. You need to have a genuine interest in each other's ideas and receptive to teaching each other new ideas and making each other's work better by adding your insight as well as absorbing their insight.
That's why I'm hesitant to simply interview and ask questions. I actually enjoy coding with other people and it's hard for me to see if I'm going to like working with this person if all I'm doing throwing questions at them so they can wax poetic about their last job, thoughts on tech/methods, etc.
Again, I'm still not convinced my method is optimal.
FWIW, as someone dealing with pretty severe (social) anxiety, I'd go for your approach over any other if I had my choice in interview method!
Homework would be my second-favorite approach, but the reason why I prefer yours is that it would also give me a lot of insight in who I'd be working for/with.
> Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time.
As someone who prefers to contemplate a question carefully before answering and stutters considerably when put on the spot, kudos for you for considering taking a more inclusive and compassionate approach.
Coding interviews make sense for great companies like FB and Google. Such companies receive probably tens of thousands of applications every week, and all the candidates who can get an onsite interview have impressive resumes. How do they pick the best and brightest from the best and brightest? Code interview at least sets a higher bar for minimum requirements for two types of candidates:
- If a candidate is a genius, the candidate can solve those interview questions easily
- If a candidate is not a genius but is truly passionate about CS, the candidate should have read or practiced enough to solve the interview questions too.
Either way, the candidates who pass coding interviews meet the minimum hiring bar.
And don't forget the historical context when Microsoft popularized brain teasers and algorithmic puzzles in its haydays. In the 80s and 90s, there were few interview prep books. There was no leetcode or any other pre site. Those so called teasers are cleverly disguised math puzzles. Remember the questions about pirates dividing up gold coins? Classic math problem. Remember the one that asks how many unfaithful husbands there are in an island? Putnam question solvable by mathematical induction. Similarly, the so-called algorithmic puzzles came from classic CS books or from real projects. Those who can solve the puzzles are either super smart or super geeky. Either way, they were likely to be great hires for Microsoft.
I think the answer to this problem is take-home coding tests. They do the best job of simulating actual working conditions and minimising associated stress and anxiety. I've had this confirmed by multiple candidates I've used this approach with.
I'm actually launching a product to streamline the process if anyone is interested.
Hi I just looked at your site. I found this very odd.
RESPECT YOUR CANDIDATES
Strictly timeboxed tasks ensure candidates don't feel pressured to devote silly amounts of time to interview coding exercises.
The biggest issue I've found as an dev looking for work is that, employers often want a full functioning, production grade, api, with tests, and some integration tests. These requirements cause the issues, and timeboxing would surely compound them?
I guess there's a learning curve for the potential employer, but as an employee I wouldn't want to potentially be a guinea pig while they get their act together when understanding how long a task should actually take.
The strictness of the time limit works both ways. They'll be comparing you against other candidates who had the same amount of time. If nobody got a complete solution done, nobody is advantaged or disadvantaged.
The employer onboarding is designed to guide them towards the best practices I've discovered. 40 minute time limit and a clear expectation set in the challenge instructions that a "perfect" response is not possible in the time provided, so just do what you can and submit what you've got.
That avoids clustering responses near the top of the curve.
It also provides talking points for the interview. "So, given unlimited time and budget, where would you go from here to make this code production ready? If you needed to scale it to an OOM more throughout, where would you start optimising?" Etc.
Me: Are you comfortable solving a small programming problem?
If the answer is yes: Here's a simple algorithmic problem you can solve in under 20-30 LOC. You can choose any language you wish, including psedocode. You can choose to write on paper or on this PC.
If the candidate seems nervous, I leave the room for a few minutes.
It can't find you the best developers. But it certainly helps weed out candidates who talk up a storm but can't actually code.
All depends on the nature of the work you're hiring for. The weakness I see with that approach is that I can't think of many workplaces where the main component of the job is solving 20-30 LOC algorithms.
The correct answer to most sorting algo challenges in the real world is some variation on "use Array.sort"
I'm more interested in how people interpret requirements, how they resource knowledge, how they architect their code, how they test it, etc.
My recently retired pet challenge was to fetch and amalgamate responses from three different, unreliable, URLs and then return them in a single JSON document. For the web developers I was hiring it worked well.
> The big companies that use them have started to finally admit this
I didn't get as much whiteboard coding as I thought in my recent interview with a big company. Last 2 actually.
But of course facebook and google was still all coding. Google is still obsessed with their overwrought process, and still try to sell a poor false positive rate as a feature.
I still haven't really heard a better idea. Some of them sound incredibly hostile to the applicant (e.g. lets try it for X days). Do this work, bring it in and discuss is a pretty decent idea.
I'd like to see more of "here's what we want, lets code it on this computer however you want.". Lets talk about while we work.
I don't know how else one can prove that they can code without having some kind of a coding exercise during the interview. It doesn't have to be trivia-without-the-beer coding hour; it could be pair programming, a take-home, etc. But not coding at all? Doesn't make sense.
I think blanket statements aren't going to work in a diverse field such as software development. Certain jobs require strict skills and those skills need to be measured by all potential employees.
On my team we aren't doing anything particularly crazy beyond a large crud application. We feel confident enough in our development process that we can hire interns and make them productive. We are more interested in knowing they want to learn and are able to learn our application. Culture fitnisnlore important to us.
As a result, having a conversation with the applicants is much more valuable than a coding challenge. It works for us.
46 comments
[ 3.1 ms ] story [ 99.7 ms ] threadUnless the job is responding to problems and being watched while you work, the argument here is that you're not actually assessing anything that's very useful.
Most engineers/developers, for example, spend a lot of time thinking about a problem or trying out their ideas (many of which quickly get thrown out). If you do this in most programming interviews, you're going to fail them.
What is relevant in my day to day is dumb shit like "What do you name things?" "How do you control access to classes internals?" "How do you construct an API?" "How do you communicate your designs to people living outside your head?"
Virtually none of which you can get done on a whiteboard with a problem set that you can define in five minutes or so.
Depends on what you're looking for.
Plus, too often it devolves into a game of algorithm trivia with the interviewer. Gotta prove how smart* you are.
"So what have you been working on?" "Oh I was the lead engineer on our new backend system. Built it on top of X, built a custom foobar because we needed to scale Y functionality blah blah blah" "Oh cool, cool. We actually are looking at building something similar. Well anyway enough of this obviously useless information exchange, here's a question about graph searches".
*smart may be substituted for grinding out leetcode questions for weeks beforehand, at the interviewees discretion.
I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the candidate and the company.
Maybe company's are "lazy" for sticking with archaic methods that are not always fair to the candidate, but when the author claims that companies are simply "too lazy to figure out how to interview people effectively", I feel he is trivializing a very difficult problem to solve.
[1]: http://davemart.in/remote-hiring/
Bear in mind that this is for the coding part, which people seem to have the most difficulty doing on a whiteboard under pressure. There would still need to be a conventional behavioral interview as well.
Somebody want to run the idea past YC? ;)
I will happily spend a few hours preparing an open source project and presenting what I've created as part of a final interview.
Relying on testing alone is going to get you good test takers. A great team needs a mix of of skills- technical experts, business minded folks, and motivated leaders. I don't have the magic answer but I'm sure that proctored testing is the wrong answer.
A conventional interview is basically a set of tests already. A conventional whiteboard coding interview segment is a proctored test, with the interviewer serving double duty as the proctor.
This proposal aims to reduce the stress by having an impartial proctor instead of an interviewer looking over one's shoulder as you code.
Only because the formulation of the problem is wrong in a manner that precludes the solution; you can't fix the programming interview because an interview is not, no matter what you do to it, a good way to assess practical programming skill. It might be a useful way to assess other skills that are relevant to the work of someone being hired as for a job that involves programming, but not the programming part.
Just an everyday conversation with a coder will give you a better idea whether he's any good or not, and it will do this without stressing him out or impugning his integrity (which is exactly what you're doing when you ask someone a bunch of trick questions on a subject they've already claimed expert knowledge on in their resume).
There's always a set of programmers who sound erudite because they are erudite. It's typically not that easy to fake being erudite, so it naturally follows that programmers who sound and behave like they're competent are usually competent.
A simple strategy would to always select from that pool. It might even be a relatively optimal strategy too if you account the time and effort to interview people.
However, my experience has show me that assumption has been wrong on a number of occasions. People have both surprised me and disappointed me. I wish I could say it's been the rare case, but it's happened a lot more than I would have liked.
I've considered I'm not the best judge of people, but I can't help but notice a lot of my colleagues aren't the best either. Some are and I envy their talents to notice some set of heuristics I haven't picked up yet.
What you pick up on when you're having a conversation with another programmer about writing code is whether or not they give a crap about their craft and doing it well, and what kinds of things they think about and worry about in their code and the code they work with.
The really good programmers are the ones who want to make the world of software a better place, without concern for ego or who wrote what.
A simple conversation with someone is far more telling then having someone fixate on a single problem for 40 minutes
About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that type of pressure. She was very experienced and my discussions with her really seemed to indicate she learns quickly and would probably be a decent fit. The only reason we didn't hire her was I found another woman who was a better fit.
Since then, I've tried a lot of things. Lately, I've been putting the emphasis that we allocate some time to pair program. We simply get in a room to make something together and we may take turns with the keyboard. I actually go out of my way to tell people this is not a coding test, but rather a play date. I emphasize I don't expect them to know everything and I even half-joke I deduct points for not asking questions.
Some people have told me they really like this approach, the others haven't commented one way or the other, but I'm still skeptical about my method. Most seem to relax well enough, but there are always people who may be more than competent who simply don't manage to relax in a realtime environment.
Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time.
I'd love to know what HN readers think. Do your interview processes penalize tortoises or other people who don't simply fit a mold? Do you have a good system that takes into account the diversity of people's talents?
This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with.
If you're concerned they'll cheat and have their friends do it for them - you needn't be. As long as the interviewer is knowledgeable enough to ask good questions (e.g. "Why did you use that auth strategy?" or "What performance problems do you anticipate?") you'll quickly be able to tell if they fully understand the problem space. That's a much more useful test than asking someone to implement a red/black tree.
With a "homework assignment" it is possible for the interviewer to throw a much wider net, and that is why as an job hunter I would not waste my time with it.
There is something incredibly revealing when it comes to collaboration, especially if the objective is slightly open-ended. People have very different styles of approaching ideas and a lot of the time, it's revealed when the objective hasn't been overconstrained. Simply asking people, "What would you do here?" and "What's your approach?" in a non-judgemental way that actually conveys you're interested in their ideas goes a long way. Also, phrasing your questions so they come off as genuinely curious rather than pointed goes a long way.
Most of all, letting people take you somewhere you didn't expect to go is an interesting way to learn about someone. When your agenda is open enough to allow a person to solve a problem with tools or ideas they're comfortable with, it can be eye opening.
However, if I see them doing something where I feel like I improve it, I offer to show them a trick and this gives me a tiny peek to see how they learn. Do they get it right away? Do they ask good questions?
I think all those things are important aspects of collaboration. You need to have a genuine interest in each other's ideas and receptive to teaching each other new ideas and making each other's work better by adding your insight as well as absorbing their insight.
That's why I'm hesitant to simply interview and ask questions. I actually enjoy coding with other people and it's hard for me to see if I'm going to like working with this person if all I'm doing throwing questions at them so they can wax poetic about their last job, thoughts on tech/methods, etc.
Again, I'm still not convinced my method is optimal.
Homework would be my second-favorite approach, but the reason why I prefer yours is that it would also give me a lot of insight in who I'd be working for/with.
As someone who prefers to contemplate a question carefully before answering and stutters considerably when put on the spot, kudos for you for considering taking a more inclusive and compassionate approach.
Either way, the candidates who pass coding interviews meet the minimum hiring bar.
And don't forget the historical context when Microsoft popularized brain teasers and algorithmic puzzles in its haydays. In the 80s and 90s, there were few interview prep books. There was no leetcode or any other pre site. Those so called teasers are cleverly disguised math puzzles. Remember the questions about pirates dividing up gold coins? Classic math problem. Remember the one that asks how many unfaithful husbands there are in an island? Putnam question solvable by mathematical induction. Similarly, the so-called algorithmic puzzles came from classic CS books or from real projects. Those who can solve the puzzles are either super smart or super geeky. Either way, they were likely to be great hires for Microsoft.
I'm actually launching a product to streamline the process if anyone is interested.
https://takehome.io
Before I spend time as a candidate I want to make sure the interviewer is seriously considering me for the position.
Oooohhhh or pay-what-you-want where the candidate sees what you paid. Use it as a signal to the candidate of how much you're interested in them.
Personally I only ever assign a code challenge after an initial general interview. Then code challenge which gets taken into a technical interview.
RESPECT YOUR CANDIDATES Strictly timeboxed tasks ensure candidates don't feel pressured to devote silly amounts of time to interview coding exercises.
The biggest issue I've found as an dev looking for work is that, employers often want a full functioning, production grade, api, with tests, and some integration tests. These requirements cause the issues, and timeboxing would surely compound them?
I guess there's a learning curve for the potential employer, but as an employee I wouldn't want to potentially be a guinea pig while they get their act together when understanding how long a task should actually take.
The employer onboarding is designed to guide them towards the best practices I've discovered. 40 minute time limit and a clear expectation set in the challenge instructions that a "perfect" response is not possible in the time provided, so just do what you can and submit what you've got.
That avoids clustering responses near the top of the curve.
It also provides talking points for the interview. "So, given unlimited time and budget, where would you go from here to make this code production ready? If you needed to scale it to an OOM more throughout, where would you start optimising?" Etc.
Me: Are you comfortable solving a small programming problem?
If the answer is yes: Here's a simple algorithmic problem you can solve in under 20-30 LOC. You can choose any language you wish, including psedocode. You can choose to write on paper or on this PC.
If the candidate seems nervous, I leave the room for a few minutes.
It can't find you the best developers. But it certainly helps weed out candidates who talk up a storm but can't actually code.
The correct answer to most sorting algo challenges in the real world is some variation on "use Array.sort"
I'm more interested in how people interpret requirements, how they resource knowledge, how they architect their code, how they test it, etc.
My recently retired pet challenge was to fetch and amalgamate responses from three different, unreliable, URLs and then return them in a single JSON document. For the web developers I was hiring it worked well.
http://www.gayle.com/blog/2013/09/18/companies-who-give-cand...
No real need for me to summarize it, it's all pretty well expressed in this blog post.
I didn't get as much whiteboard coding as I thought in my recent interview with a big company. Last 2 actually.
But of course facebook and google was still all coding. Google is still obsessed with their overwrought process, and still try to sell a poor false positive rate as a feature.
I still haven't really heard a better idea. Some of them sound incredibly hostile to the applicant (e.g. lets try it for X days). Do this work, bring it in and discuss is a pretty decent idea.
I'd like to see more of "here's what we want, lets code it on this computer however you want.". Lets talk about while we work.
or just talk about what you have done.
On my team we aren't doing anything particularly crazy beyond a large crud application. We feel confident enough in our development process that we can hire interns and make them productive. We are more interested in knowing they want to learn and are able to learn our application. Culture fitnisnlore important to us.
As a result, having a conversation with the applicants is much more valuable than a coding challenge. It works for us.