When you walk in the door, you’ve got what it takes to stay in the company. You just have to show that you have what it takes to stay.
I have had a brief internship in netease, wechat and Ali. Now I have received a few offers, but I will probably stay in Ali (I can’t afford a house in Beijing or Shenzhen, so I have to come to Hangzhou).
To be honest, from students to workers, from school to the company, from independent developers to team development is a big different, the original poster also suffer from most of the articles are talking about interview skills and the brush topic guide (funny, delicious), of course, these along with your school is to enter the threshold of the company, but how to finish transition into the team, is the foundation of you. (Perhaps this chart below will illustrate the change.)
So, I summarized my internship experience and my final job as a full-time employee, and made a few points that I think are more important. Of course, they are all humble opinions, and you can judge them by the good (maybe none) and the bad (maybe all).
Section1. Before induction
As it is a team work, you need to learn the basic skills of being part of a team before entering the internship:
- Use your IDE proficiently: my job is Xcode, for example
- Understand the use of common debugging tools such as Charles, iHost, Chrome Dev Tools, etc
- Code tools: Git or sourceTree etc. (Skilled use of tools can greatly improve your work efficiency)
- Your own productivity tools: Xmind, Keynote, Pages, etc
- (Optional) Some generic tools: Aone, JIRA, etc. (These depend on the company, but the flow is similar)
Section2. What you need to do in the first week:
- Get a clear understanding of the products and modules that your group is responsible for. You can directly get input from the tutor for this part, and directly work on this module, which can save you a lot of time. After all, a product is too big for a 2-month internship cycle. This can be seen from your weekly reports, what modules you are responsible for and the weekly workload.
- Learn the technical picture of the team and understand the module owner.
- Set up your project environment, and complete the project independently according to the instructions of GitLab and team documents. There will be permission approval and other things in this process. Record in time to prevent confusion. In fact, the level and learning ability of an intern can be seen in the process of running the project. Do not ask at the beginning, but first solve the block and then ask.
- If you can’t solve the problem with the reference document, remember to update your document as soon as possible so that the new person behind you can also show your new person’s quality.
- Plan with your mentor as soon as possible what you want to do next. It should be challenging, productive, experiential, and valuable to the business. Or your final interning defense will be tough. Of course, it’s better to be able to get data online. After all, without data, it’s just a personal fantasy, and not convincing to executives.
Section3. Start moving bricks
I think that part of it depends on the job description, but there are some principles that guide it:
1. Owner Your module is represented by:
- Serious and responsible: your code must be easy to maintain, easy to expand, reject bad code, after all, there is code review. You can refer to the code specification of the group and the code specification of the internal students. Everyone has the same code style. This will reduce the time for code review and improve the goodwill of your classmates in the group. After all, most interns’ code habits are somewhat different from the team.
- Active optimization: This part is a supplement to PD. After all, PD is not the implementer, and he will definitely be negligent. However, when we really implement it, all details and logic will be covered
- Focus on data: have a good understanding of the calculation method of buried data, and know how the value behind the business is reflected in data.
2. Priority:
We will be wrangling about various things every day. I suggest that we prioritize things according to the latitude of time nodes and cost estimation, and try to control the granularity of things well so as to be orderly and not delay the project.
3. Admit mistakes and reflect on them:
The mistakes you make during your internship are the cheapest you’ll ever get into the company, so don’t waste the opportunity.
- When you encounter a problem, your first reaction is not to blame, and certainly not to take the blame. When you’re wrong, you’re wrong. Admit it. Don’t say, “No one told me and I didn’t know.”
- It is inevitable for interns to step on holes. Of course, holes within the acceptable range are acceptable to the team, but the same problem should not be repeated. After each step on holes, we need to reflect on it in time. Put an end to it.
- Don’t panic when you have bugs. Don’t try to hide bugs. If there are no bugs, you are either too good or your modules are too simple
4. Communication:
Swallow what you want to say first, filter it through your brain and then express it. The content should be concise, concise, persuasive and expressive. Everyone’s time is precious, don’t waste others’ time, choose some comfortable points to communicate with each other:
- 20 minutes at the end of the day
- Use your lunch hour
- Summarize the non-urgent questions together and send them to senior students or senior students by nail or email. They will answer them after work
- Any other way to make each other “comfortable.
5. Refused to:
There are some things that you should refuse. As the business develops, the original implementation must be updated. For example, the patch should be made on the service side.
- If design itself is unreasonable originally, that should be unreasonable that party undertakes modification.
- A unilateral revision is better than a bilateral one.
- For the long term.
6. Don’t brag:
For corporate projects, don’t sacrifice stability and maintainability for the sake of technology and blindly pursuing new technologies. This is not to write inefficient code, but to improve performance as long as stability and maintainability are satisfied. You write a bug online, basically your leader helps you recite… Your leader doesn’t have time to help you read code line by line, and some holes are invisible.
7. Set up a reference:
Last year’s school enrollment and this year’s interns are your reference, not to encourage the bad atmosphere of comparing, but let you urge yourself, after all, people are lazy, there is no reference is terrible.
8. Program Review:
When you receive the requirements, first design one or more of the architecture, and then go to your mentor to determine the plan, this will avoid one-way input, but also can correct many of your own cognitive errors. Don’t ask for solutions without thinking. You’ll be looked down on because everyone’s time is precious. And don’t try to determine if it makes sense after you’ve done it… Otherwise, even if you refactor your own code, it will blow you up.
In the end, this may not be a guide, nor the north, because each of us is different individuals, it may point to the north, south, east, west, and ultimately decide you are your own choice, I wish you all can successfully get their own satisfactory offer, goodbye ~
