Here's a few notes to consider. I'll build off of @alice's solution, which maintained your logic and general approach.
First, when working on sample projects like this, it's a good idea to set up the test cases they give you. Here's a starting point, which you can note fails the second test case, but passes the first.
So what happens in the second test case? To begin, the
while condition gets the first value (3) from the iterator. Then it uses
iter.find(...) to look for another 3 in the rest of the iteration -- "find a 3 that comes after the current point in the iteration". It doesn't find one, and now the iterator has been exhausted. The
while condition runs again and gets
You can think of looking through the rest of the iterator as simultaneously increasing your current position. One way to fix this would be to clone the iterator before running
find(...) on it, so that you exhaust the cloned iterator instead of your while-loop iterator.
(This ended up being a long reply, but the last two paragraphs are the most pertinent to your original question. I suggest working through this to make sure you understand how the iterators are consumed and why cloning fixed that part of the problem.)
But what you're ultimately trying to do is look through the rest of the vector beyond the current position. So another approach would be to keep track of the current position as you go, and create a new iterator "from scratch" instead. This also means you don't have to calculate the index of the current value once you've found a solution. Here's a version with those changes. Because we don't need to use or clone the iterator within the loop anymore, we can also use
for to consume the iterator instead.
Now the second test case succeeds, but the third one is failing. When you look up the second position, you're iterating over the entire vector again. So when the second value is the same as the first value, you get the index of the first value. You could use
skip(cur_index + 1) again, but instead of iterating twice inside the loop, let's just use
enumerate() a second time, when we look for a match.
Things look pretty good at this point, but I'll throw in a final algorithmic observation for extra credit. Instead of looking for a match among the values that come after the current value, you could check for a match among the values that came before. The advantage is that you can record the values as you go in a way that's quicker (and cleaner looking, IMO) to look up than iterating over the vector each time.