How to ask for help in PM

Revision en6, by -is-this-fft-, 2021-04-08 13:33:21

There was a blog today with a similar title, and although it was (I think, not really sure as I didn't get a good look) some kind of satire/joke blog, I wanted to post some serious advice about things I (don't) like to see when people are PMing me. However I decided that this wouldn't be in the spirit of the blog and decided to make a separate blog. And now that blog is deleted anyway.

While it's not a bad thing to write messages to more experienced users, most people who write me do things that make them very difficult to deal with. These are my opinions, but somewhy I feel that many reds will agree. Some things here feel silly to write because they are so obvious. But I'm only writing them because people regularly mess them up.

Use punctuation and spelling.

There are some very simple rules that make your messages infinitely more readable. I find it especially strange when many of these messagers call me "sir", which is supposed to show respect, but then write like this. Is this how you write to someone you respect? Do you write to your teachers or boss like that?

Don't be pushy.

The worst case was when someone contacted me by email, and 20 minutes later sent another message "please reply ??". Think about it like this: you are writing someone who you don't know, who you don't have any previous agreement with and whose job is not to reply to you. I think you aren't automatically entitled to a reply at all. And although I try to reply to most messages, I think it's very rude to expect them to reply in less than a day or even two. Replying to you is not anyone's top priority.

Don't overstay your welcome.

A big reason why I'm wary of responding to PMs is that many people treat this as an invitation to ask 1000 more questions. Of course it's normal to have some followup questions and maybe write again another time, but there comes a point where you just being to annoy. You should understand when that moment comes and stop before.

Don't ask people to debug your code.

I will send the following template message if you get WA/RE:

