I will talk from the experience, but keep in mind that everyone is different. These things are not universal.
One thing is to let it go personally. This project is something you lived with and lived in for 18 months - you would naturally want every change to be like you would do it. Give a buffer for a colleague to make mistakes, to learn. Create a room for them to be useful. And keep in mind it might not happen right away. Also it would be great if there is something, a part of the code they can feel they succeed in improving or creating, that feels like success in a short period of time. Patience and tolerance has a good pay off rate here. Do not try to micromanage, and if you want to criticize, to say "you are wrong", make sure you have a merit, you can prove it, it is not a "religious" fight.
Another key issue is to find the right person for you. Ideally it is better to find someone smarter than yourself. It is subjective and relative, but if you feel a person has some knowledge and skills you don't have, it is for the best. It will be a mutually rewarding collaboration.
There are two ways it can go - the colleague will be a drag, and you will end up redoing what he or she did, or the skills of two of you will multiply, not just add up, and you will really appreciate working together.
On a topic of "clean, fast, reusable code" - I suggest on an interview, ask to write a small micro-kernel/service manager and/or job executor. See how pluggable components are specified and configured. Doesn't have to be finished, it is a thought that counts. And also you will quickly learn people who know well how to do it will want decent money ;-) Good luck!