I can offer two ideas here. The first is to try, whenever possible, to use some real world metaphor for the technical problem at hand. Railway sidings, card shuffling, etc. Some instructors use these as a matter of course in introducing a new algorithmic concept.
But if you want a thorough study of how to approach and develop algorithms, get a copy of:
David Gries, The Science of Programming
The book will change how you think about algorithms and how they are developed. One of the key ideas is algorithm development from loop-invariants along with pre- and post-conditions. There is a science (hence the name) of modifying post-conditions in order to develop a loop and its invariant.
One of the magical problems in the book is a linear time sort of an arbitrary array that contains only three distinct values (Dutch National Flag). It generalizes to a linear time sort of an array containing a finite number of distinct values. [1]
But as a TA, if you are familiar with the technique as described in the book, you can guide a beginner by working with the student to find the pre- and post-conditions, expressing them logically and then looking at formally weaker statements to guide the algorithm development. Note that the classic sorts, for example, all have identical pre- and post-conditions. The different algorithms arise from the various ways in which a logic statement can be weakened.
Note: if P -> Q the P is "stronger" and P is "weaker". So, a post-condition for a sort might include that the array A[0:n] is sorted. A weaker statement is that A[0:k], k <=n, is sorted. Combined with other statements, this can lead to a well defined loop and its exit condition.
So, it isn't a bunch of discrete tricks, but a methodical approach to developing the algorithms. The "tricks" are consequences of the technique, not the technique itself.
Both of the suggestions here are to give students a way to think about the problem, rather than to just reveal a "trick". You may be able to think of other ways to achieve the same end.
This book has been mentioned in several other answers on this site. A local search for "Gries" will turn up some additional ideas. I was lucky enough to have been taught this by David himself.
[1] For those requiring more explanation, the array can be of any length, but the values contained in it come from a set of three values, often {red, white, and blue}. This implies, of course that while there are only three distinct values in the array, they are repeated. The sort is to bring all of the red values together at the start of the array, and the blue values to the end. The algorithm runs in linear time as a function of the size of the array. The sort is not stable, in that entries of the same value may be exchanged. So, a white value to the "left" of another white value at the start might wind up to the "right" of it at the end. The sort is linear in "time" as mentioned above. It is also linear in comparisons between values and linear in exchanges. If you double the length of the array you (roughly) double the time, the number of comparisons, and the number of exchanges.
I suggest that you try to develop the algorithm using invariants and post-conditions as explained in the book, rather than just finding it online and reading it. (It is an exercise in the book, actually). You will learn something important. The algorithm is effectively a single scan of the array (hence linearity), but not the scan you normally see. That is the magic.