What are the main problems your interns usually face in their work? I guess theoretical knowledge is not a problem, so what bothers them the most in a practical sense?
One of the roughest parts of the transition from the classroom to the workforce is the realization of how elusive good code can be. In a learning environment, all the examples are well-defined and neatly contained; very little of the natural weirdness of real-world software projects leaks into that safe little sandbox.
The second difficulty they encounter is in moving from the essentially micro-managed environment of the classroom to the somewhat self-managed environment of the workplace. While interns have access to myself and the rest of the staff if they have any questions, and while I meet with them 1-on-1 regularly, the responsibility for asking for help rests solely on them. They are assigned a task in a real project, and must figure out how to complete it. Having that much autonomy is often a shock to the system if all you've ever known of coding was the undergrad college environment.
I have a saying for myself: It is better to let someone dig themselves out of their own hole, than for them to have to dig themselves out of a hole I dug for them. Typically, it's easier to recover from, and learn from, a disaster of one's own making, rather than the results of bad management advice.
Incidentally, the difference between a successful intern and one who doesn't complete the program often comes down to whether they can ask for help. That approach is necessary if they're going to learn to make it in the industry, and it's one of the reasons why our internship graduates have made such a smooth transition into full-time development jobs elsewhere.
The third difficulty is ironically in understanding the concept of a "need-to-know" basis. In college, you can usually see the purpose of an assignment right off the bat, but in the workplace, you may not fully understand the depths of a project, or why your piece is needed.
I answer some of those questions, but I don't spell out all the logic behind my decisions, partly because the individual wouldn't be able to handle it all, and partly because one has to learn how to let go of understanding many things "above their paygrade" (often just for purposes one's own personal sanity!)
Going hand-in-hand with that is in learning to respect the autonomy of other coworkers as well. Collaborating and providing feedback without micromanaging or meddling can be a difficult balance, especially when "group projects" are one's only exposure to teams.
And then there's the good old-fashioned "learning how to take directions." No further comment necessary on that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What are the main problems your interns usually face in their work? I guess theoretical knowledge is not a problem, so what bothers them the most in a practical sense?
One of the roughest parts of the transition from the classroom to the workforce is the realization of how elusive good code can be. In a learning environment, all the examples are well-defined and neatly contained; very little of the natural weirdness of real-world software projects leaks into that safe little sandbox.
This is one of the reasons I have all new hires read Dreaming in Code by Scott Rosenberg.
The second difficulty they encounter is in moving from the essentially micro-managed environment of the classroom to the somewhat self-managed environment of the workplace. While interns have access to myself and the rest of the staff if they have any questions, and while I meet with them 1-on-1 regularly, the responsibility for asking for help rests solely on them. They are assigned a task in a real project, and must figure out how to complete it. Having that much autonomy is often a shock to the system if all you've ever known of coding was the undergrad college environment.
I have a saying for myself: It is better to let someone dig themselves out of their own hole, than for them to have to dig themselves out of a hole I dug for them. Typically, it's easier to recover from, and learn from, a disaster of one's own making, rather than the results of bad management advice.
Incidentally, the difference between a successful intern and one who doesn't complete the program often comes down to whether they can ask for help. That approach is necessary if they're going to learn to make it in the industry, and it's one of the reasons why our internship graduates have made such a smooth transition into full-time development jobs elsewhere.
The third difficulty is ironically in understanding the concept of a "need-to-know" basis. In college, you can usually see the purpose of an assignment right off the bat, but in the workplace, you may not fully understand the depths of a project, or why your piece is needed.
I answer some of those questions, but I don't spell out all the logic behind my decisions, partly because the individual wouldn't be able to handle it all, and partly because one has to learn how to let go of understanding many things "above their paygrade" (often just for purposes one's own personal sanity!)
Going hand-in-hand with that is in learning to respect the autonomy of other coworkers as well. Collaborating and providing feedback without micromanaging or meddling can be a difficult balance, especially when "group projects" are one's only exposure to teams.
And then there's the good old-fashioned "learning how to take directions." No further comment necessary on that.