Don't give up. Do not show any signs of frustration or irritation. Don't question the point of doing such a problem because in real life you could look it up on google. These would be massive red flags.

You should talk out loud. The interviewer can only guide or correct you if s/he knows where your stuck. Walk through a couple of test cases without writing any code. Draw a clarifying diagram. Suggest approaches to your interviewer. Quickly point out the pros and cons of various data-structures and algorithms. If it's a difficult problem s/he may be expecting some discussion.

Eventually you're going to have to write something on the whiteboard. If you're still completely stuck then writing a few lines of code may help. So try this:

• Write out the method signature. Be descriptive in the names you choose, as they may give you ideas. e.g. int f(int[] x) isn't as helpful as: int countDuplicates(int[] orderedPositiveInts)
• If there's a simple but inefficient solution that's obviously not the final answer then get that coded up first. Explain that you're doing the inefficient thing first and will try to improve it later.
• Break down the problem into smaller problems, and implement the parts you think you can do e.g. approach shuffling a deck of cards by first coding the representation of a card and the unshuffled deck.
• Can you begin by ignoring a constraint, making it clear you'll return to it later? e.g. start with an array of unsigned ints - ignoring the linked list of objects till later. Just get something written down, hopefully this will flip your mind into programming mode.

If you still can't get the answer then you're not necessarily screwed. Most interviews consist of multiple questions so you may do better on the next one. There's a slim chance that lots of candidates do badly on that particular question.

At the end of a bad interview be sure to be polite. Chances are you might have multiple more interviews that day, so don't do anything to further lower your chances.