4 ms·
They're too busy writing self congratulatory blog posts on their hiring process to have time to improve it. https://alexgolec.dev/reddit-interview-problems-the
by bschwindHN 5y ago
They're too busy writing self congratulatory blog posts on their hiring process to have time to improve it.
https://alexgolec.dev/reddit-interview-problems-the-game-of-life/ https://alexgolec.dev/reddit-interview-problems-the-game-of-...
- herbturbo 5y agoIt's a good signal for me when I'm presented with silly brain teasers like this in interviews, especially when the technology of the company isn't that great. I'm interviewing you too, so give me something that reflects the problems you solve as a team, otherwise my assumption is your office is full of white boards containing puzzles of the day and your tech is all 3rd party libs.
- randomswede 5y agoI wouldn't actually class this as a brain-teaser. It is a non-trivial[1] problem that doesn't require an "aha!" moment to get right. It is amenable to multiple ways of reaching a correct solution. It has interesting follow-up questions. It also stands a minimal chance to actually discover (some) of the way a candidate thinks. It is also implementing the VM for a Turing-complete computational model. It may also be that anything work-related is actually too long to fit into a limited interview time. Now, a trivial, brain-teaser, question would be "you have an NxM matrix, and you can either go left or up. How many paths are there from the lower left, to the upper-right corner?" I consider it a brain-teaser because if you write code that contains any matrix manipulation or searching, you have basically failed. There is a closed-form expression for the number, so... [1] By "non-trivial", I basically mean that there are multiple correct solutions.
- xtracto 5y agoThat's actually a nifty problem in itself, I don't see anything wrong. Of course I have learned that the actual "proposition" of whatever problem is not what is right/wrong in an interview. The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already). How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby). The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem. I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.