I'll go over your post point by point for the sake of clarity. You didn't mention the country, but I'm hoping that, while my input comes from a US perspective, you'll be able to apply the principles and main ideas to your particular context. Also, I'm assuming that this is a full-time employee and not someone in an internship, although many interns do transition over to full-time employees, so maybe this distinction doesn't matter that much.
I am a young professional with around six months of software engineering experience now. I work with a young girl who is writing her bachelors thesis in my company.
Congrats. It might be a good idea to start referring to her as a woman, not a "girl". Usually, people entering a bachelors degree are already adults, and I'd expect someone who appears to be close to graduation to also be an adult. Therefore, treat her as an adult from the get-go.
By treating her as an adult, you'll do your part in treating her as an equal, in the sense of respect and so on. Presumably, she earned her position at your company and it was not "given away" to her for "free" for knowing the "right" person... so, reminding her about that fact could go a long way.
Rather than feeling sad for not already knowing things no reasonable person expects her to know anyway (she's an undergrad, after all), she should simply be encouraged to rise to the occasion and make sure she's aware that that's what's expected of her. Pity doesn't get anyone too far.
Your company should consider a mentorship program, if it doesn't have one already. A program like this allows a more experienced co-worker to become someone else's "mentor" in a more official capacity, much like a guide.
We get along well, and I always see a sad mood in her face whenever she has to face criticism.
I don't think anyone is happy about facing criticism, but you don't mention what kind of criticism she's facing. Is this a personal matter or is it simply about code reviews?
For example, as software engineers, we tend to review (and should review) each other's code. If this is the case (and if it's not, then just take it as an example), then this is a good/common practice and she (anyone, really) will need to get used to that. A few reasons include:
- This is one way in which we improve the quality of the code --this is a code review, not personal review;
- This is another way in which she'll be able to learn from those who have more experience;
In short, the key here is realizing a few things:
- Reviewing code is not equivalent to evaluating you as a human being;
- This is a very good learning opportunity and she should take advantage of it to improve her knowledge (she can always ask why the team wants solution A instead of B) and advance her career;
If the criticism she's getting is from employee evaluations, then, while I can sympathize with her, there might not be much that can be done, depending on the situation and context.
She thinks that she is not performing well enough and is doubting that the job as a software engineer is fitting for her, while I think she does good and just needs some more time.
While I'm not a behavioral expert or the like, some have mentioned the "Impostor Syndrome", to which I can relate. There's simply too much to know and it can get overwhelming quickly. This is normal.
I think she may also need to realize, and accept that, as someone who hasn't even graduated yet, she will need more time and effort to acquire the added knowledge and experience that then translates into better individual performance. And even then, if her personal standard is very high, then it's something she may need to learn how to live with and handle.
(This is my case and is what some of my friends tell me, so I just learned how to be aware of it and handle it better. And this is coming from someone with 10+ years in the industry as a software engineer.)
I told her several times now that she has nothing to worry and this isn't something to learn in just two weeks.
In my experience, and that of some of my co-workers, depending on the complexity of the environment/systems/etc, it can take several months and even a bit over a year to get a good-enough grasp of things to become reasonably effective and proficient at your job. This is how it is for us average individuals and the amount of complexity in today's systems. Also, software engineering is difficult; it's not something that's learned and done perfectly overnight. It takes a significant amount of time and effort. Help her be aware of this fact.
In the same way that it may come as a shock to some students that college is very different to high school, especially if they used to be straight-A students but couldn't maintain that in college due to increased difficulty, as an undergrad, she may be running into a similar situation with the corporate environment and may simply need to realize that she needs more time to overcome it.
Also, while it doesn't sound like this, could it be that the corporate environment itself was very disappointing to her and not at all what she expected? This might be worth talking about. Many years ago, I had been hired as a Firmware Engineer, but spent roughly the 1.2 years defining and writing test cases for testing firmware --not writing code. Needless to say, I was upset for a while until I got a chance to jump and do programming work. It might be worth talking about her expectations and reality, in a way that she knows will not affect the outcome of her career negatively or anything.
She should realize that, while two weeks are usually good enough for a fairly complicated homework, the systems used in corporate environments are generally a lot more complex than that.
In the same way she knows, by personal experience, that she can't fit her entire Bachelor's Degree into two weeks, she must understand that she won't be able to fit a corporate environment into her brain within the first two weeks, either.
Understanding that reality is what it is, and not necessarily what we'd like it to be, might be a good first step here.