Lately I've been reading a lot of advice regarding coding structure that suggested to draw class interactions and write pseudo-code or comments explaining what you're going to do before starting actual coding. Since it's something I've never personally found useful, I'm kind of curious to know if there's a common preference here.

To explain better what I mean, I once worked with a guy who wrote whole functions in comments before writing the actual code, like in the sample below:

int fibonacci(int x) {
    // If x < 0 throw an exception
    // If x is 0 or 1 return 1
    // Return sum of fibonacci(x-1) and fibonacci(x-2)
}

His comments were probably less code-like than mine, though.

I understand that we people are wired differently from one another and for some it's easier to think first in a more natural language and then translate it to code and others think better in code than in natural language, but I want to ask, do you guys use this kind of techniques? Why do you find them useful or not useful?

No, i don't write pseudo code.
However I implement something that baerly runs very quickly, and after that I reason about the API and the code that I've just wrote.
This is my philosophy.

I once worked with a guy who wrote whole functions in comments before writing the actual code, like in the sample below

I've seen it, and there is only one thing I dislike about it when I see it. Usually I'm grateful for it.

I've seen many times where it makes sense to document the algorithm being used, or to provide an easy-to-read description of something that may not be obvious, or occasionally to state something like "This is an implementation of such-and-such paper from SIGGRAPH, a copy should be in this folder."

That last one is particularly nice. I may look at a function and have no idea initially what it is doing, but the link to the research paper with a good description of the algorithm and the reason for the choice, that helps a ton.

I've seen comments like that noting that the code was like that as a hacky fix to bug 4723. I've seen comments that apologized to everyone in the future for the implementation but the designer and producer is firm that it must be a certain way.

I've seen comments with a warning that doing it some simpler way doesn't work for certain reasons. I've seen comments warning that before changes were made to a function developers should check with the team lead (or former team lead) and to profile before and after due to performance concerns.

And I've written a comments like all of those above. When the comment relates to other parts of code, often I'll put the date on the comment so the maintainer can figure out how fresh or stale the comment is.

Many times the comments are useful. Remember that while the code needs to work for the computer, it needs to be understood to everyone who comes by later (including your future self) who maintains or extends the code. What may seem obvious to you when you are writing the code may not be obvious to a maintainer who is trying to change it months later. Sometimes that person is yourself, thinking "I remember this was needed for a good reason, but I don't remember exactly why."

I don't have a problem with it as long as the comment matches the code.

The moment they get out of sync, that's when I don't like it. And unfortunately, it is easy for the two to fall out of sync.

I'll often spell out a set of tricky if conditions as comments first, then fill in the code.

// If we foo has bar, then we need to do this

// else we need to add bizzbuzz

I then go and replace those with code, sometimes I keep a comment on the if, if it's not readily apparent. If it's some chained clauses, it can be easier to read the comment to understand what is being tested for.

I rarely use pseudocode for writing code. Typically, I diagram things out at a coarse level and jot down requirements, both project-driven and personal, for the code. Then I write a minimal working solution that fits the requirements and uses the diagram and iterate from there.

Where I do use pseudocode a lot is in debugging, or changing the way existing code works. I'll often reduce the code down to pseudocode to try to reason about the flow of a program, particularly if that flow is really complicated.