English 英文
自我介绍与背景
Tell me about yourself
I'm Junhong, I'm in Shenzhen, and I've been doing front-end for about six years. I mainly use React and TypeScript, and I've used Vue and Next.js too. I was last at Insta360 on Antigravity, their drone brand, building the global store, checkout and ops console, across sixty-plus countries, nine languages and eleven currencies. And before that, two years at Baidu on an LLM platform. Thank you.
What is your tech stack, and what are you strongest at?
My main tools are React and TypeScript, and I'm fine with Vue and Next.js too. For builds I use Vite and Webpack, Jest for tests, and Sass or CSS Modules for styles. And where I'm strongest is the middle layer, so component libraries, shared style rules, shared tracking, and splitting a big app into parts that ship on their own. And I've built that at three companies now.
Why are you leaving your last company?
Well, the drone business at Insta360 got much smaller, so many teams were joined and many jobs were cut, and we agreed to end my contract. So I'm looking around now.
What are your greatest strengths?
I'd say two things. First, I own the whole path, not just my ticket, so if a checkout step is slow I just go fix it. And second, I care about reuse, so I built component libraries and docs that other teams actually picked up.
What is your biggest weakness?
I used to take on way too much myself. When time was short I'd just do it, and it felt fast, but then everyone had to wait for me. So now I write things down as I go, so how to use it, why we chose it, and I sit with people on work they will keep.
项目与经历
Walk me through a project you are most proud of
It's the order emails at Insta360. So each one had nine copies, and one word change meant nine edits. And I made one FreeMarker file, plus a tool that builds all nine. And we ended up with about 107 emails.
Tell me about the most challenging project you have worked on
The checkout at Insta360. So it looks simple, but the money rules are not. And it covers tax, coupons, points and trade-in, in sixty-plus countries. And I made it a state machine, so the steps stay clear. And then the money parts were easy to test.
Describe the architecture of the last system you worked on
There are three parts. The shop is Next.js, and it does SEO and buying. And the admin side is React. And a micro-frontend shell joins those apps, so each team ships alone. And both sides share components, tracking and login. And data comes from REST APIs.
What was your specific contribution versus the rest of the team?
My part was the buying flow and its state machine. And I also did the order and points screens. And I built the shared base too, so components, micro-frontend and tracking. And the backend owned the data. So twenty-plus areas could work the same way.
Tell me about something you built from zero to one
The Qianfan JS SDK at Baidu. So there was no official one, and I suggested it and built it. And it's one API for chat and streaming, in the browser and in Node. And if a call fails, the retry waits longer. And then I put it on npm.
How does your sprint work, and are you comfortable in an Agile team?
Yeah, I've done two-week sprints for years. So we plan, we pick what fits, and then we look back. And I like it because the work stays small. And if I'm stuck for two days, I say so early.
Tell me about a time you worked with legacy or messy code
At Tencent the component docs were old. And people just read the code instead. And I rebuilt the site on Docusaurus, and I added search. And it updated itself when components changed. And the hard part was twenty-plus docs, so I did them in small groups.
Tell me about a production issue you diagnosed and fixed
A new cookie tool logged people out. And I thought the login had run out, but the account service was fine. And its cookie list was empty at first, so it deleted the login cookie too. And I blocked that delete until the list was ready.
行为面
Tell me about a time you disagreed with a teammate
We had to upgrade locked dependencies for security fixes, and I wanted them in one release. And a teammate said the risk was too much for one go, and he was right, because locking versions makes the ones under them jump too. So we split it into four small groups.
Tell me about a time you pushed back on your manager
I was asked to promise a date for a checkout change that needed a tax service we hadn't connected yet. And I said I wasn't comfortable, and I explained what we didn't know, and I suggested we ship the parts that didn't need it. And he agreed.
Tell me about a failure or a mistake you made
I put thirty-one dependency locks in one merge request and shipped them together, and each looked safe. But the locks made ones under them jump, and one broke old code. And it only broke when it ran, so we went back. And now I do it in small groups.
Describe a time you were under a tight deadline
A sale had a fixed date and the promotion screens weren't done. And instead of longer hours I cut the work, so I agreed with the PM on the smallest set of screens that could run, and I moved the report screens to the next sprint. And we launched on time.
Tell me about a time you took ownership beyond your scope
Nobody owned front-end speed, so it came up only when users complained. And I measured the buying path with Core Web Vitals and turned it into a work list, so splitting code, smaller files and drawing only what's on screen. And it worked because I brought numbers, not opinions.
How do you handle conflicting priorities from different stakeholders?
I make the conflict easy to see instead of taking it all on myself. So I write down what each person needs, by when, and what it pushes out, then I get them into one talk. And most of the time they sort it out themselves. And if not, I bring a suggestion.
Tell me about a time you received critical feedback
A reviewer said my components were hard to reuse, because too many options only made sense to the person who wrote them. And that hurt, because I thought more options was the point. So I split the worst ones into a simple API, and now I write a use example first.
How do you handle unclear or changing requirements?
I first lock what is hard to change later, usually the data shape and the states, and I stay open on the rest. So I'll ask what can happen to an order before I worry about layout. And for the rest I build something people can look at, and I let the details get clear around it.
动机 · 公司 · 职业规划
Why do you want to work here?
Three reasons. First, the work matters, because I've spent my career on systems where a wrong number on screen is a real problem. Second, I want English as the working language. And third, I want a stable team, so I can grow with one team.
What do you know about our company?
To be upfront, most of what I know comes from your careers site and public pages. And what stood out is the work in many countries, a big tech team here, and code that sits close to strict business rules. And that means security is a real need, not an extra.
Why should we hire you?
Well, I've built what this job asks for. So splitting a big front end so teams can ship on their own, and a shared component library other teams used, and a buying path with real money and many currencies. And I'm used to rules for many regions, and I can start now.
Where do you see yourself in five years?
Deeper, not wider. I want to be the person a team trusts with front-end architecture, so how it's split, how state works, how fast pages should be, and how other teams build on top. And I want to keep helping people learn too. And I'm not rushing to become a manager.
What are you looking for in your next role?
Three things. I want to really own the work, so how something works and not just tickets. And a product big enough that careful work pays off. And a stable team, because I plan to stay in Shenzhen or Guangzhou for years. And pay matters, but it's not first.
Are you comfortable working in English every day?
Yeah. And I haven't been in a fully English team, so I want to be honest about that. But I read docs in English every day, and I've handled open-source issues in English, and I'm fine in meetings and writing. And I'd rather pause for the right word than guess.
HTML 丨 CSS 丨 JavaScript
What happens when you type a URL and press enter?
The browser looks up the domain, opens a connection, and sends the request. Then it gets the CSS and JavaScript too. And it builds one tree for content and one for styles, then lays out and paints it. And CSS blocks painting, so that's where speed talks start.
Can you explain closures?
Sure. A closure is a function that keeps access to the variables around it, even after that scope ends. And that's how a counter holds private state. And it's how leaks happen, if you hold something big. And the loop bug is every closure sharing one variable.
How does the JavaScript event loop work?
JavaScript has one call stack. And sync code runs first, then the engine clears the microtask queue, so promise callbacks. And then it takes one macrotask, like a timer. And that's why a promise runs before a setTimeout of zero, and why heavy work blocks painting.
What is the difference between debouncing and throttling?
Both limit how often a function runs. And debounce waits until you stop and then runs once, so it's good for a search box. And throttle runs at a steady pace while you keep going, so it's good for scroll. So debounce is for the last call, and throttle is for every set gap.
How do you debug a problem you cannot reproduce?
First I match the setup, so the same browser, region, role and data, because most of the time the setup is just different. And then I stop guessing and read the logs and the release. And if I still cannot find it, I add a safe check and say what I don't know.
TypeScript 丨 React
Why do you use TypeScript instead of JavaScript?
It catches a lot of bugs earlier. And on a shared library, it finds a wrong prop at build time, not in review. And it also makes big changes safer, because changing a data shape shows what breaks. So the cost is adding types for messy outside data.
What is the virtual DOM and how does React update the UI?
React keeps a light copy of the UI in memory. And when state changes, it builds a new one, compares it with the old one, and applies the smallest set of changes to the real DOM, and that's the slow part. So re-rendering is cheap but not free, and stable keys matter more.
How does data flow in React: props and state?
Data flows down. A parent passes props, and a child can't change them, so it calls a function back instead. And state stays local and changes through its setter. So the real question is where state lives: as low as it can, and moved up only when two parts share it.
How does useEffect work, and what are the common mistakes?
It runs after React updates the screen, so it's for work outside React, like listeners, timers and direct DOM changes. And the usual mistakes are a wrong dependency array, and a fetch with no cleanup, so a slow response sets state after the component is gone.
When do you use useMemo and useCallback?
Only when there is a real cost. And useMemo is for slow work, or to keep the same object so a memo child does not render again. And useCallback does that for functions. So I don't add them everywhere, because they can hide bugs.
Why would a component re-render, and how do you avoid unnecessary renders?
A component renders again when its state changes, when its parent renders, or when a context it reads changes. And I fix the shape first, so I move state down or I split the context. And then I use memo when props almost never change.
How do you decide how to manage state?
I split state by kind. Server data, like orders, goes in one place that fetches it and keeps a copy. And shared client state, like the cart or the login, goes in a store like Redux. And the rest stays local. And I don't copy server data into that store by hand.
Why are keys important when rendering lists in React?
Keys tell React which item is which. And a real id updates the right one. But with the index, a new order makes React think a different item changed, so inputs or focus go wrong. So I use a real id, and the index only if the list never changes.
工程化 丨 构建 丨 性能
How do you approach front-end performance optimization?
I measure first, because guessing picks the wrong thing. So real-user numbers and Core Web Vitals on key pages, and where the time goes. And the fixes are simple, so split the bundle by page, and don't draw below the first screen yet. And then I check bundle size in CI.
What are Core Web Vitals, and how do you improve them?
Three numbers. LCP is how fast the main content shows. And INP is how fast a tap gets an answer. And CLS is how much the page jumps. And we look at real users at the 75 percent mark, not the best case. So for LCP I check the server and images, and for CLS I leave empty space.
What is your testing strategy for a front-end codebase?
Mostly unit tests on pure logic, and most of all the risky rules like price or the checkout states, because they're cheap to test and bad to get wrong. And then a few UI tests on the main paths. And end-to-end on the flows that would be embarrassing to break.
Webpack or Vite: what is the difference, and which do you use?
In dev Vite lets the browser load each file alone, so start and updates stay fast. And Webpack rebuilds a big bundle every time. And for the real build both bundle, and Vite uses Rollup under it. So I pick Vite for a new app, but moving an old one is not always worth it.
How do you make a web application accessible?
I start with real HTML, because a real button gives keyboard use for free. And then labels, real alt text, focus you can see, and colors that are easy to read. And ARIA only where HTML can't say it, because bad ARIA is worse than none. And then I test with a keyboard.
How do you handle internationalization, currencies and time zones?
I keep words out of the code. And text sits in files by id, and dates and numbers go through one helper for that language. And money is a number plus a currency code. And I store time in UTC and show the user's time zone. And German text is about twice as long.
How do you use AI tools in your work, and how do you check what they produce?
I use them for boring parts, like setup, tests and small edits. But not for money, rights or security unless I read every line. And AI code gets the same review as a new hire's pull request, so I run tests, check odd cases, and ask why each line is there.
Walk me through how your code gets from your machine to production
I branch off main and open a pull request, and CI runs checks, types, tests and bundle size. Then two people review, and after merge we build files with a hash in the name, put them on a test site, and run end-to-end tests. Then production, and we can always go back.
How do you review someone else's code? What do you look for?
First I check that it works, so it does what the ticket says, and I check the bad paths. And then I look at what will be hard later, so unclear names, a data shape that is hard to change, and missing tests. And I leave code style to the linter. And if I say no, I explain why.
How do you use Git day to day, and how do you handle merge conflicts?
I keep small branches off main, one change per pull request, and messages that say why. And I rebase often so conflicts stay small. And when one comes up, I read both sides and talk to the other person before I choose. And I never fix it by just taking my side.
架构 丨 系统设计
How would you design the front-end architecture for a large application?
I'd start from how teams split the work, not folders. And if teams ship on their own, I'd build the app from parts that go live on their own, with a shared shell for routes, login and the look. And under that, one shared layer, so components, request code and tracking.
What are micro-frontends, and when would you use them?
It means splitting one big front end into parts that build and go live on their own, joined by a shell. And I'd use it when teams need their own release time. And not for a small team, because versions can clash and bugs are harder to find.
How do you handle authentication and authorization in the front end?
I don't own login. I use a token that dies soon, refresh it in one place, and keep no long-term secret in the browser. And rights are by role, checked on the server, because hiding a button is not real safety. And I check the page, not just the button.
How do you handle server data: loading, errors, caching and retries?
I keep server data in one place, with a clear loading, error or success state, so the screen can't show old data as new. And the saved copy follows the query, and I refresh after a change. And I retry reads and wait longer each time, but I never retry a write for no reason.
How do you decide between paying off technical debt and shipping features?
I look at risk and at speed. And if the old code slows every change, or it sits in code we touch every week, then it gets real time. And if it's ugly but stable and nobody goes there, I leave it. And I ask for a fixed bit of time each sprint, and I bring numbers.
How do you handle a production incident? Have you carried on-call?
I haven't been on a fixed on-call list, but I was first called when the buying path broke. And first I stop the harm, so I roll back or turn the feature off. And then I find what happened and who it hit, then the fix, then a short note so it doesn't come back.
网络 丨 安全
What is CORS, and how do you handle it?
CORS is the browser refusing to let a page read a response from another site, unless that server allows it. And it's the browser and not the network, so a request can succeed and still fail in code. And the fix is on the server: the right headers and a preflight response.
What is XSS, and how do you prevent it?
It means someone puts script into a page so it runs as the user. And the main way to stop it is not to treat text you don't trust as HTML, because the framework turns it into safe text for you. And I avoid raw HTML, and I use HttpOnly cookies and a content security policy.
What is CSRF, and how do you defend against it?
It means tricking a logged-in browser into sending a request the user did not mean to send, because cookies go out on their own. And you stop it with a token the attacker can't read, and with SameSite on cookies. And for risky actions I ask the user to confirm.
How do cookies work, and what do HttpOnly, Secure and SameSite do?
Cookies are small bits of state the browser sends back to the site that set them. And HttpOnly means JavaScript can't read them. And Secure means HTTPS only. And SameSite controls sends to other sites: Strict is safest, Lax is the usual one, None needs Secure.
How do you handle sensitive data and secrets in the front end?
I don't keep secrets in the front end, because anything sent to the browser can be seen. And keys stay on the server, and the screen calls our own backend. And I ask only for what I need, and I don't keep personal data in localStorage, and I check what goes into logs.
反问 丨 HR 丨 入职
Do you have any questions for us?
Yeah, a few. What is the team most excited about right now? And how is front-end work split across teams? And what does good look like in six months? And how do you ship, and who is on call? Because that shows how much people really own.
What are your salary expectations?
My last package was about 450,000 RMB a year. And I'm aiming at 450,000 to 480,000 depending on the level, and the housing fund base matters because I plan to buy a home. And I'm happy to hear your range first, and I look at the whole package and not just base.
When can you start?
I've already left my last company, so there's no notice period. And I could start one to two weeks after an offer, and within a week if you needed me sooner. And a few days to sort the move to Guangzhou is all I'd need. So, as soon as you want me.
Do you have other offers or ongoing interviews?
I'm talking to a few companies, but nothing has reached a written offer, so I'm not under time pressure. And I'd rather be open about that than pretend. And what I can say is this is the direction I care about most, so if we both want to move, I can move quickly.
Are you open to relocating and to hybrid working?
Yeah, both. And I'm in Shenzhen, and Guangzhou is an easy move, so moving is not a problem. And for hybrid, I'd want enough days in the office to really know people, especially people in other places. And a couple of days together makes the home days work better.
How do you work with teams in other countries and time zones?
I write first. And a short note with the choice and the reason means nobody wakes up early, and people reply in their own time. And I keep one or two shared hours for live talks. And I'm clear about what I need and by when.