It's hard to help without knowing what languages you work with and what kind of feedback you're getting.

Are your solutions overbuilt? Poorly documented? Introducing new patterns where they aren't needed?

The biggest clue I've got to work with is:

> I refer to stack overflow or ask my colleagues if I get stuck on some design / technology feature which I haven't seen before.

I'm searching up the problem as many ways as I can before I even get started. Even if I think I know how to do something, there could be a better way to do it.

> the rush to complete the deliverable on time

If you're rushing, you're doing something wrong. Here's a secret: it's way more important to be reliable than it is to be fast. Who's setting the deadlines? Is there a way you can squeeze more time? A lot of junior devs underestimate things habitually.