3 ms·

You're selecting for candidates that either have the kind of memory that lets them recollect those experiences on demand, or can fabulate it. Once word gets ou

You're selecting for candidates that either have the kind of memory that lets them recollect those experiences on demand, or can fabulate it. Once word gets out about your interview process candidates will just prepare something ahead of time, as they do for the HR interview already.

IgorPartola 6y ago
What was the last interesting project you personally worked on and what were the challenges with it? What technology did you use to solve them? I mean if you literally can’t remember anything of what you’ve worked on ever, no I don’t think you’d be a good hire. And also this part is surprisingly hard to bullshit. You can say “well I worked on an eCommerce site and it was hard because we had a lot of visitors” isn’t a full answer. If that’s as much as you can give me, no I don’t believe you contributed much to that project. Maybe I’m wrong and you are brilliant and just can’t remember, but it’s a risk of false negatives that I think most employers will find acceptable. But: “It was hard because we had a very complicated system for determining the final price of the whole cart because of discounts offered if you bought certain pairs of products together. I didn’t implement that system and we had plans to eventually rewrite it but in the meantime we started calculating the prices in our task system instead of during the web requests. It reduced web server load and made adding things to the cart feel faster.” Me: “OK that sounds neat but how did you prevent race conditions? Say while the first calculation was running the customer added a second item that triggered another calculation? What if the first task finished after the second?” Then: “Ah yes I recognized that it would be a problem when writing that code. At first I tried using a lock using Redis for the cart but that just made the tasks serial and the whole thing took longer. Plus if a task failed or was interrupted it could cause issues. So instead I just put the latest task ID onto the cart object in Postgres so I always knew which the latest task was. When a task finished and wanted to update the price first it would lock that cart with the Redis lock, then check if the ID still matched its own, then update and unlock.” The above tells me how they think and what they think of. If I’m not getting enough technical detail out of them I will ask stuff like “what Redis primitive did you use to create the lock?” But usually the interviewee will go into lots of technical detail all on their own.

IgorPartola 6y ago

What was the last interesting project you personally worked on and what were the challenges with it? What technology did you use to solve them? I mean if you literally can’t remember anything of what you’ve worked on ever, no I don’t think you’d be a good hire. And also this part is surprisingly hard to bullshit. You can say “well I worked on an eCommerce site and it was hard because we had a lot of visitors” isn’t a full answer. If that’s as much as you can give me, no I don’t believe you contributed much to that project. Maybe I’m wrong and you are brilliant and just can’t remember, but it’s a risk of false negatives that I think most employers will find acceptable. But: “It was hard because we had a very complicated system for determining the final price of the whole cart because of discounts offered if you bought certain pairs of products together. I didn’t implement that system and we had plans to eventually rewrite it but in the meantime we started calculating the prices in our task system instead of during the web requests. It reduced web server load and made adding things to the cart feel faster.” Me: “OK that sounds neat but how did you prevent race conditions? Say while the first calculation was running the customer added a second item that triggered another calculation? What if the first task finished after the second?” Then: “Ah yes I recognized that it would be a problem when writing that code. At first I tried using a lock using Redis for the cart but that just made the tasks serial and the whole thing took longer. Plus if a task failed or was interrupted it could cause issues. So instead I just put the latest task ID onto the cart object in Postgres so I always knew which the latest task was. When a task finished and wanted to update the price first it would lock that cart with the Redis lock, then check if the ID still matched its own, then update and unlock.” The above tells me how they think and what they think of. If I’m not getting enough technical detail out of them I will ask stuff like “what Redis primitive did you use to create the lock?” But usually the interviewee will go into lots of technical detail all on their own.