>I am really struggling with getting my foot through the door, as there is the typical catch 22 scenario, "We can't take you on board as you do not have Production centric experience"
How many applications and feelers are you sending out? The vast majority of companies are either unwilling to risk hiring a junior developer, or don't have the on-boarding and infrastructure to make use of them. With excellent set-up, you should still expect to see fewer than one in twenty companies get back to you. The application game sucks, but it's how you find the companies that can hire junior developers.
Where in the interviewing pipeline are you getting this? The best course of action is very dependent on where you're getting rejected.
My model of the pipeline:
1. Initial contact
2. Phone screen
3. Technical or coding challenge
4. On-site interview
5. Offer & salary negotiations
So, there's five different pieces of advice:
1. If you've sent out a hundred resumes and have gotten zero phone screens, I recommend working on your resume and on-paper skills. The good news is that a hundred applications like that takes 5-10 hours depending on skill and organization. Advice: make a couple small open-source web applications, and put them on the very top of your resume.
2. If you've gotten five phone screens and no technical challenges or on-sites, I recommend brushing up on self-presentation skills. Figure out a quick, one-minute story to tell about who you are and why you're an awesome self-taught programmer. Also, you could check how you're talking about yourself, and try to find areas where you're convincing people to not hire you. Self deprecating talk about lack of production experience is playing defense, not offense. Your job is offense, not defense.
3. Coding challenges are basically something you can cram for. There's programming competitions to get domain-specific expertise here. I don't have good advice since this is personally an area of natural strength. Project Euler is awesome and a great fit for Python. Challenges are a mix of live shared-editor with voice and offline ones. The shared-editor stuff is higher value since there's more commitment on their end.
4. Expect to fail the first one to four on-site interviews. The good news is that getting the first on-site is the most difficult. Anxiety, comfort levels, and lots of 'soft' skills go into interviewing well. You improve at this best by interviewing badly. Cracking the Coding Interview is a good book to use to improve here. If you have or can form a social group for this, that's even better.
On-site interviews roughly look like "put candidate in room, have someone come in and give them a whiteboard problem like something from Cracking the Coding Interview, repeat three to five times." The more you can make your practice look like this, the better. I'm talking down to wearing interview clothes, keeping the practice-interviewees in the same room and rotating interviewers, etc.
5. Don't worry about negotiation too much at this stage. If you must, I have some very general advice. First, ask for more time to make a decision - try for two weeks. Do not mention a number first. The only thing you need to say live is something like "that's a very interesting offer, let me think on it and get back to you." Do all negotiation over email or in rounds. Try to get multiple offers at the same time. Accepting an offer from the first company that gives you one is usually a mistake. (Why? Because someone who can get one offer can likely get three or more, there's a large variance in fit and compensation, and you want to accept the best offer so far. Plus, as long as you don't burn bridges, companies that have extended you an offer are willing to talk again later.)
tl;dr - Do you have projects and a good resume? If so, how many applications are you sending out?