# Code Style - Your code contains a few lines that accomplish nothing and obfuscate your intent: else: continue If the conditional is false, you'll automatically `continue` on the next iteration without having to tell the program to do that. return None All Python functions implicitly `return None`, so there's nothing gained in explicitly typing this out. - `num_lst = list(range(len(nums)))` effectively generates a list of all the indices in the `nums` input list. Then, you immediately `enumerate` this list, which produces pairs of identical indices `indx, num`. If all you're attempting to do is iterate, this is significant obfuscation; simply call `enumerate` directly on `nums` to produce index-element tuples: def twoSum(self, nums, target): for i, num in enumerate(nums): for j in range(i + 1, len(nums)): if num + nums[j] == target: return [i, j] This makes the intent much clearer: there are no duplicate variables with different names representing the same thing. It also saves unnecessary space and overhead associated with creating a list from a range. - Following on the previous item, `indx, num` and `num_lst` are confusing variable names, especially when they're all actually indices (which are technically numbers). # Efficiency - This code is inefficient, running in quadratic time, or O(n<sup>2</sup>). I'm surprised Leetcode permits this to pass. The reason for this is the nested loop; for every element in your list, you iterate over every other element to draw comparisons. A linear solution should finish in ~65 ms, while this takes ~4400 ms. Here is a clean, efficient solution that runs in O(n) time: hist = {} for i, n in enumerate(nums): if target - n in hist: return [hist[target - n], i] hist[n] = i How does this work? The magic of hashing. The dictionary `hist` offers instant O(1) lookup time. Whenever we visit a new element in `nums`, we check to see if its sum complement is in the dictionary; else, we store it in the dictionary as a `num => index` pair. This is the classic time-space tradeoff: the quadratic solution is slow but space efficient, while this solution takes more space but gains a huge boost in speed. In almost every case, choose speed over space. - Be wary of list slicing; it's often a hidden linear performance hit. What you're doing here appears safe, because Python should know not to copy the entire list from `num_lst[indx+1:]` onward, but it's worth avoiding if possible. Removing this slice as the nested loop code above illustrates doesn't improve the quadratic time complexity, but it does reduce overhead.