I think attitude is the first thing. There have been a lot of decisions made already in the project that you didn't have a chance to give input to. Likely you will disagree with some or even most of them. The last stages of a project is not usually the best time to revisit decisions made months ago and that a lot of the code depends on, so pick your battles carefully. You don't want to make enemies from day one. This is similar to coming in on a legacy project, when you come in late in the game. You don't understand everything about why they made the choices they made, so wait a bit, get some credibility from your own competence and then start suggesting changes in order of importance. Don't do it days before a critical deadline either.
Document problems you found with the approach so you can prove the issue in the next project that you are on from the start. Often having details about what turned out to be a mistake makes it easier to sell a different way later on.
Next big problem is getting up to speed fast enough to be of use. Especially towards the end of a project, people just don't have time to help you get up to speed.
So spend the first couple of days building a list of questions as you look through the code and then talk to a senior developer (or team lead if the person is technical) about your questions in one swoop rather than bother them continually for several days. You will have to ask some things immdeiately of course, you can't look through the code if you don't know where to find it. But try to be somewhat independent in figuring things out.
They will likely assign you to a specific area to work in, make it your business to read the requirements (if you have a requirements document) and look at the code in that area first. Once you think you understand it or know you are stuck in understanding it, then go talk to someone about it. Confirm that your understanding is correct and ask your questions. But above all don't ask the questions in such a way that makes the person feel as if you regard their code as garbage even if (maybe even espeically if) you do. If something feels off to you, ask why they did something not "how could you have done that?" Try to understand their thinking and decision making processes not just their code.
If coming in at the end of a project is discouraging (and let's face it they wouldn't be hiring near the end if they didn't have problems) keep in mind that you will be there for the beginning of the next project and have a chance to have more input. Your job, career-wise, is to do a good enough job on what they assign you to gain credibility for the being a significant player in the decision making process on the next project. So do your best to be a team player, to meet deadlines and to provide working code that plays well with what has already been finished. Now is the time to impress them with your abilty to get things done. You can impress them with your brilliance later.