This is a pretty reasonable start on a simple interpreter. Edward's suggestions are all good; a few additional suggestions:

----

    interpret("+++++++++++++[->....

Please break up that long line.  C allows you to break up literal strings

    "like "
    "this."

----

    void goToLoopEnd(char** ip) {
    ...
    void goToLoopStart(char** ip) {
    ...

If you wrote these instead as

    char * findLoopEnd(char* ip) {
    ...
    char * findLoopStart(char* ip) { 
    ...

then you have functions that are just as useful, but *do not modify the input and are therefore testable with an independent unit test*.

This also enables you to improve the contract of these methods; for example, you could return null if there is no matching bracket. Which then brings up...

----

Aside from that, my biggest problem with your interpreter is that it has undefined behaviours all over the place if the program is not valid. What happens if there is an unmatched `[`?  What happens if the pointer goes *before* available memory?  Bad stuff, that's what. **A good interpreter is safe no matter what its input, and gives good diagnostics to the user when the input is bad.**  Always structure an interpreter so that it detects bad inputs, because it *will* get bad inputs.

----

Once you have the undefined behaviours under control, consider the cost of doing a linear search for matching brackets all the time.  It is almost always more efficient to scan the source code *once*, make a note of the locations of all matching pairs of brackets, and then when you hit a bracket you just do a lookup of the destination rather than a linear search for it. Yes, a linear search is fast if the program is small, but the program might not be small.