There was no hard list, but we found early on that these were better factors to look at instead of just focusing on if the app won all the time.
We wanted to see factors that tended to align with our team and workflows: How often did they check in? How were the commit messages? Were tests added or needed? How readable and organized was the project? We were not looking as much at the tech, typos, edge case bugs they left, or even if their tic-tac-toe engine never actually lost we had many unanimous approvals for apps that sometimes lost. If there were more approvals than rejections on the PR, we brought the person in to learn more. We had one submission that worked through CLI just because “I was bored and wanted to try it.” We tried to keep an open mind when reviewing the candidates, and multiple people were required to weigh in before a final decision. Some people tried to impress us with huge, elaborate apps that used different services and engines. That was all we asked we intentionally left it open-ended. * Tech stack removed to protect the innocent. We are a shop, but it is not a requirement that you implement your program using that tech stack. Push your code back to GitHub and send us a pull request. Commit early and often, with good messages.Ĥ. Create a program that can interactively play the game of Tic-Tac-Toe against a human player and never lose.ģ.
The instructions and ask were simple, and laid out in a README. We made a public repo on GitHub under our org account for the purpose of tests. There was a time when people didn’t have a bunch of public repos to peruse. During the time this story occurred, it was more accepted, and we had a lot of success with it. The pros and cons of this are a completely different discussion altogether. I know the practice of asking people to code for free just to get an interview is not popular right now. But one truly stood out, and it taught me to think about what I am really looking for in these sorts of submissions. And as you can imagine, we got all ranges of results from massively impressive to wondering if this candidate was messing with us. One way we sorted through them all was requiring coding tests for potential candidates.
We were heavily involved in the community and allowed for remote hires, so we received a constant influx of applications for open roles. In a previous role, I was an engineering manager for a well-known company for a particular tech stack.
0 kommentar(er)
