I was disappointed that they disallow the use of external libraries, but then criticise C++ code that is vulnerable to the obvious integer overflow. In a real interview, I would expect a good candidate to indicate that they would pull in a bignum library to avoid this, but there is no way to say that in this sort of test. Likewise, depending on the exact specifications, you might consider using a 64-bit integer type to hold the sum, but that's not portable yet. Presumably, if you're limited to standard C++ (which has no bignum library) and required to pass the overflow test to get a top score, the only way to do this is to reimplement the relevant parts of a bignum type. Of course, that is exactly the wrong thing to do if you have to solve this sort of problem in reality.
It is particularly unfortunate that they would criticise a candidate's code for this, while at the same time making a basic mistake themselves in the specification for the equi function. (If, as the problem states, there may be many elements in the input, then the correct return type for an index into a std::vector<int> would be a std::vector<int>::size_type, not an int. A size_type is always unsigned, so returning -1 in the event of finding no match is a bad idea.)
Compiler output:
wrapper.java:23: not a statement
for(int i =0; i++; i<A.length())
^