Best advice I can give you is that programming is programming. I've worked all over the place (literally and figuratively): scientific, embedded, real time, shrink wrapped software, enterprise, web development. There isn't a lot of difference, to be honest.<p>The key thing to understand is that programming is 5% "getting it to work" and 95% "expressing what you are doing in a way that others can extend". Most people, when they are at the beginning of their career, have enough to worry about just making the code work. It's easy to get an anti-climax once you get over that hump, though.<p>Even doing work in real time or other resource constrained systems, you will discover that algorithm design and optimisation are secondary because in a big software system you often can't get there from here. You have some terrible mess and it seems infeasible to refactor it in a way to even apply those optimisations.<p>Anyway, having said all that, I'll say that embedded work <i>is</i> mainstream :-). I have a hard time thinking of stuff that <i>isn't</i> mainstream. By numbers, the vast majority of programmers work on internal business systems -- many of which are far older than the web. So I would remove that notion that "mainstream == web development". Programming is programming.<p>Being self taught is not so much of a worry these days. I don't really pay much attention to it when hiring people. I will say, though, that companies with an engineering background often like to hire people with engineering degrees first and will begrudgingly hire people with CS degrees. It's often hard to break into those companies without a STEM degree. Having a good CV helps a lot.<p>As I have done it many times, I will say that it is challenging to hop over domains. If you are a web developer, then people often tag you as a "web developer". If you are an enterprise Java developer, then people tag you as an enterprise "Java developer". It's up to you to display a flexible mind and show that you are a generalist programmer that can pick up whatever tools they throw at you in short order. I've literally lost track of the number of programming languages I've used professionally (probably somewhere between 10 and 20), not to mention libraries and frameworks. When I go to an interview I explicitly tell people, "If you want someone who is an expert in X and who knows all of the tricks for using X, then you probably should look for someone else. If you want a solid programmer who is going to help you get your code base in order, then I'm your guy." Sometimes it is a short interview ;-) (which is good for both of us).<p>Finally, one last piece of advice. When you work for someone, you do what they need done. Sometimes that corresponds with what you currently want to do, sometimes it doesn't. If you want to develop yourself in a particular area, <i>you</i> have to invest in yourself. That means a side project. For some parts of your career (even myself right at this moment!) that means doing katas, and exploring ideas. For others that will mean starting a project and grinding it through. While there is no harm in interviewing for jobs, I would encourage you to spend most of your time exploring the kind of programming you want to do -- by writing your own code. Having done that, you will be <i>very</i> much more valuable to the people looking for that kind of programmer. It is true that lots of people in the field that you will want to get jobs in will not care about that work -- but, trust me, you don't want those jobs.<p>Good luck!