|
|
|
|
|
|
by emmydee
910 days ago
|
|
|
Thanks for sharing. I wouldn't consider "failures" as learning experiences, as I'm sure you are too. W.r.t hiring, I can share some thing that really worked for me:
Engineering: I've had great success with giving prospects who pass the initial screen, a small real world problem or user story in our codebase. No NDA, just show them a User Story, and ask them how they'd go about it.
And just listen. Make it interactive. For example, I'd deliberately leave out a couple of details in User Story. So if the Engineer starts solutioning rightaway that's a red flag. I've also shown snippets of code that has a simple bug, and asked them to "read" the code and figure out what might be wrong. The best engineers are ones who can read and understand other people's code also, in addition to their own. Wishing you the best, in the next iteration of your entrepreneurial adventure! |
|
|
It's interesting how "treat it as real as possible" is the best advice for both parties to have the best possible outcome. As an interviewee I've found that the more divorced from the actual work the interview challenge is, the "spicier" the engagement is overall.
I was part of an org that was having trouble hiring people. To help with this, they decided to obfuscate the stack used because several candidates gave up after trying to use the tool the team (who had all left) settled on ~10yrs ago. "Just don't tell them we use X" was the decision management made. At some point the people left holding the bag will have ask why and you will owe them an explanation of why this wasn't discussed from the beginning.
It took me a while to figure out why I think the way you are doing things is important to me, I hope that makes sense.