3 ms·

> one addition to programming assignments includes an analysis write up. when i was interviewing candidates this was the fastest way to filter those who unders

> one addition to programming assignments includes an analysis write up. when i was interviewing candidates this was the fastest way to filter those who understood and those who didnt. ask someone to talk you through how to solve some real-life problem. to look at a stack trace and describe what they see, or to run a profile and trace through the cause of a hotspot/contention. show them an issue and have them live debug to root-cause and fix. it's okay if they use the internet, SO, etc. -- that's how we all do it. see what they have to look up! just listening to the amount of depth someone can verbally communicate during novel problem solving (including additional questions they ask you) turns a 60min interview that wastes time into a 10min one that tells you if you can move on. a favorite one of mine was to ask the candidate to describe in as much detail as possible what happens between a keystroke typed into a google search box and the search results appearing. the diversity of replies is facinating. some will tell you "google returns results from its database", others will ask you if you want them to first describe how the keyboard works at an electrical level through the USB or bluetooth driver stack. "Never memorize something that you can look up." --someone smart

nkingsy 4y ago
Ugh I had someone ask me to debug a verbally communicated error message in an interview. Like they picked some random port configuration issue that had stumped them for days in the past and thought cool let’s remove the internet, the command line, and ask people to solve it on the spot. I offered plenty of plans for how I would go about debugging, but I didn’t know the one simple trick. I agree with trying to use challenges that are closer to the real work, but it’s really hard to do that without over-testing domain knowledge. For instance, I ask candidates to do some asynchronous control flow. These are all candidates with js listed as their best language and I offer to let them look things up or to show them the promise apis they need, but a certain percent just refuse to engage with the problem because they don’t have the domain knowledge and seem to feel they’re being tested unfairly. The problem does a really good job of showing a candidates grasp of all the tricky parts of js, so I keep using it despite the drawbacks.
- leeoniya 4y ago
  > Ugh I had someone ask me to debug a verbally communicated error message in an interview. i dont mean that the problem is only verbally communicated. i mean that the debugging process the candidate does is verbally communicated. in the scenario you're describing you'd be sitting at that machine with access to the internet on another machine. like, you know, in real life. > The problem does a really good job of showing a candidates grasp of all the tricky parts of js, so I keep using it despite the drawbacks. async stuff in js is pretty good, but it's also easy to go too deep on it with some bizzarely poorly architected code. many js devs still fail to grasp all the implications of closures, or how to avoid memory leaks, or how to work with the GC rather than against it.
  - deleted 4y ago
    [deleted]
matheusmoreira 4y ago
That's a great way to evaluate someone! Individualized and personal, uses concrete problems, no artificial restrictions. It's a shame our mass education systems cannot use it. They simply cannot apply such a humane method to hundreds or thousands of students. They are reduced to applying their bullshit test questions because it's the best they can come up with at their scale.

nkingsy 4y ago

Ugh I had someone ask me to debug a verbally communicated error message in an interview. Like they picked some random port configuration issue that had stumped them for days in the past and thought cool let’s remove the internet, the command line, and ask people to solve it on the spot. I offered plenty of plans for how I would go about debugging, but I didn’t know the one simple trick. I agree with trying to use challenges that are closer to the real work, but it’s really hard to do that without over-testing domain knowledge. For instance, I ask candidates to do some asynchronous control flow. These are all candidates with js listed as their best language and I offer to let them look things up or to show them the promise apis they need, but a certain percent just refuse to engage with the problem because they don’t have the domain knowledge and seem to feel they’re being tested unfairly. The problem does a really good job of showing a candidates grasp of all the tricky parts of js, so I keep using it despite the drawbacks.

leeoniya 4y ago
> Ugh I had someone ask me to debug a verbally communicated error message in an interview. i dont mean that the problem is only verbally communicated. i mean that the debugging process the candidate does is verbally communicated. in the scenario you're describing you'd be sitting at that machine with access to the internet on another machine. like, you know, in real life. > The problem does a really good job of showing a candidates grasp of all the tricky parts of js, so I keep using it despite the drawbacks. async stuff in js is pretty good, but it's also easy to go too deep on it with some bizzarely poorly architected code. many js devs still fail to grasp all the implications of closures, or how to avoid memory leaks, or how to work with the GC rather than against it.
- deleted 4y ago
  [deleted]

matheusmoreira 4y ago

That's a great way to evaluate someone! Individualized and personal, uses concrete problems, no artificial restrictions. It's a shame our mass education systems cannot use it. They simply cannot apply such a humane method to hundreds or thousands of students. They are reduced to applying their bullshit test questions because it's the best they can come up with at their scale.