Have you tried the following:

  • Write a very naive and simple solution to the problem (maybe exponential complexity) (if you can, you may also just copy someone else's solution)
  • Write a program to generate thousands of small (!) test cases
  • Using those two, find a test case where your program gives the wrong answer
  • Use print statements or a debugger to see where exactly your program does the wrong thing.

98% of WAs and REs can be resolved this way. I don't have time to delve into every code I'm sent, it's much harder to debug somebody else's code and being able to debug your own code is a valuable skill. It is also a very routine process that can be learned much faster than problem solving and algorithms.

And if you get TLE, make sure before writing that:

  • you know what complexity is and
  • you read/print input efficiently (sync_with_stdio and friends).

On that note, by the way: cin.tie(NULL) is useful but cout.tie(NULL) doesn't do anything.

Don't go in over your head

This section feels somewhat controversial to write, but I have some bad experience from the past with people who have asked help understanding some advanced tutorials. I accepted but every time it became evident after some time that the person did not yet have the capacity to understand this advanced algorithm or DS.

There is some amount of mathematical/algorithmical maturity needed to understand some complex things. (I don't think that you must have a high rating to understand, after all many top computer scientists haven't even heard of CP, but real understanding of simpler things is required). Moreover, you can not expect complex tutorials to hold a beginners hand and explain everything in such basic terms that anyone will understand. Mathematics (and the kind of CS we do here is basically mathematics) is cumulative and builds upon itself. Abstract stuff requires experience with concrete stuff, complex algorithms use many simple algorithms as subroutines. And you should be able to read some quite dry or terse mathematical text without someone showing you "what this intuitively means" at every little step.

About asking for help in a specific problem

If you ask for solutions or hints for some specific problem, be prepared to send a link. There are two reasons for this.

  1. I don't want you to help you cheat. Asking for solutions in an ongoing solution is cheating. And some of you may not realize it, but so is all other discussion: asking for hints, asking to debug and asking for "general ways to approach problems of this type" (whatever that means). By sending the link, you prove that you're not trying to do any of these things.
  2. I'm being blunt here, but a lot of you suck at retelling problems. For example, many beginners haven't developed a sense of what information is important. There are countless examples of CF blogs where some green asked for help in a seemingly impossible problem until finally it turns out that the author had left out a crucial detail. See below for more.

Of course, it is not always possible to send a problem link. If that is the case, I will probably wait a bit before answering — if the contest is short, there's a good chance that it will be over when I reply. And if you do retell the problem, keep in mind the following:

  • Try to write the problem as closely as in the original problem. If you are inexperienced, don't try to "simplify" the problem because there is a good chance you will fail. It's probably okay to remove the non-mathematical part of the problem like "Vanya found an array in the left pocket" but leave the mathematical part of the problem as it is.
  • Constraints are very important and a part of the problem. For example, there might be a problem where $$$n \le 10^3$$$ allows for a simple DP while $$$n \le 10^{18}$$$ requires some complex algorithms and a lot of creative thinking. Before I start thinking, I want to know whether you are satisfied with the simple DP (that takes me a few minutes) or need the complex algorithm (that might take a few days and may not exist at all).
    • This also goes for "hidden" constraints. If the problem says that there is a grid of lowercase English letters, don't say "there is a grid of some values" because the fact that there are only 26 distinct values may be important.
    • Small constraints are especially important! If $$$n \le 20$$$, we can use all kinds of exponential solutions that would be impossible otherwise.
    • Of course, there is some value for asking what the "best complexity" is. But thinking about that is a bigger investment in time. And even then it's a good idea to outline what you have already come up with.
  • If there is some strange condition in the problem, definitely include it. Problemsetters tend to not write random things and if there is something like that in the problem, there is a good chance that it is important.
  • If the time limit is not close to 2 seconds, that's also important information.

Speak in a language the receiver will understand

It's surprising but I have received a number of messages in languages I don't understand. Now of course you can't really know, but use common sense here. For example, my profile will tell you where I live. If I don't live anywhere near Bangladesh and don't even have a South Asian name, what is the probability that I can understand your message in what I think is Bengali? Same goes for any other language.

Thoughts some common questions

  • "Please give me some guidance" I have no idea what to answer. If you have some specific question, write.
  • "Should I sort by number of solves or by difficulty?" Please understand that there is no consensus or real science on "how CP should be practiced". Furthermore, such questions likely have very little effect on your practice.
  • "How many minutes before looking at the editorial" I will say "until you have solved it". I will also point out that many strong contestants have conflicting views and thus I think it's not the most important thing.
  • "Can you give me some resources" If you ask something specific, maybe I have something good. But 99% of the time I will just send links to and
  • "The resources you sent are too hard" See the part about going in over your head. Also I don't know what you expected but some people expect resources where you don't need to think to understand. This is an unrealistic expectation.
  • "How do you approach problems like X" In high school algebra and calculus you often have well defined recipes that tell you how to solve every problem (of some specific kind) ever. I suspect some people think this applies to CP as well. It doesn't. Most of the time, there is no "standard first step" that you do, you just have to think. But if you have enough experience, many problems have solutions that become obvious immediately.
  • "Can you be my mentor" No.

In general I must say (this is about me though, not necessarily other reds) that I'm much more likely to be able to answer technical questions (specifics of some problem, solution, algorithm...) than "career" questions ("how to practice" and similar). If you have a question in the latter category, it may be a good idea to write to someone else.

Concluding words

Unfortunately I don't think this is going to have a big effect because many of these people who write PMs are beginners who aren't going to see this blog. It would be a really cool feature if I could set some kind of "status" that is visible at the "send message" panel.


  Rev. Lang. By When Δ Comment
en7 English -is-this-fft- 2022-04-21 14:31:49 14 Tiny change: 'em up.\n\n####Us' -> 'em up.\n\n[cut]\n$~$\n\n####Us'
en6 English -is-this-fft- 2021-04-08 13:33:21 2875
en5 English -is-this-fft- 2020-12-06 06:58:44 350
en4 English -is-this-fft- 2020-10-21 16:39:11 466
en3 English -is-this-fft- 2020-10-14 00:57:03 34 Tiny change: 'diately.\n\n####C' -> 'diately.\n- **"Can you be my mentor"** No.\n\n####C'
en2 English -is-this-fft- 2020-10-13 23:04:32 7120 (published)
en1 English -is-this-fft- 2020-10-13 22:19:39 1722 Initial revision (saved to drafts)