Guan Yijun brought remote internships back to a basic student question: what should an internship give you? Location affects daily life, but contact with real engineering, cooperation, and demonstrable skills determine its longer-term value.
Guan spoke as a student intern in a recording published on March 8, 2023; the event date has not been confirmed. His year at university, roles, hiring conditions, and pandemic-related arrangements refer to that period.
An internship is more than making a feature work
Guan had three internships with some remote work. The first began remotely and moved into an office. The second was wholly remote in a smaller team. The third was remote temporarily because public-health and travel conditions kept him from going to Beijing. He corrected the host’s description of “three remote jobs”: treating them all as fully remote would obscure why he could compare the two modes of working.
He also contributed to open source, allowing him to compare company work with a public software community. First, an internship puts technology learned at school into a real setting. Frontend engineering includes pipelines, deployment, infrastructure, load balancing, and cooperation with product, design, and backend colleagues. It does not end when a local development command starts a page.
The next question is what the intern contributed within that system. Guan connected the internship, resume, and interview: actual work creates evidence; the resume identifies the contribution; the interview explains the process and judgment. “I used a framework” names a tool, not the problem the candidate solved.
From completing a task to identifying and proving value
Guan borrowed the contemporary campus-hiring vocabulary of ordinary offers, SP, and SSP to describe levels of contribution as he saw them. This was his own analogy, not a formal company scoring scheme or a formula that converts one project into a particular offer.
The baseline is dependable delivery. A mentor asks for a marquee or another component; the intern uses the team’s engineering tools and ships it on time. That is real work and an introduction to the infrastructure. But in an interview, “I did what I was assigned” says little about whether the candidate can notice an unassigned problem.
One step further is a specialty that can be explained in depth: performance work, Node.js and BFF, scaffolding, build plugins, visualization, and similar areas. The value is not another word on a resume. It is being able to explain the principles and improve a situation when that specialty is needed.
Guan used server-side rendering as an example. A business dashboard may show an unsatisfactory measure. An intern could investigate the reason, change the implementation, and use before-and-after data to show the effect. “I know SSR” only describes exposure; finding a cost the business is bearing and explaining why the intervention works demonstrates initiative and judgment.
His second example concerned build-cache cost. A developer in another team noticed that a service charged per frontend developer and that the monthly bill grew with team size. The developer moved the cache capability to private infrastructure and could then explain the saving to the department. Guan extended the example to BFF machines: if a fixed number of instances run all the time while demand rises and falls, could the system scale with load? That was a proposed improvement, not a completed claim. It showed the habit he wanted students to acquire: inspect recurring cost, discuss it with the responsible person, and own a change whose effect can be checked. The amounts quoted in the talk were illustrative and were not an independently audited cost study.
He also separated value from influence. First solve a real team problem. Then document its conditions and implementation so others can reuse it. Writing can expand the reach of a solution, but an article does not replace an actual improvement in cost, performance, or cooperation.
Information sources and explanation are part of preparation
Guan advised against spending all spare time on recycled interview questions. He followed developer newsletters and technical-team writing to see what problems others were solving. A newsletter introduced him to a young open-source project in which he later contributed. The point was not to chase every new term but to find a tractable problem one could help deliver.
He also thought ahead to the next interview. During an internship, record the original problem, one’s own action, trade-offs, and result. Put only the part one truly owned on the resume. An interview lasts a short time, so prepare a clear account of how the work created value. His casual expression about “talking up” work did not mean claiming someone else’s achievement.
Why he preferred an office internship when he had a choice
The choice is first constrained by courses, school rules, location, and, at the time, public-health conditions. Guan did not advise an impossible move for someone who could only take one form of internship. When both were available, he personally preferred the office for two reasons.
The first was practicing human communication. He had been somewhat shy before his first office internship. Working with colleagues showed him that he sometimes explained things poorly or behaved awkwardly in a discussion. An internship gave him a place to notice and correct those habits before taking on a more permanent role. That is his reason for preferring in-person experience, not proof that remote interns cannot learn to communicate.
The second was asking questions and learning the business. In a previous team he messaged a colleague assigned to help him and got slow replies. He wondered whether his questions were too basic. Once they met in person, he found the colleague warm and willing to explain, often adding useful background. For example, the placement of an analytics event might take several messages and a wait to clarify online, while pointing at the page and code can lead to an immediate one-sentence explanation. The delay reflected the medium and circumstances, not hostility.
Asked about adding a remote job on top of an office internship, he prioritized growth. If the extra role merely brought short-term pay but displaced study and attention to the main job, it might undermine later prospects. That was a student’s personal trade-off; another person’s financial pressure could justify a different choice.
Finding a remote internship and understanding the actual role
Frontend remote internships were hard to find in his experience. He separated when to search from where to search. Remote work reduced the need to move near an office, so a prepared student could apply outside one fixed seasonal window if courses and hours allowed. His first interview lead came through Boss Zhipin; a later remote Web3 internship came through someone he knew. He also tried internship platforms but got fewer replies. These are historical experiences, not current counts of open roles or a guarantee of year-round hiring.
The more important check is what the intern must own. A startup without a stable office or a large frontend team may expect one intern to set up the frontend engineering, build pages, and coordinate with backend, product, and design. That sounds flexible but can require considerable independence. Other “remote” internships consist mostly of small miscellaneous tasks. Ask who mentors the intern, how code is reviewed, and where responsibility begins and ends. The application still involves a resume, interviews, and mutual fit.
Building project experience without an internship
Guan suggested two alternatives when neither remote nor office internships are available: a training program in which one really works on a team project, and sustained open-source contribution. Enrolling in a program is not itself experience; the value depends on the team’s actual work. Open-source discussion, code, and documentation can leave public evidence of technical ability. Programs named in the recording were opportunities from that time, and their current availability needs checking.
Students often open the Vue or React repositories first, see the scale, and retreat. Guan said one need not begin with the largest framework. A young project can be easier to understand and may let a newcomer discuss a bounded module directly with its creator. A mature project may have small, well-defined tasks. Both are more promising than choosing only by a project’s reputation.
Two concrete entry points are issues and discussions. Look for user requests, whether a maintainer accepted them, and planned features. Verify the task is still open, read the relevant code, state an intention to help, and submit a pull request. During the presentation, Guan showed a feature-request issue in Ant Design asking for a component property. It had been solved between preparing the talk and presenting it. That change in status illustrates why a contributor must check the current thread instead of acting on a week-old task list. A small property can still require understanding and changing the component correctly.
He also used a documentation-site framework in which he had contributed. A discussion may describe a feature desired for a coming version; he could pick one understandable piece, read its code, make a small change, and discuss the PR. His earliest contribution involved passing a configuration or property down to the right layer. The diff was not enormous, but it took him through the complete participation cycle.
Another route is to compare a tool one uses with a similar project such as VitePress. A missing capability may be worth proposing and implementing, but it must fit the project’s direction. Copying every feature from a competitor is not automatically useful contribution.
Remote life: flexibility requires planning
Guan liked the ability to exercise, spend time with family or pets, and study between tasks. He imagined starting with a run, shower, and breakfast before concentrating on work. If a task scheduled for ten days was complete in three, he would rather use some remaining time to improve his skills than sit in an office merely to appear busy. Product and operations changes still needed attention. This describes the rhythm he hoped for; it does not grant an automatic seven-day leave under every team’s agreement.
He also experienced the opposite: from 8 a.m. to 10 p.m. he felt as though he was at work, not because every task took fourteen hours, but because he failed to concentrate work into defined periods and let it interrupt the rest of the day. Remote work gives more control over time and more responsibility for keeping a schedule. For a student, that cost sits alongside fewer chances to watch colleagues, ask a mentor in person, and practice face-to-face communication.
Audience questions: distinguish the experience and prepare for interviews
Were all three roles purely remote? No. One began remotely and moved on site; the next was wholly online; the third was temporarily remote because of conditions at the time. Without those constraints he would have liked to visit the office in Beijing, experience the team culture, and speak with colleagues directly.
Was a remote-role interview special? Guan had not interviewed at a company designed exclusively for overseas remote work. In the interviews he knew, fundamentals, frameworks, projects, and sometimes algorithms remained central. His answer cannot describe every cross-border team’s selection process.
What changed between first and later internships? For a first internship, he expected questions on frontend basics, Vue or React, build tools, and computer networking. With experience, interviewers could dig further into previous project decisions and one’s actual contribution, while algorithms might still appear. Memorized answers are not enough; a candidate has to explain tools used, code written, and choices made.