• 0 <= nums.length <= 10⁵
• -10⁹ <= nums[i] <= 10⁹
• -10⁹ <= target <= 10⁹

Before the algorithm, get a clear picture of the thing we are searching. An array is a row of values stored side by side, and every position in that row has a number called its index. Indexes count from 0, not from 1: in the array [12, 45, 7, 23], the value 12 sits at index 0 and the value 23 sits at index 3. The problem asks for an index because an index is an address — once you have it, you (or any later piece of code) can jump straight to that element. And because 0 is the smallest real position, the number -1 can never point at an element — which is exactly why it is the traditional signal for "not found": it can never be confused with a real answer.

The array is unsorted: its values sit in no particular order, so nothing about them hints at where the target might be. It could be first, last, anywhere in the middle — or absent entirely. Suppose we tried to be clever and skipped some position to save time. That skipped position could be exactly where the target lives, and we would wrongly answer -1. On unsorted data there is no information that lets us rule out any position without looking at it. That leaves one honest strategy, the linear scan: start at index 0 and check the elements one by one. The moment we see the target, we stop and return that index — we were asked for the first occurrence, so nothing that comes later can change the answer. But we are only allowed to conclude "not found" after checking the very last element, because until then the target could still be hiding in an unchecked spot.

for i in range(len(nums)):    # i takes the positions 0, 1, 2, ... up to the last index
    if nums[i] == target:     # is the value stored at position i the one we want?
        return i              # yes — stop immediately and report the position
return -1                     # the loop ran out of elements: target is absent

A few words on the code itself, since this is our first algorithm. len(nums) is the number of elements in the array, and range(len(nums)) produces the sequence of positions 0, 1, 2, and so on — so i visits every index in order. nums[i] reads the value stored at position i, and == asks whether two values are equal. return ends the function on the spot, which is what gives us the early stop: the instant a match is found, no further elements are examined. The final return -1 line is only ever reached when the loop finished without a single match — meaning every value was checked.

Let's count comparisons instead of guessing about speed. If the array holds N elements, the best case is a single comparison (the target sits at index 0) and the worst case is N comparisons (the target sits at the very end, or is missing). Here is the observation that matters: if the array doubles in length, the worst-case work also doubles. The work grows in direct proportion to N. Computer scientists write this as O(N) — read it "order N" — and call it linear time. The notation deliberately ignores details like how fast your computer is; it captures only how the effort scales as the input grows, which is what lets us compare algorithms fairly. You will see this notation on every problem from here on.

The linear scan is the baseline that every faster search technique is measured against. Faster methods all answer the question "how can we avoid looking at everything?" — and each pays a price for that right: binary search demands the data be sorted first, and a hash map spends extra memory to remember where things are. When the data is unsorted and you have no extra structure, the linear scan is not a naive choice — it is provably the best you can do. Saying exactly that in an interview ("the input is unsorted, so a single O(N) scan is optimal here") shows you know why, not just how.