As the class you TA is a programming class, I'll suggest two options I've used - that have worked well for me (after Googling Stack Overflow and Github of course). Both these options start by asking conversational questions ("How are you doing? Are you enjoying class?") to help relax the student - when talking about the code in the next part hesitations and mistakes can be used as an indicator for a lack of knowledge but not if it is just nerves.
Option 1: better for mid-level to advance classes: Look at their coding before hand, make sure you have some notes on their coding style, preferred methods, and level of knowledge. Then select one of their programs and ask them to write out on paper/chalkboard/whiteboard some code that solves a similar problem. Let them know that you don't expect error-free code and that if they can't remember an exact method to just use something close (depending on the class pseudo-code may be acceptable). The point is that a person who has done the assignment should come up with something that follows the basic logic and coding style that was seen in their assignments - if it is way off you know they likely did not write it themselves - many times leading me to start option 2 with them.
Option 2: I would honestly use 2 or 3 assignments for this method. As it is easier to see if the progression makes sense this way (a person does not typically go from if/else to building generators and decision trees in the span of a class or two*) and it gives more material to discuss.
Starting with one of the programs, I would then ask very open-ended questions about how the student came up with their solution. You want to avoid fact questions as your trying to see the knowledge and thought process not just a memorization of quiz answers. You can ask follow-up questions here but keep them limited and still open ("can you explain that more", "why did you use that particular method", "did you try anything else"). Your looking for a few things here:
Someone who wrote the code for themselves should flow through the conversation naturally - without having to pause and think about their answers as often.
The student should be able to explain each method. If it is a complex method they may get lost or make a few minor mistakes - but they should be able to explain all the concepts.
The thought process they describe should make sense. This should include both the method used and the reasoning for using that method: "I decided on a for loop over the dictionary keys as that just seemed more elegant and easier to maintain then the massive if/elif/else statements".
I'm probably missing a few here, but the point is that your experience and knowledge will usually make it pretty obvious if someone actually wrote the code or not based on just how they explain it.
* I had one student who did just this. Turns out he had been programming for a few years and was picking up the language at a much faster pace.
