Oh boy, give it three months and we're gonna start being asked this in coding interviews.
[deleted]
Here's a puzzle game. I call it Reverse the List of Integers
131–140 of 188 posts
Re: Here's a puzzle game. I call it Reverse the List of Integers
#132I thought the game was cool so I built a little version of it here: https://blaise.gg/number_game/index.html
Cool!
Though I say the rule about repeated numbers is a bummer. I can see things might get easier (also it might be a more procedurally easy problem to solve) if this is allowed
Basically I don't think it's a "productive" complication
Re: Here's a puzzle game. I call it Reverse the List of Integers
#133Earlier quoted context omitted.
I like that all possible moves are shown at once. Would it be possible to have the sequence be other than [7, 5, 3]?
I added an url parameter so you can load it up with any sequence. Example for sequence 5,2,7 https://bewelge.github.io/aNumberGame?seq=5,2,7
Thanks!
Re: Here's a puzzle game. I call it Reverse the List of Integers
#134Earlier quoted context omitted.
"Dynamic programming" is jargon from competitive programming. It sounds a lot more sophisticated than it is. In reality, it is nothing more than memoization of function calls into an array.
Memoization is just caching so I'm not sure how that would make any difference here.
Different sets of moves can lead to the same state, so if you can cache that a given state will not lead to a solution you can stop exploring that branch when you encounter it again.
Re: Here's a puzzle game. I call it Reverse the List of Integers
#135So like, infinity, infinity-1, infinity-2, etc.?
Re: Here's a puzzle game. I call it Reverse the List of Integers
#136Earlier quoted context omitted.
[9,8] -> [6,3,8] -> [6,2,1,8] -> [6,2,9] -> [8,9]
Yeah, the [n,n+1] is only a problem when there isn't enough wiggle room between the numbers. ex: [2,3] and [3,4] [3,4] --> [1,2,4] --> 4 can't split because 2/2 and 3/1 are invalid --> 4 can't initially split because 2/2 and 3/1 are both invalid [5,6] --> [5,4,2] --> [5,1,3,2] --> [6,3,2] --> [6,5] [7,8] --> [7,3,5] --> [7,1,2,5] --> [8,2,5] --> [8,7] When you add more numbers, you need more wiggle room. So, [4,5,6]…
A solution for [6,7,8,9]:
6,7,8,9
6,3,4,8,9
6,3,4,8,2,7
9,4,8,2,7
9,4,8,2,1,6
9,4,3,5,2,1,6
9,7,5,2,1,6
9,7,5,3,6
9,7,8,6
9,5,2,8,6
9,5,2,1,7,6
9,5,3,7,6
9,8,7,6
Re: Here's a puzzle game. I call it Reverse the List of Integers
#137The rules are too restrictive. Even a basic [1, 2] is not solvable.
For this game to be popular, the difficulty should grow (generally) with the size of the list and the relative differences between numbers.
Re: Here's a puzzle game. I call it Reverse the List of Integers
#138Hi. I'm the post's author. This was something I dashed off quickly, so I was a bit imprecise in the language. Clarifications: Only positive integers are meant to be allowed. (Zero excluded.) Combining is meant to work on adjacent pairs of integers. If this is used in coding interviews, I deny any responsibility. Unless it's used in interviewing me, in which case I will totally take credit.
Should we assume the numbers are initially positive and distinct, too?
They must be, because otherwise you'd never be allowed to split or combine to create the final list.
Re: Here's a puzzle game. I call it Reverse the List of Integers
#139Earlier quoted context omitted.
Memoization is just caching so I'm not sure how that would make any difference here.
Different sets of moves can lead to the same state, so if you can cache that a given state will not lead to a solution you can stop exploring that branch when you encounter it again.
Is that 'dynamic programming' or is that just keeping a set of explored states?
Re: Here's a puzzle game. I call it Reverse the List of Integers
#140My first reaction to this was, "neat coding question for interviews". I started to try to solve it for a few seconds, then thought of when I've asked coding questions. Invariably starting by saying "The goal is to see how you approach and work through the problem, and less so whether you come up with the optimal solution". Then I thought, what if the interviewer and interviewee tackled the problem together, both comi…
It's a problem because it's not deterministic. You need some kind of determinism when comparing 20 people a month and need to justify your position, especially if you're the only one saying no. The biggest problem is that are you, the interviewer, having a good day or a bad day? In your scenario, your performance is necessarily coupled in with the candidate, which is exactly what you don't want, for this goal of determinism.
I think a modification of this works well, and it's what I do:
1. Come up with a problem that's loosely contextually related to the work, and open ended. Leaving it open ended will test their communication and "problem navigation". The contextual relation allows you to, at the end of the interview, explain how it's contextual related to the work. This helps them understand their own performance, rather than leaving them feeling tricked with random puzzles.
2. If the problem is too out of context for the candidate's experience (which is often fine) provide a path that teaches them the background they would need. Makes this "training" path available and known to everyone. Make sure it doesn't take too much time. This helps the determinism since it doesn't rely on luck of some specific knowledge. Also, someone that communicates they want to go this path is the better candidate, regardless of experience, since information seeking is the best attribute of a colleague.
3. Explain that it's purposefully meant to be an open ended, so they should feel free to ask questions, and it's ok if they get stuck. This allows you to collaborate in a way that you can judge against others. Also, it reduces the adrenaline, which is important, because you can easily loose good candidates who "freeze up". Related, maintain positivity. If you seem annoyed, their performance can irrationally plummet. Personally, I'll do a second round if I see someone freeze up, especially if they haven't done many interviews, because I don't think interviewing for the skill of being interviewed is interesting, since I'm interviewing them to work with them.
4. With the above, the metric for their performance is all about communication, problem solving, and skill. The amount of explanation they needed to understand the fundamental problem, and how well they could fit it in their head, the amount of help they needed to implement it, the amount of mistakes they made, and how they reached out for help can be used to justify your yes or no, in a predictable way, that can be compared against others.
Across about 30 people, my observation of their actual performance, compared to my prediction from the interview performance, has been pretty darn close, with only a few outliers. The outliers were those that were either too familiar, or not at all familiar, with the problem space. The too familiar people appear to have better performance during the interview, since they're working from rote. The out of context people have the burden of not having the relationally-compressed version of the knowledge in their head, so run out of working memory. It's very easy, and somewhat fascinating, to see the moment when someone runs out. But, this is why the problem should be loosely related to the work: it's a valid criticism that "they're going to take significant time to ramp!".
I apologize for the wall, but this is something I'm interested in, and would love to see how others handle it. I think the Jim Keller way is the best, but it requires more than 45 minutes, and a certain level of seniority on the candidates side.