I'm going to guess that you've most likely used dependency injection without even thinking about it. It's one of those things you naturally do because it makes sense, even if you don't know it has an actual name, frameworks, and all that other stuff that often only makes it more confusing.
I would say you are a bad programmer for implying that DI is useless though.
My philosophy of programming is "there's no right way to do it, do what works for you and makes you happy and if someone tell you you're doing it wrong, pay no attention - they're a bully and a fool".
Or like a pilot doesn't get a job because they flew a slightly older Airbus model and need to do some sim time.
Writing tests for nearly all my code, in particular, is these days the only way I roll - and as for TDD (i.e. write the test and let it fail first, then write the actual code and make the test pass), I do it quite often, and I guarantee you that - contrary to your opinion - it makes coding a whole new kind of fun and creative. Dependency injection I still consider myself less of a ninja at, but I've done it (and seen it done) enough times now that I get it and I see the value in it.
I think it's a bit stupid for an employer to say "we'd never have hired you if we knew you had no experience in X" (sure, this doesn't apply to all skills, but I'd say it applies to quite a few). If you're worth hiring, then you'll pick up X within a few months on the job. I'm grateful to several past employers of mine, for showing me the ropes of TDD and DI (among many other things).
Anyway, I'm not saying that the above things are "the (only) right way to do it", and please don't take my above ramblings as making a judgement on your coding prowess. I agree, do what works for you. I'm just saying that there's always more to learn, and that you should always strive to be open-minded to new skills and new approaches.
It's too complicated of a term for what it is because we generally don't say we inject arguments into a function when we call a function.
But maybe you mean patterns building on that, e.g. repository/adapter patterns.
The value of tests doesn't generally come from when you first write them. It comes from when you're working on a codebase written by someone else (who has long ago quit, or been fired).
It helps me understand and be able to refactor their code. It gives me the confidence to routinely ship something to production and know that it won't break.