@ExErvus

Using a game engine does not just involve "drag and drop". If you want to create complicated gameplay systems, you can't do that without writing gameplay code. There can be a huge amount of programming work that goes into writing the actual game on top of the game engine. Companies hire gamplay and A.I programmers and most of the time do not require that these programmers have knowledge of engine architecture, graphics, sound or physics. Not one job posting even for a game engine developer requires that the applicant has created their own engine. Actually its better to create smaller projects that showcase knowledge of graphics or physics than to write a full game engine that involves a lot of mundane uninteresting work. I think a lot of programmers started writing their own engines (me included) a few years ago back when engines such as UE4 and Unity weren't available or as appealing as they are now. They then developed knowledge of how to create game engines and refuse out of pride (ego) to use a third party solution for their personal projects. What ends up happening is that they try to create a game with their own engine which is far inferior to the third party solutions and the game either never gets released or when it does, it pales in comparison to what it could have been if created with a third party solution. So many indie developers are looking for people that have experience with Unity to work on the client part of their game. Companies looking for engine programmers usually require that they have already worked on x amount of shipped titles. With the number of companies using Unity and UE4 now, its more beneficial to have experience working with those engines for getting into the industry. Many engine programmers become so after joining a company as a general programmer and gaining experience working on a game engine over time.

Large portions of this thread unfortunately devolved into a debate about whether you should build games or build engines. I'm going to try and take a more direct stab at answering your question.

You can absolutely be successful with Unity, CryEngine, or any other technology stack that you want to use. Before talking specifically about your Unity experience, I would echo the sentiment that overspecializing in a currently vogue technology is dangerous; nothing stays current forever. With that said...

I played with unity made a small game and it is really easy, I mean so much easy.

This is the wrong way to look at the problem. With personal projects, your goal should never be to just spit out a game; your goal should be to become a better developer. If developing your game was exceptionally easy, you probably finished it pretty quickly. In that case... spend some more time just playing with the technology.

Did you evaluate UI tools? Could you apply multi-threading to improve your user experience? How does your application handle memory pressure... and can you do anything to reduce or eliminate the probable hitches associated with garbage collection? What do your load times look like? How would you profile your load times, and determine options for reducing them? If you had multiple content creators working within this infrastructure, what steps could you take to help them work effectively together within Unity's monolithic "scene" model?

These are just a few of the places in which Unity has not historically been spectacular. Being able to say "I built a game in Unity" is great. Being able to talk about what problems you encountered and how you overcame them is much, much better. If you encountered no problems, you probably didn't learn anything either. If you didn't learn anything, why should a potential employer care that you built it?

Again, don't think about personal projects in terms of spitting out a result. Think about them in terms of bettering yourself. With every new project, strive to learn at least one thing that you didn't already understand. The rest will take care of itself... regardless of what tech stack you were using at the time.

Quite simply, your ability to finish is the most important part of the equation. I for instance would hire someone who has something to show me but doesn't know Unity specifically than someone who "knows Unity" but can't really show me tangable (and half way decent) proof of that. It's easy to start, but ability to finish is the real goal regardless of how it was made.