Chain of Responsibility Design pattern in C++
Design Pattern Comments
It works as a chain of responsibility (and the point of patterns is that they are not exact and are chained depending on exact need).
BUT saying that I think you could have done it better in this situation.

Your descent of the the chain is manual and repeated in any every class.
This should be automated in the base class. Each derived class should simply perform the action that you wan them too.
This will remove programmer error when a new developer creates a chaining task.
Your creation of the chain elements is not consistent. It would be easier to have a setTask() method then force every new task to join the chain rather than force every class to have a boiler plate constructor (that can be done incorrectly).
You do not always want to chain all the way to the end.
On of the handlers should be able to say I have done the final processing stop searching the chain.
No memory management (but that was covered by @Mantosh Jumar).
Also note using smart pointers helps you with another design pattern (Separation of Concerns).

I would have started like this:
class HelpInterface
{
        // Private virtual function.
        // You don't want it called directly as it just does the action
        // None of the chaining.
        virtual bool getHelp(int iHelpConstant) = 0;
        // Note it returns bool.
        // true indicates I have done it all.
        // Do not activate any more tasks in the chain.
        // false indicates try the next item in the chain.


        // Always have a next pointer in all HelpInterface
        std::unique_ptr&lt;HelpInterface&gt;   next;

    public:

        // Need  virtual destructor to make sure memory management is done
        // done correctly. As elements are destroyed via a pointer to the 
        // base class.
        virtual ~HelpInterface() {}

        // Chain the getHelp.
        // But stop if it returns true (or we are the last element
        // in the chain.
        void activateHelp(int iHelpConstant)
        {
            if (!getHelp(iHelpConstant) &amp;&amp; next)
            {
                next-&gt;activateHelp(iHelpConstant);
            }
        }

        void setNextTask(std::unique_ptr&lt;HelpInterface&gt;&amp;&amp; nextElement)
        {
            next = std::move(nextElement);
        }

};

Now you can create the chain like this:
int main()
{
    std::unique_ptr&lt;HelpInterface&gt; app    = std::make_unique&lt;Application&gt;();
    std::unique_ptr&lt;HelpInterface&gt; ilayer = std::make_unique&lt;IntermediateLayer&gt;();
    std::unique_ptr&lt;HelpInterface&gt; fend   = std::make_unique&lt;FrontEnd&gt;();


    iLayer-&gt;setNextTask(std::move(app));
    fend-&gt;setNextTask(std::move(iLayer));


    fend-&gt;getHelp(GENERAL_HELP);
    fend-&gt;getHelp(INTERMEDIATE_LAYER_HELP);
}

General Coding comments
A tiny bit lazy here.
using std::cout;
using std::endl;

But these are used so often I will not complain. I would have preferred it if you had not polluted the global namespace for everybody (in this file).
All caps identifier are by tradition reserved for macros. Macros have no regard for scope so you are putting yourself in a dangerous position using all caps for constants.
const int FRONT_END_HELP = 0;
const int INTERMEDIATE_LAYER_HELP = 1;
const int GENERAL_HELP = 2;

Also could have used an enumerate. I personally would have done.
enum HelperTypes { FrontEndHelp, IntermediateLayerHelp, GeneralHelp};

Doing it this way, makes the compiler generate the actual numbers (so there is no chance that somebody accidentally puts two identical numbers into the list). Also if you change your getHelp() signature to use the enum people can not accidentally pass an integer, as the compiler will spot that and force them to use the correct type.
A base class with virtual members. Must usually have a virtual destructor.
class HelpInterface
{
protected :
    HelpInterface * Successor;
public:
    virtual void getHelp(int iHelpConstant) = 0;
};

Also in C++ never us RAW pointers (there are some exceptions). But RAW pointers do not convey ownership. If you don't know the ownership then you don't know who is responsible for deleting the object. One of the most important concepts in C++ (over C) is the concept of ownership (RAII being more important). We should always know who owns a pointer so we know who is going to clean it up. Smart pointers are the usuall technique of indicating ownership (or using references to indicate the passing of a reference with no ownership transfer).
The * is part of the type. So put the * by the type when declaring pointers.
 HelpInterface*     successor;   // object (anything you can get an address of)
                                 // this includes functions. Should have an
                                 // initial lower case letter.

 // User defined types have an initial uppercase letter.
 // This helps you distinguish Types from objects.

You use at least two different styles of bracing:
class HelpInterface
{                                       // Brace on the next line.
 
class FrontEnd : public HelpInterface { // Brace on the same line.

Pick one and be consistent.
Note: You can use different styles in different places.
class X
{                 // Style for classes.

    int func() {  // Style for code.
        
    }
};

Personally I always put the '{' on a new line by itself. Others find this wastes vertical space. I buy a big monitor and keep my functions relatively short.
Use default parameters to avoid this situation.
        FrontEnd(HelpInterface * s){ Successor = s;}
        FrontEnd(){ Successor = NULL;}

Can be replaced with:
        FrontEnd(HelpInterface* successor = nullptr)
            : successor(successor) // Note:  member and parameter name the same.
        {}

You have plenty of space between operators here:
    if (FRONT_END_HELP == iHelpConstant)    {

But here they are all packed together. Space is your frined use it.
        cout&lt;&lt;&quot;This is the front end, don't you like it ?\n&quot;&lt;&lt;endl;

Don't use std::endl unless you want to force a flush. This is rarely the case. std::cin and std::cout are linked. If user input is required the cout is automatically flushed so the user can see any questions (or output). Excessive flushing severly degrades performance.
The most hidious of things ever:
    system(&quot;Pause&quot;);

Stop using it.
Try.
    std::cout &lt;&lt; &quot;Hit Enter to continue\n&quot;;
    std::string line;
    std::getline(std::cin, line);

This is portable.