Sorry for the confusion.
I must admit I only skimmed through your post, and given the topic, I though it would be enough to link you to the article.
You already seem to have a proper fixedtime step loop, and to interpolate between your object's 2 last positions.
I inspected your code a bit better, and noticed you are moving your square (object) by one pixel every update.
In this case, the interpolation won't do any good, because if your screen can only display in 1 pixel increments, what is happening is that, in some frames, your object won't move at all (because until the delta reaches 0.5f, your object's position won't change by 1).
What I mean is, if the object's x coordinate is 400, and you're 40% on the way to the next update, it's interpolated position will be 400.4. But since, basically, you will only notice a difference, when the object moves by, at least 0.5 pixels (because it is rounded to 1), it will appear not to move.
Also, like Shaaringan said, the 2 pixels jump will also happen, probably, due to rounding/precision issues.
Basically, this is what I think might be responsible for the jittering.
Also notice, that the object moves properly when you don't use a fixedtime step, because you're always moving by 1 pixel and not interpolating between two positions separated by a single pixel.
The object won't always move at the same speed though, because should your loop run slower than normal, then your object will also slow down (one of the reasons you really should use one).
Again, sorry for the confusion.
That is one of several good ones. The bigger game engines with more comprehensive feature sets will interpolate what you see between the two simulation steps as describe.
Indeed. I find that as I get more experience coding, actual program/engine design becomes more and more of an issue, so it is really cool to see how the (much) more experience programmers do it.