Brace wrapping to limit the scope of lim to the pertinent area. I would normally throw that into the for loop (see next bulletpoint) but here the compiler can take advantage of its const attribute and optimize.
Moving j into the first for declaration prevents it from being generated and destroyed (automatic storage class) each i loop.
Unsigned because we are not interested in negative numbers.
Prefix operator can be faster.
Setting i to the limit is effective here, but I would prefer a boolean flag if this were a general case, since it would fail on lim = std::numeric_limits<int type>::max(), where it would roll over to 0 or std::numeric_limits<int type>::min() on the increment, making the mathematics undefined and liable to hurt someone. However, the true sin is the use of <=. Any time you have a foo <= or >= bar in a foor loop, you risk having an all foo is true situation. Sanitize your limit so it must be in the data type's range and that lim is not a useful value of your incrementer. If that cannot be done, for example you may want to run all uint8_t values from 0 to 255, you'll need something else to catch the end condition, such as incrementing a uint16_t and testing & 0x100).

A few things:
1) Limiting the scope of variables is good. However, don't do it for performance reasons (your compiler can see that you aren't using it elsewhere).
2) The cost of creating/destroying an automatic variable without a constructor/destructor is zero.
3) Unsigned operations are the same speed as signed operations on every platform ever
4) ++i will compile to the same thing as i++ if you aren't actually making use of the return value.

I don't want to be the person that is always saying "just let your compiler do it, it is smarter than you", because I don't believe that is true (a significant part of my work now is hand compiling stuff that compilers do a sucky job of). But doing tiny tweaks that could be done automatically by a computer program is a waste of your time.
The example is a bit contrived, so this ends up looking fairly verbose for something that doesn't do much. But this is how I would approach it:

_________________
Trying is the first step towards failure
b

I guess the only real way to make it pretty is to write an extra search function, which is sad.

If you templatized find_position then you could do stuff with functors and lambda, like find_position(DELAY(GetPosition, _1, 2) == 3) so you can write the conditions where you use them... I think there HAS to be a more elegant solution, though.

More functions = more fun.

Seriously, what's the problem with more functions? (assuming they can be given sensible names - which is the case here)

_________________
Trying is the first step towards failure
b

It depends on what you're doing with them. If you're just writing simple search code for every single type of data container you have you'd think there'd be a way to generalize, saving time/effort/bugs. Simple lambda functions also look better for simple conditions, imo.

Here's a better solution -

1) Limiting the scope of variables is good. However, don't do it for performance reasons (your compiler can see that you aren't using it elsewhere).
That's fine, I'm doing it so I don't try to use it elsewhere.

2) The cost of creating/destroying an automatic variable without a constructor/destructor is zero.
But the code might be put into a template and then fed an object. I'll do it right the first time.

3) Unsigned operations are the same speed as signed operations on every platform ever
Not a speed thing. Negative values are undefined here so a signed type is inappropriate.

4) ++i will compile to the same thing as i++ if you aren't actually making use of the return value.
Of course, but same as #2, I'll do it right the first time.

"But doing tiny tweaks that could be done automatically by a computer program is a waste of your time."

And that is why we learn to code the optimal line when we first write it! Imagine a program written by some poor, poor newbie, "it's just a tiny tweak, a waste of time" through thousands of sub-optimal lines.

Suddenly, I try to open a word processor on a multi-core 3.4GHz system and it takes many times longer than WordPad did on a 0.1GHz Pentium 1. PROGRESS!

Even a nanosecond is huge if you have a billion +1ns suboptimal lines of code being called.