Time complexity of Hash table lookup
If the hash function takes the whole string into account, then the hash calculation takes $\Omega(k)$ time where $k$ is the length of the string. So the hash table lookup takes $\Omega(k)$ time.

The hash table lookup takes $\Theta(k)$ time if the hash calculation is done in linear time in the length of its input, which is typical for hash functions, and the lookup of the value takes $O(k)$ time. That part is usually not the case. With a typical hash table, looking up the bucket for the hash value in the table takes constant time $O(1)$ with respect to the length of the string $k$ and the size of the hash table $n$. But that's not the end of the lookup.

If the bucket is empty, the value is absent and the lookup ends there, having consumed $\Theta(k)$ time. If the bucket contains a value, you need to be compare it with the string that you're looking up, and that takes $O(k)$ time. If the value in the bucket is equal to the value that you're looking up, the lookup ends there, having consumed $\Theta(k)$ time. But what if the value is different? What happens next depends on the variant of the hash table data structure.


In a variant where collisions are handled by growing the hash table until there are no more collisions, the lookup ends here and the cost of the lookup is indeed $\Theta(k)$. This variant has efficient lookup, but pays for it by making addition potentially very expensive (depending on the growing strategy when a collision happens).
In a variant where collisions are handled by putting the value in the next bucket (for some traversal strategy), the search can potentially cover the whole table, with one string comparison for each bucket. The worst-case cost of each string comparison is $\Theta(k)$ (with a typical string comparison algorithm, the worst case is reached if the strings have the same length and differ towards the end). In the worst case, the total cost of the search is therefore $O(k \cdot n)$.
In a variant where collisions are handled by storing values that land in the same bucket in a secondary lookup structure (such as a list, a hash table with a different hash function, or a search tree), the cost depends on what the secondary data structure is. It's unlikely to be $O(1)$ with respect to the number of values in the bucket, so the worst-case cost of the lookup is not $O(k)$.


Hash tables only have constant-time operations in the average case with some “reasonable” (or not) hypotheses over the data, not in the worst case. See also (When) is hash table lookup O(1)?