The method

How long should I spend before writing any code?

About ten minutes of a forty-five minute round: three reading and clarifying, seven thinking out loud. That feels long while it is happening and it is the block that pays for itself, because code written before you can say what the answer looks like gets thrown away. The signal an interviewer is waiting for is that you can state the brute force and its cost, and then name the waste in it. Once you have said that, you can type.

Should I give the brute force even when I can see the optimal solution?

Say it, in one sentence, with its cost. It takes fifteen seconds and it proves you understood the question, which a bare optimal solution does not. Then say what is wasteful about it and go straight to the better version. What loses marks is spending ten minutes coding the brute force when you already know the answer, not naming it.

What do I do if I do not recognise the pattern at all?

Fall back to the routine rather than searching your memory for a name. Write down a small example by hand, solve it the slow way on paper, and then ask what you had to keep looking back at. That question is what names the pattern, and it works on problems you have never seen because it is a question about the work rather than about a catalogue. If it is still not coming, say the brute force out loud and start coding it; a running slow solution is worth far more than a silent search for a fast one.

Is it bad to take a hint?

Taking one is normal. Needing three is the problem, and so is going quiet until one arrives. Keep the interviewer inside your reasoning: say what you have ruled out and why, and ask a specific question rather than a general one. A candidate who says “I have ruled out sorting because of the O(n) requirement, so I think the order has to come from a hash structure, but I cannot see how to avoid walking each run twice” gets a small nudge and keeps the round. A candidate who says “I am stuck” gets the answer handed over, and the round is now about something else.

How much of a senior round is the coding?

Roughly a third of the clock, and less than a third of the decision. Junior rounds end when the code works. Senior rounds treat the working solution as the start of the conversation and spend the last block on what changes when the input gets bigger, arrives as a stream, will not fit in memory, or has to be served to other people. That block is usually what the write-up is about, and you only reach it if the first four run on habit.