3 ms·

Absolutely agree, I'm always afraid of loosing out on someone great. Even the screening of CVs themselves is an incredible hard task as the best engineers are o

by TN1ck 2y ago

Absolutely agree, I'm always afraid of loosing out on someone great. Even the screening of CVs themselves is an incredible hard task as the best engineers are often humble and maybe not portray their strengths enough. What I do to make the live coding challenge a bit nicer: * I use codesandbox.io (not affiliated) as a live coding environment which is a VSCode editor that executes your code whenever you save. This makes it much more realistic how one would solve it real life. * I have them share their screen and make it clear that they can google whenever needed and that it's expected (who remembers the exact incarnations for reading a file or some API) * I only do one challenge, which most candidates finish in less than 30min. We then talk about refactoring it, building an API design around it etc. * The challenge itself is building a solver for a text based game, which imho is a fun task and is literally reading a file and filtering the content with some ifs. Any recommendations for improvement are welcome.

nomel 2y ago
I think executing code makes things too strict, and can lock up/shut people down, since forgetting a library function name means you're completely stuck, which causes a feedback loop of nervous. Interviews are high stress. Absolute precision, required to run code, is not a good fit for high stress, in my opinion. You'll filter people that haven't don't a lot of interviews more than anything. I keep the problem relatively simple. I tell them that they can use whatever language, don't worry about silly typos, or exact syntax, and if you forget a library name just make one up. It's trivial to see if someone can code without executing the code. If I notice obvious problems, I'll describe the incorrect behavior, like if there's an infinite loop: "I see a problem. When you run the code, you see that it never ends".
- jgwil2 2y ago
  > forgetting a library function name means you're completely stuck Just let them use Google to find documentation, as they would in a real job setting.
  - nomel 2y ago
    No need. I explicitely tell them that I don't care if they remember exact library/function names, and to just make them up and tell me what they do, if they don't remember. If you require specifics like that, you'll filter out anyone who hasn't worked on that specific very recently. Those sorts of things aren't something you should need to worry about keeping in your head for long.

by TN1ck 2y ago

nomel 2y ago

I think executing code makes things too strict, and can lock up/shut people down, since forgetting a library function name means you're completely stuck, which causes a feedback loop of nervous. Interviews are high stress. Absolute precision, required to run code, is not a good fit for high stress, in my opinion. You'll filter people that haven't don't a lot of interviews more than anything. I keep the problem relatively simple. I tell them that they can use whatever language, don't worry about silly typos, or exact syntax, and if you forget a library name just make one up. It's trivial to see if someone can code without executing the code. If I notice obvious problems, I'll describe the incorrect behavior, like if there's an infinite loop: "I see a problem. When you run the code, you see that it never ends".

jgwil2 2y ago
> forgetting a library function name means you're completely stuck Just let them use Google to find documentation, as they would in a real job setting.
- nomel 2y ago
  No need. I explicitely tell them that I don't care if they remember exact library/function names, and to just make them up and tell me what they do, if they don't remember. If you require specifics like that, you'll filter out anyone who hasn't worked on that specific very recently. Those sorts of things aren't something you should need to worry about keeping in your head for long.