There is way less bandwidth involved since the amount of data transferred for a shared coding exercise does not surpass the data (pixels) involved in screen sharing.
Helps with remote interviews/candidates with slow connections.
I think screen sharing isn't really optimized for text legibility - it's still the same video calls, just using screen capture instead of webcam as a source.
When I've shown some code over Skype, I had to change fonts size to pretty large to make sure it was comfortable to read.
While this looks like a well developed feature, I despise the concept of coding in a phone interview too much to not worry about this enabling more of it just because it's more convenient.
Especially for research-heavy positions, the amount of nonsense exercises really makes or breaks a company impression for me.
case 1) Have a serious technical conversations with questions testing my understanding, asking about my projects, ideas and interests.
case 2) 3 minutes of smalltalk while the interviewer reads out some points from my CV so I can repeat them back. Then 'alright, let's do a coding exercise'. Learn nothing about the team, their process, their vision in the phone rounds.
Real-time interviews are the worst of two worlds (emergency fast coding and live demonstration at the same time) and barely show anything about how one normally does things.
E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. It helped me a few times when the servers were on fire and I needed to fix stuff fast and think later. But that's incompatible with live demonstration, unless the purpose is to embarrass myself and make me look completely incompetent or diffident.
>E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks.
That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment.
A real-life example of what I said in the last few lines above:
A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser):
# init 0
(which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...
Oh, I can only guess. A well run shop will have performance bonuses that the floor employees may depend on for vacation funding, college funding, or a down payment on a house. A shutdown like that can impact a weekly, quarterly or annual bonus severely. He may have inadvertently prevented someone from financing the house they wanted
It's definitely a skill that doesn't translate to actual development. Before I was a programmer I was a Navy nuclear power plant operator and they did boards like that. In that situation, it made sense because you needed to be able to remember causality procedures during an emergency. Coding, on the other hand, doesn't have that requirement often if at all.
A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck. Or having to feel guilty about reaching for Stack Overflow and wondering how that would affect their interviewer's opinion of them. Sure they could Google the question but then give them something that requires a litte bit of creativity on their side and ask them to talk through their submission.
In an interview I'm much more interested in hearing how people would structure and architect applications, how they think about and would deal with tech debt, how they'd iterate and improve, how they think about reliability, instrumentation, testing and what not than having them solve a simple question in 30m. I'm not hiring people for a position that boils down to "solve a simple problem in 30m" either.
> A simple homework assignment will do much of the same and allow them to do it at their own pace and having full access to any tool, instead of during some arbitrary time limit with someone else breathing down their neck.
Who is paying for that time?
As someone who has interviewed a lot of people; if I am going to ask someone to perform some coding, I offer them the fact that my entire TEAM (5+ people) will be there for them to ask questions of.
That is us being serious about hiring. It isn't just a single person who is interviewing - but a large amount of the engineering team.
On the contrary, for positions that require getting your hands dirty with implementation, I find it very valuable to be able to look at a code example with the applicant. How do they approach making sense of legacy code. Do they spot code smells? How familiar are they with the technology at hand? Are they comfortable with asking questions when things are not clear? None of this must involve solving algorithmic puzzles under pressure ... but having a conversation around code can be of value.
I agree with this approach a lot, being able to speak about code intelligently is very important. But live coding by fire on some esoteric random brain teaser is not effective, imho.
But if you're hiring general purpose noon-senior software engineers, live coding exercises separate the wheat and the chafe very quickly.
Lots of people lie on resumes and are smooth talkers, but lack basic skills for their job. A coding exercise is a really fast way to find these. Then you can move on to more interesting things.
Yup, I don't enjoy coding interviews, but the number of people I've interviewed with ostensibly many years of programming experience who can't actually write some basic code with a for loop and a couple of variables makes me extremely hesitant to hire without a coding interview. If you haven't run across people like this yet, you simply haven't done enough interviews yet, or have somehow entered into an alternate fairytale land where everyone is honest (and if so please take me with you!).
> or have somehow entered into an alternate fairytale land where everyone is honest
This won't likely be a popular answer, but more likely than what you described above is simply that you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand.
It's perfectly understandable that many don't have this skill as it's rarely ever taught before you start doing interviews at an employer.
Continuing your strained analogy, so because you didn't want to make only right turns, everyone else should spend an extra 10min in traffic each morning?
The reason to "constrain your solution" is to not rule out very capable candidates who have "stage fright" and not offend other very capable candidates who take offense to your crappy brain teaser problems that don't actually reflect anything they'd do in their real job.
> don't actually reflect anything they'd do in their real job
I should hope the coding exercise would reflect what they would be doing! Finding logic bugs, munging data, using appropriate data structures, recognizing recursion, etc.
If coding isn't a significant portion of the job (researcher, manager, etc.) then yeah, don't put it in the interview.
I think the problem with this approach is you're actually selecting for a related skill that might have little to do with whether the candidate will be successful. Some people are very good at doing the work but don't perform well under "social" pressure, while others may be very good at dissecting a small thing in the interview context and yet be unable to follow through on a large, complex task. The company I work for solves that issue by combining front-end interviews with a homework project of reasonable scope, followed by a paid work-along day. It takes more time and investment than running through some coding exercises on the phone, but results in a more cohesive team because we know before we hire not only whether someone can do the work, but also whether they can do the work with us.
At IBM, I review hundreds of resumes and interview dozens of candidates each year (mostly students or new graduates). I used to ask tough algorithmic questions, require a small coding assignment, etc. I no longer do that.
Today, I have technical conversations like you describe. I don't need you to remember that 415 is Unsupported Media Type. But I need you to be able to discuss how REST works, the difference between 400s and 500s error codes, and maybe even REST vs GraphQL advantages and tradeoffs, if you mention the latter on your resume.
Occasionally I get a surprised "This was so nice. I was expecting a coding interview". It was a coding interview, just not the kind the candidate is used to.
You can look up specific answers on Google, but you can't quickly google your way out of a conceptual discussion, your involvement with past projects, technologies that excite you, etc.
Generally speaking, I can tell within 5 minutes who is a great candidate.
Luck might have played a part, but I have not had a single bad hire with this method so far. In fairness, I'm selective with the candidates I decide to interview, from usually large pools. For these, I also tend to review code they've written in the past if they specify a GitHub account on their resume.
I've done hundreds of interviews for candidates over the past twenty years and couldn't agree with you more. The ultra rare occurrence that someone can talk their way through and elude b/s detectors is usually caught later in the interview process anyway.
I've seen places (well, one place) that have "team meetings". You just have an informal group talk with a few members of the team, and just usually reveals a lot -- to both sides!
Based on the performance of the people I have hired over the years. Of course, there is always the possibility that a candidate might have been great and this was not discovered by my approach, but I think this is an inherent risk.
That's why I was wondering. For companies that need to scale, a high false negative rate is inherently costly. But, if you only need to hire a small number of people that may be a cost you're willing to eat.
> In fairness, I'm selective with the candidates I decide to interview, from usually large pools.
I agree with your thoughts on interviewing, but the "real-time coding" session in my mind isn't part of the interview, it's part of the pre-interview screening process that you gloss over here.
Asking programmers to code tough problems on the phone or whiteboard is a good test of certain personality traits, but not a good test of programming skills. On the other hand, there are problems so simple that a decent programmer should consider them to be typing rather than coding, and I think they make perfectly decent initial screening tasks. FizzBuzz is the obvious example here, but I think it's too popular to be useful. I periodically hear from devs who say they get so nervous in interview situations that they can't program at all, but no type of screening is going to be perfect.
And I much prefer this kind of objective screening process to more subjective ones, which tend tend to devolve into "let's choose people with backgrounds similar to mine".
Yep, obviously there are good ways and bad ways to use any tool. And the shiny shiny lures a lot of people into using new tools poorly when they already know how to use old tools well.
Well I would like to see some basics fixed like being able to talk to people without having to restart the client. And screen sharing without crippling performance of my laptop so my code still autocompletes while working together with someone.
> Calling capabilities are only supported on Microsoft Edge and Google Chrome.
Feels like I'm back in time a decade. I don't understand why other browsers are not supported: are they using non-standard features? I can't imagine what those would be. WebRTC is supported by every browser nowadays.
Microsoft isn't the only company involved in ORTC, so chrome supports it as well. Most of the industry just hasn't adopted it yet, it's much less mature than webrtc at this state but may supplant it someday.
OT : has anyone noticed that microsoft is adding features which were covered by niche saas companies?[1]
There is a similar tool that has recently been introduced by microsoft for feedback form,automated mails and chat(drift/intercom) that integrates with outlook.
[1]https://coderpad.io/
I liked the entreprenure who developed coderpad, he gave a talk on youtube as well.
This seems like a good option for hiring remote engineers. The reason I like to call people to come in person for fizz buzz tests is to verify that they're not collaborating with someone. With the simultaneous video chat and text editor, you can examine one's thought process while preserving some integrity of the interview process.
These ideas are great on paper, but in real life, don't really work.
Most developers (especially senior ones) have their preferred IDE/editors/tools/etc. Forcing them to use a custom one for an interview, where they have to constantly fight memory muscle and work with a new tool is likely to give unrealistic results.
Quick example (by no means the only one!): On vim insert mode, ctrl+w deletes a word. On a browser, it closes the tab. It's really hard for me avoid memory muscle jumping in and closing a tab. TBH, I simply cannot code python on a browser textfield, since I end up closing the tab sooner or later.
Screen sharing works great, and has really no drawbacks.
One of the best experiences I've had is using HackerRank. They have a nice code editor with a audio/video communication tool built-in. This is sort of the reverse of that.
49 comments
[ 3.3 ms ] story [ 67.8 ms ] threadHelps with remote interviews/candidates with slow connections.
When I've shown some code over Skype, I had to change fonts size to pretty large to make sure it was comfortable to read.
Also, bandwidth. Video streaming requires a lot.
Especially for research-heavy positions, the amount of nonsense exercises really makes or breaks a company impression for me.
case 1) Have a serious technical conversations with questions testing my understanding, asking about my projects, ideas and interests.
case 2) 3 minutes of smalltalk while the interviewer reads out some points from my CV so I can repeat them back. Then 'alright, let's do a coding exercise'. Learn nothing about the team, their process, their vision in the phone rounds.
Real-time interviews are the worst of two worlds (emergency fast coding and live demonstration at the same time) and barely show anything about how one normally does things.
E.g. in emergency coding I automatically assume I'll inevitably make mistakes due to haste, so I run a lot of sanity "is 1+1 still 2, do I remember that right?" checks. It helped me a few times when the servers were on fire and I needed to fix stuff fast and think later. But that's incompatible with live demonstration, unless the purpose is to embarrass myself and make me look completely incompetent or diffident.
That's a great point. I've been in such emergency situations multiple times earlier in my career, when I was a system engineer (mainly Unix field support work) at a large hardware vendor. I used to do the same as what you say (double-check many things, sometimes even triple-check, particularly the more important changes I was making via some script or command), and I know it helped prevent me many times, from making mistakes that could have been serious, in a high-pressure and high-stakes situation (where said situation was often because of data loss with no backups or something equally bad). And in many cases, I was successful in solving the problem / restoring the data / etc. Also saw, and in some cases, prevented colleagues from making, such mistakes. Was too late to prevent them in other cases (sometimes by a few seconds, like once when I was a bit too late while trying to grab a colleague's wrist off the keyboard when they were typing a command (as root, natch) that could cause irrecoverable damage (and sometimes did). And this in live production environments on multi-user Unix systems, e.g. in a factory environment.
A real-life example of what I said in the last few lines above:
A colleague and me were in the computer room of an auto parts factory that had such a multi-user Unix system deployed in production. As part of some maintenance / problem-solving procedure, he types (as the Unix superuser):
# init 0
(which shuts down the Unix system automatically, with no delay or warning) on the main console, without thinking of informing all the live users in production to stop and save their work - on the shop floor, stores, accounts dept., etc. You can guess what happened next - dozens of calls on the intercom from highly irate workers from all those depts., in colorful language ...
The problem given in a coding interview should be a simple one and the candidate should be allowed to choose the solution language.
In an interview I'm much more interested in hearing how people would structure and architect applications, how they think about and would deal with tech debt, how they'd iterate and improve, how they think about reliability, instrumentation, testing and what not than having them solve a simple question in 30m. I'm not hiring people for a position that boils down to "solve a simple problem in 30m" either.
Who is paying for that time?
As someone who has interviewed a lot of people; if I am going to ask someone to perform some coding, I offer them the fact that my entire TEAM (5+ people) will be there for them to ask questions of.
That is us being serious about hiring. It isn't just a single person who is interviewing - but a large amount of the engineering team.
Sure.
But if you're hiring general purpose noon-senior software engineers, live coding exercises separate the wheat and the chafe very quickly.
Lots of people lie on resumes and are smooth talkers, but lack basic skills for their job. A coding exercise is a really fast way to find these. Then you can move on to more interesting things.
This won't likely be a popular answer, but more likely than what you described above is simply that you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand.
It's perfectly understandable that many don't have this skill as it's rarely ever taught before you start doing interviews at an employer.
I'm sure we could figure out a non-code non-marker way. I'm also sure I could figure out a commute involving only right turns.
But why would I arbitraily constrain my solution like that?
The reason to "constrain your solution" is to not rule out very capable candidates who have "stage fright" and not offend other very capable candidates who take offense to your crappy brain teaser problems that don't actually reflect anything they'd do in their real job.
I should hope the coding exercise would reflect what they would be doing! Finding logic bugs, munging data, using appropriate data structures, recognizing recursion, etc.
If coding isn't a significant portion of the job (researcher, manager, etc.) then yeah, don't put it in the interview.
Sadly, I have not found this to be the case almost anywhere I have worked or interviewed (seems to be especially relevant the bigger the company is).
Today, I have technical conversations like you describe. I don't need you to remember that 415 is Unsupported Media Type. But I need you to be able to discuss how REST works, the difference between 400s and 500s error codes, and maybe even REST vs GraphQL advantages and tradeoffs, if you mention the latter on your resume.
Occasionally I get a surprised "This was so nice. I was expecting a coding interview". It was a coding interview, just not the kind the candidate is used to.
You can look up specific answers on Google, but you can't quickly google your way out of a conceptual discussion, your involvement with past projects, technologies that excite you, etc.
Generally speaking, I can tell within 5 minutes who is a great candidate.
Luck might have played a part, but I have not had a single bad hire with this method so far. In fairness, I'm selective with the candidates I decide to interview, from usually large pools. For these, I also tend to review code they've written in the past if they specify a GitHub account on their resume.
How do you validate that this is true?
I agree with your thoughts on interviewing, but the "real-time coding" session in my mind isn't part of the interview, it's part of the pre-interview screening process that you gloss over here.
Asking programmers to code tough problems on the phone or whiteboard is a good test of certain personality traits, but not a good test of programming skills. On the other hand, there are problems so simple that a decent programmer should consider them to be typing rather than coding, and I think they make perfectly decent initial screening tasks. FizzBuzz is the obvious example here, but I think it's too popular to be useful. I periodically hear from devs who say they get so nervous in interview situations that they can't program at all, but no type of screening is going to be perfect.
And I much prefer this kind of objective screening process to more subjective ones, which tend tend to devolve into "let's choose people with backgrounds similar to mine".
Feels like I'm back in time a decade. I don't understand why other browsers are not supported: are they using non-standard features? I can't imagine what those would be. WebRTC is supported by every browser nowadays.
[1]https://coderpad.io/ I liked the entreprenure who developed coderpad, he gave a talk on youtube as well.
Most developers (especially senior ones) have their preferred IDE/editors/tools/etc. Forcing them to use a custom one for an interview, where they have to constantly fight memory muscle and work with a new tool is likely to give unrealistic results.
Quick example (by no means the only one!): On vim insert mode, ctrl+w deletes a word. On a browser, it closes the tab. It's really hard for me avoid memory muscle jumping in and closing a tab. TBH, I simply cannot code python on a browser textfield, since I end up closing the tab sooner or later.
Screen sharing works great, and has really no drawbacks.