I've noticed on my team the developers are very busy toward the beginning of the sprint with the QA people having little to do, while the opposite is true toward the end of the sprint.

This seems inefficient... is there any way to smooth it out?
['https://pm.stackexchange.com/questions/32922', 'https://pm.stackexchange.com', 'https://pm.stackexchange.com/users/597/']
It sounds like you are doing something very common in teams - a 2-week waterfall project. Things likely move from some requirements conversations before the sprint or in the early days of it to coding, then QA at the end. There are a few things you can do to change this up which will also have the impact of smoothing out workload:

1. Smaller pieces of work. Break things down into small features that can be designed, coded, and tested in 2 - 3 days. Lessons learned many decades ago from Lean: small batches lead to better flow.
2. Test-first development. Using techniques like TDD and BDD (as examples) can bring a lot of the testing early in the process instead of later. (this doesn't completely eliminate exploratory testing btw). This also really helps with...
3. Invest in test automation. Unit tests, integration tests, automated acceptance tests. This is all part of the build it process. Also, this requires both the coders and testers to work together. The testers are good at knowing what to test and the developers can help automate them and build the application to be more easily testable. This also gives you a large suite of regression tests that make it easier and safer to do #1.
One key is cross-training to reduce the skill gap between QA and SW engineers. That is, train developers to do some low-level testing, and testers some low-level development work. In fact, a big-data presentation I saw all the way back in 2014 at Agile World showed the best-performing teams did not have separate disciplines.

This echoes some of the other answers, but the process that has worked well for my teams includes these generic tasks for each development user story:

1. Write the test case, if one doesn't exist (QA, or dev in easier
cases).
2. Develop (Dev) || Automate new test case, or conduct break/UX testing of existing code (QA).
3. Unit test (Dev).
4. "Second set of eyes" testing (QA, or different Dev from step 3's).
5. Acceptance test (Customer or Product Owner).

Good luck--Jim