There are hundred ways that you would have written any piece of code differently than your mentee. And if you correct all of them you will both be unhappy and unproductive. There are truly amazing coders who code differently than you or I. Focus on issues that materially affect the application(correctness, reliability, performance, security, reliability, maintainability - less important than the other) and give clear explanation of why you're making the critique and how it affects the application.
Also remember you're a team, and he wants the application to be awesome too. Approach critiques with "here's a way we can make the application faster" as opposed to "you wrote slow code".
Document every critique you make to create a code guidelines document. This will help anyone else who joins the teams, and will make your critiques feel less arbitrary, and help them remember and be able to lookup your critiques.
Make sure you have a standup every day to watch over their progress and code.
It's really easy to focus too much on getting your own work done and slack off as a tech lead or mentor. Always prioritize your mentee's work over your own. Don't start your work until you've set him up for success for the next few days. (code reviews, making sure he has work lined up and understands what he needs to accomplish and how he needs to accomplish it)
Maintain a positive attitude, remember to compliment them, err on the side of over complimenting than under complimenting.
Don't be afraid to ask for their advice or for them to do research.
Expect the quality to not be up to what it would be if you wrote it. Try to plan for this by increasing QA time, testing, and spending more time reviewing the parts of the applications where correctness is the most important. Also make sure to do performance testing in case he did something boneheaded.
Over communicate. Explain the why's of everything. There are 100 tech leads who under communicate for every tech lead who over-communicates. So chances are your team will run better if you communicate more.
>Over communicate. Explain the why's of everything.
I would like to second this, if your schedule allows it. Attempting to make sense of a large codebase (that likely has much domain-specific and even historical reasoning within) when you are inexperienced and/or new to the domain can be a much better experience if the information flows as freely as possible from the expert to the new person.
There are hundred ways that you would have written any piece of code differently than your mentee. And if you correct all of them you will both be unhappy and unproductive. There are truly amazing coders who code differently than you or I. Focus on issues that materially affect the application(correctness, reliability, performance, security, reliability, maintainability - less important than the other) and give clear explanation of why you're making the critique and how it affects the application.
Also remember you're a team, and he wants the application to be awesome too. Approach critiques with "here's a way we can make the application faster" as opposed to "you wrote slow code".
Document every critique you make to create a code guidelines document. This will help anyone else who joins the teams, and will make your critiques feel less arbitrary, and help them remember and be able to lookup your critiques.
Make sure you have a standup every day to watch over their progress and code.
It's really easy to focus too much on getting your own work done and slack off as a tech lead or mentor. Always prioritize your mentee's work over your own. Don't start your work until you've set him up for success for the next few days. (code reviews, making sure he has work lined up and understands what he needs to accomplish and how he needs to accomplish it)
Maintain a positive attitude, remember to compliment them, err on the side of over complimenting than under complimenting.
Don't be afraid to ask for their advice or for them to do research.
Expect the quality to not be up to what it would be if you wrote it. Try to plan for this by increasing QA time, testing, and spending more time reviewing the parts of the applications where correctness is the most important. Also make sure to do performance testing in case he did something boneheaded.
Over communicate. Explain the why's of everything. There are 100 tech leads who under communicate for every tech lead who over-communicates. So chances are your team will run better if you communicate more.