The term "Middleware developer" is not what people talk about. They talk about "game development", which includes middleware development, they are not two separate, exclusive fields anymore.
Your missing my point, those two things go hand in hand and as I already stated, is much more valuable to be well versed in both, more so the latter because it is generally a more difficult technical skill to acquire that talks years of discipline.
As you pointed out earlier, this is a forum for people wishing to break in.
In order to write an effective reusable component (be it a key library, a tool, or an engine component), you need to be extensively familiar with the requirements. That is a level of seniority and experience which doesn't apply to someone entry level.
They are far better served by spending their time *using* an existing and solid framework to make actual games. If they ever do need to write their own engine (or be a key engineer writing an engine for an employer), they are much better served by having made games than they are by making toy engines.
I'm just saying, in a day and age where everyone creates a home-brewed engine of some sort and learns the knowledge required to do so, is much more desirable than familiarity with click/drag operations.
What you need to do to be a game developer is make games.
Back in the late 1990s, there was a game development channel on EFNet. Mostly aspiring game developers, and a handful of professionals.
And they would say "I am adding this to my engine" or "I am going to redo my engine to support that", and we would say, "Just make a game."
And they would talk more about the technology they would add to their engine.
A few years later, I wandered back in. Same people, mostly. Still talking about what they would add to their engine, still never having actually made a game.
If you want to be a game developer, make games.
If you want to be a middleware developer, make middleware.
Like Promit already pointed out, what engine you use does not matter. But here is my opinion, using tools does not make you a game developer. Anybody can pick up a set of tools and create something passable because somebody else has done all the hard work in creating those tools. Be that guy if you want a job and to be successful.
By implication, you would need to therefore write your own compiler, and OS, after first designing the CPU you intend to use.
Ive been programming for quite a while now but because of tough competition I wasnt able to get a programming jobs.
So, here is the thing.
Competition for jobs (especially entry level jobs) is insanely high in the game industry, because the labor market is flooded with entry level talent. So, lots of competition, low pay (relative to comparable jobs outside of games).
Outside of games, there are people getting really good jobs after doing programming bootcamps, or other non-degree programs, because the labor market is tilted in the other direction -- lots of jobs, not a lot of capable talent.
If you want to get in to professional programming, getting in via games is much much harder.
I have no faith that employers will make the right decision to recognize my skills and talents; I believe they will only see that I have not been paid to do web development, medical imaging, etc., and end the discussion there.
So, there isn't anything we can do here to change that.
I can tell you that there is a massive demand for programming talent -- to the point that bright people can do sub-1-year training bootcamps and get jobs. I can tell you that outside of the game industry there is a perception (accurate or not) that game programmers are *higher* skill than the industry norm. I can tell you that job "requirements" from employers are little more than wish lists in many cases.
I wish I could have received that advice 20 years ago. I can't imagine that employers will accept my existence at this age with so little applicable skill - transitioning now would require a far more forgiving environment that exists.
Programmers transfer out of the game industry all the time. I find it difficult to believe that a programmer with decades of experience has no transferable programming skills anywhere else in software.
I'm leary of advising anyone to use "concept artist" as a break in goal, because I don't ever recall working with someone who was purely a concept artist -- concept art was just one of the tasks an artist might be doing.
There is a balance between "dig into this yourself" and "ask an expert in house". If you spend a week trying to find the source code, you've clearly gone too far. If you ask a question about every function, you've gone too far in the other direction.
The problem is, this is a balance that people find *by* working in professional environments, it isn't something that gets taught in school, so far as I know.
This is why entry level engineers are basically a loss early on; a big part of the ramp up is how things work in a professional environment, not just "how we do things differently here". Better companies know this, and the manager will either mentor the engineer, or assign a mentor. Worse companies, well, leave you to sink or swim.
When you work on a project at a company, the results do not accurately display your own ability because you were part of a team frob. Everyone contributed. Having a portfolio is a means of isolating your own abilities and showing your own work, not the work of your teammates as a manifestation or extension of your own. I feel that your logic is unsound in your evaluation of potential candidates.
Except that when we hire people, we're hiring people to work on a team. Someone's ability to contribute effectively in a team environment is actually more important than what they do when they have absolute control and can do whatever they want on whatever schedule they want.
While a college degree certainly helps, your credentials aren't as important as being able to demonstrate that you can program. From what I can tell, assuming you are a decent programmer you're virtually guaranteed to find some sort of job in the US, as there is rabid demand for programmers over here.
OP is in Peru. To get a job in the US, OP would require a work visa. That is something that is going to be hard to get no matter what, it is significantly harder without a degree.
(The exception is an O-1 visa, but if you qualify for the O-1 visa, you don't need to be asking questions on a web forum)
Here is the dirty secret, and it applies to all of the tech sector, not just games.
Interviewing for talent is hard. Getting an idea of skills in the course of a day of interviews is *hard*.
Even looking at past performance (especially in games) is hard. Are they ready for the next project, or did that last game burn them out?
(Seriously, I have known people who would not hire people out of studios known for high crunch, because they had had too many cases of hiring people who were burned out. You had to go somewhere else first and prove you were ok, before they would consider you)
Whiteboarding questions aren't there to prove how good a programmer are, they are to weed out the people who can talk all the right talk but are inept.
There are all sorts of schools of thought on how to interview, and there are trainers out there touting methods for companies to use. People keep looking, because this is hard, and because the cost of a bad hire is high.