Three months is the standard probation period at Alibaba, and before I knew it, mine was over too. That also meant it was time for my regularization review.
Looking back, I touched a lot of things in those three months—some scattered, some routine, some unexpectedly difficult—but there were a few clear themes. What stands out most are the kinds of situations that kept coming up in day-to-day work, the front-end knowledge those situations demanded, and some thoughts I’ve had about what “advancing” in front-end really means once you’re past the beginner stage.
The first few months on the job
Not long after I joined, Alibaba went public, which was an exciting moment to be around for. In practice, though, I wasn’t completely new to the environment: before officially joining, I had already spent three months interning with Taobao UED, so the workflow, the tools, and the general pace of development were already familiar.
Still, being officially on the team is different. Very quickly, I ran into the kinds of situations that are common in real product work.
Production bugs always come first
A typical message from operations might sound like this: a customer reports that image preview fails on a form submission page, can you take a look?
You may already be juggling several tasks, but one rule becomes obvious very fast: production issues take top priority. “Customer first” isn’t just a slogan. If something is broken for users, that outranks almost everything else.
So you open the page, test it locally, and... everything works fine. No upload failure. No preview issue. Nothing abnormal.
At that point the investigation becomes much less straightforward. You ask the user to try another browser. Then another machine. Still nothing changes. Eventually the only option is to remote into the customer’s computer and inspect the issue directly. In this case, the root cause turned out not to be the page logic at all, but a CDN problem affecting a particular region.
That kind of experience teaches you something important early on: solving a front-end issue often has less to do with writing code than with narrowing down variables, verifying environments, and resisting the urge to assume the first explanation is the right one.
How a site revamp actually moves forward
Another common situation is being assigned responsibility for one or more business lines, and then suddenly being pulled into a redesign or feature expansion. A large request rarely arrives in a clean, final form. It usually goes through multiple rounds of discussion and review before development properly begins.
At the start, product and operations argue through what should be built and why. Once that product review settles the basic direction, front-end, design, and development join the interaction review to refine how things should work. After that, visual designers go back to produce mockups, backend engineers start preparing the data side, and front-end engineers stay in close contact with design while waiting for the final assets.
Once the visual draft is complete, front-end development really starts. And one of the first practical questions is: who defines the interface contract?
If the backend team defines the APIs first, they often need to mock data while their real implementation is still in progress. At that stage, the API domain and the front-end development environment may not match, which creates cross-domain issues. One workaround is to expose JSONP during development and switch back to JSON later, but that means more changes and more follow-up work once integration starts.
If the front-end team defines the interfaces instead, then the front end usually mocks data locally. That works for initial development, but if the backend still isn’t ready by the time front-end implementation is done, the integration phase becomes awkward. Backend may end up mocking the same data again, so both sides have effectively duplicated effort.
Fortunately, we had a tool specifically for API definition. It could persist interface specs as documentation, provide mock data that could be accessed across domains, and make interface changes much easier to manage. With a tool like that in place, the process became much more manageable.
So the practical choice was simple enough: write up the data interfaces, hand them to the backend team for review, and then start slicing the designs and building the page.
For internal front-end work, the framework in use was KISSY. It had already advanced to version 5.0, though the version most commonly used in business work was still 1.4.x. For companies without their own framework, jQuery often becomes the default foundation. KISSY played a similar role internally, but it was more tailored to business scenarios. It came with a large collection of components and plugins and was very convenient once you were comfortable with it, though getting over the learning curve took some effort.
Business logic was then implemented with KISSY, and static resources were deployed to the CDN. On this point, the internal publishing system really was excellent.
Because the HTML layer was handled by the backend side, front-end developers would finish the HTML/CSS/JS, hand the HTML over to backend engineers, and publish static assets—CSS, JS, and images—separately. Images could be uploaded directly. CSS and JS were packaged locally and pushed to the repository, after which the system handled the CDN deployment automatically. In most cases, front-end changes could show up online within two minutes. Releasing dozens of versions in a single day wasn’t a problem.
That speed made a real difference. Small changes didn’t require standing in line for deployment windows or nervously waiting to see whether someone else would publish first and force another merge. The release process felt designed to help developers move quickly instead of slowing them down.
Once backend development was also complete, testing would begin. QA would come in to verify the system, and operations could also join to validate the business flow. After the bugs were fixed, the feature could officially go live.
One interesting detail in this process is that front-end resources were often deployed ahead of the backend code. Everything above describes the PC-side workflow; mobile development had some notable differences, but that’s another discussion.
Requirements change, even when you think you’re done
There’s also the situation everyone eventually runs into: you feel great because a project has just been completed smoothly, and then someone from operations comes over to say that one feature can’t launch this cycle after all. Maybe the reason is external, maybe it’s procedural, maybe it’s strategic—but either way, that module has to be removed now and moved to V2.
You ask the obvious question: after I make this change, is the requirement finally stable?
The answer is the kind that makes any developer uneasy: maybe yes, maybe no.
And then the whole process keeps going.
For people who haven’t worked in a company setting yet, scenes like these probably offer a more realistic picture of how product development works. The three situations above are extremely common, but of course they’re only part of the job.
Not just page work
During those three months, I also participated in developing a front-end automation inspection tool and completed both front-end and backend-side transformations for it.
The technologies involved included:
- websocket for real-time communication
- scss/less as CSS preprocessing tools
- grunt/gulp for packaging and build tasks
- MVC-style separation
- Promise-based asynchronous programming
- middleware writing
- Express as a Node framework
- ...
And even that list only covers part of a single project.
Front-end work hides a surprising number of traps. If your fundamentals aren’t solid, you’ll constantly run into them. The same task that someone else can finish in three hours may take you three days—not because the task is impossible, but because you keep getting stuck on things you should already understand.
What “advanced learning” in front-end really looks like
A lot of capable front-end developers hit a point where they feel strangely stuck. They’ve learned enough to build things, but then they start wondering what to learn next and whether the things they are learning actually matter. In many cases, what people focus on while studying doesn’t line up especially well with the work they later do on the job.
That disconnect is worth talking about.
I once raised this question on Weibo as well. Many people study without much structure: a little of this today, a little of that tomorrow. After a while, they feel like they “know” all of it, but they don’t have a good way to verify whether they really understand it deeply enough. Then one day the question arrives: what exactly should I learn next?
Everyone grows through stages, and each stage involves a kind of transformation. Once you’ve crossed the threshold into front-end development, the next thing to think about is not simply “more knowledge,” but how to improve your level in a meaningful way.
Take a simple example: are you actually fluent with git?
Publishing front-end resources to the CDN relied on git. Common commands like add, commit, diff, log, status, tag, remote, push, and merge weren’t optional decorations—they were part of everyday work. Beyond memorizing commands, there’s also the mindset of version management: when a production bug appears, how do you handle the codebase? Do you open a new branch? Do you patch on top of the current branch? How do you organize versions so that fixes and new development don’t collide?
A lot of important knowledge areas require substantial time investment. Things like backbone, jQuery source analysis, MVVM, design patterns, the HTTP protocol, responsive design, asynchronous programming, modularization, websocket, DOM monitoring, local storage, browser rendering principles, and more.
A useful way to study is to list these topics as keywords and then expand from each one.
The method itself is simple: search one keyword, read through a dozen strong articles, and then keep following the new keywords that appear inside those articles until the larger topic starts to open up. That’s how I’ve been learning for a long time.
Learning front-end well is a long-term job, and it’s rarely an easy one. But once you’ve seen how real work unfolds—production bugs, shifting requirements, release pipelines, cross-team coordination, and the constant need to strengthen your foundations—you also get a clearer sense of what to work on next.