The reason I was asking what data type was used on the SQL side is that date and datetime are formatted in a standard way no matter how the date was sent over. For example, if you store 01/20/2020 as a "date" type, it is still stored as 2020-01-20 in SQL.
However, the fact that any of your queries worked in testing suggests that they're being stored as string values (not necessarily best practice), but that would be why the "LIKE" queries worked at any point.
Second, "LIKE" is not a partial comparison by default, you need a % symbol to act as a wildcard for it to work the way you expect and that was missing from your second round of tests.
For example,
'3/10/2020' LIKE '3/10/2020' -> TRUE
'3/10' LIKE '3/10/2020' -> FALSE
'3/10%' LIKE '3/10/2020 -> TRUE
Note that in your original screenshots the % is added to the end of the "HireDay" Token itself, but you did not have it in there when you tested 3/10.
Try testing '3/10%' instead of '3/10' and see if you get different results.
Also, I'd recommend adding the % in the query, not in the token value, that way it is easier to notice it should be there.
You could add it to the end of the "parameter values" or you could build it into the query itself so there's no way to forget it even in testing, like so,
WHERE [HIRE DATE] LIKE CONCAT(@today,'%')
Then your Parameter Value for @today would just be %(HireDay) and you could remove the extra % at the end when setting the HireDay token.