3 ms·

You are still not testing if they can code. But whether under the scrutiny of another person, they can code. Maybe this is important to you, maybe peer programm

You are still not testing if they can code. But whether under the scrutiny of another person, they can code. Maybe this is important to you, maybe peer programming is important to you for example. I remember a young dev who couldn’t pass such tests, as he would get too nervous, yet he had written the core tech for many shipped products. The type of guy you would just stick in dark room. With age this type of stuff settles down.

giantg2 2y ago
I agree with both you and the parent to some degree. I have experienced interviews that went badly because they were in an IDE I wasn't familiar with, or in Leetcode (never used it). So I'm distracted by how to use the tool rather than how to code the solution. But I can also see how stuff like finding a substring is easy - most languages have a function for it. But at that point, you're testing different things - problem-solving vs rote memorization of a provided function. I feel like a good middle is to allow Google for documentation searches, not solution searches. Without searching (or IDE with radix completion), I'd probably fail the test for not knowing the syntax off the top of my head.
- WalterBright 2y ago
  > rote memorization of a provided function. I never mesmerized strstr(). But using it frequently makes it stick in my mind.
  - giantg2 2y ago
    Not everyone uses it (or their language equivalent) frequently depending on the needs of their project. If I'm really using it frequently, then I would probably be looking at higher accuracy/resiliency options like parsing the input and comparing to a map, or regexes.
alabastervlog 2y ago
“Scrutiny of another” who’s a peer or even a client is super different from an interview. The latter has more in common with an open mic night, the prospect of which the vast majority of people are terrified and would break down if they attempted it.
- WalterBright 2y ago
  My first attempts at public speaking were a frozen horror. But I kept doing it, and it kept getting easier and easier. I recommend that when there's an opportunity to get up in front of a mike, take it, and get comfortable with it. It's a skill that will serve you well.

giantg2 2y ago

I agree with both you and the parent to some degree. I have experienced interviews that went badly because they were in an IDE I wasn't familiar with, or in Leetcode (never used it). So I'm distracted by how to use the tool rather than how to code the solution. But I can also see how stuff like finding a substring is easy - most languages have a function for it. But at that point, you're testing different things - problem-solving vs rote memorization of a provided function. I feel like a good middle is to allow Google for documentation searches, not solution searches. Without searching (or IDE with radix completion), I'd probably fail the test for not knowing the syntax off the top of my head.

WalterBright 2y ago
> rote memorization of a provided function. I never mesmerized strstr(). But using it frequently makes it stick in my mind.
- giantg2 2y ago
  Not everyone uses it (or their language equivalent) frequently depending on the needs of their project. If I'm really using it frequently, then I would probably be looking at higher accuracy/resiliency options like parsing the input and comparing to a map, or regexes.

alabastervlog 2y ago

“Scrutiny of another” who’s a peer or even a client is super different from an interview. The latter has more in common with an open mic night, the prospect of which the vast majority of people are terrified and would break down if they attempted it.

WalterBright 2y ago
My first attempts at public speaking were a frozen horror. But I kept doing it, and it kept getting easier and easier. I recommend that when there's an opportunity to get up in front of a mike, take it, and get comfortable with it. It's a skill that will serve you well.