豐揚科技股份有限公司

Legacy reviews: 1

Good 0%Neutral 0%Bad 100%Rating sample: 1 reviews

  • 0 reviewed job openings
  • 0 labor law violation records
  • Job links:
Work/Interview(1)
Q&A(0)
Chat(0)
豐揚科技股份有限公司
Pros

None at all

Cons

A project-based company. During the interview, they said, “You won’t need to be stationed at a client site,” but in reality, I spent almost the entire year stationed at client sites, with very little time at the company’s main office.

The client-site environment was extremely poor. There were no fixed monitors, so I often had to use my own laptop. Development required using my personal mobile hotspot, but the signal in the building was slow and unstable; some carriers had no signal at all. The ID badge was only used to enter the building. You would be reprimanded if you did not wear it, but you still had to wait for someone to open the door to use the elevators, go to the restroom, or enter and leave the floor. If no one was on the floor, you could only stand outside and wait.

Long working hours were the norm. Whenever I was stationed at a client site, I almost always worked more than 10 hours, and there were times when I worked 11–12 hours or more, with no overtime pay. Overtime could only be exchanged for compensatory leave at one-third of the hours worked, but in practice it was impossible to take the leave because the project schedule would fall apart as soon as you took time off. They could not ensure that employees left work on time, yet they strictly controlled starting times; being a few minutes late would get you called into a meeting.

The department manager said verbally, “You can bring up any problems,” but when I actually said that I did not want to continue pointless client-site assignments and that the working hours were too long, the only response was, “There’s nothing I can do. I’m developing your ability to communicate with clients.” During periods of routine overtime, the manager showed no concern. However, after I resigned and began leaving on time every day during the handover period, the manager would proactively call and beg me to finish rushing the project to completion.

A colleague (Mr. J) severely hampered development efficiency:

1. His only experience in the software industry was at this company. With 17–18 years of seniority and a monthly salary of 50,000, his technical ability was inadequate. He hard-coded large amounts of code and did not care about readability or maintainability.

2. Version control was completely out of control. The code on the local machines, test server, and production environment was all different.

3. Before every development task, we had to decompile the entire system, perform a three-way comparison, restore missing files, and deal with compilation issues. Only after completing all of that could development begin. When releasing a version, we could only deploy the modified files; deploying everything would immediately cause problems.

4. We were required to create “manual regression tests covering the entire UI.” Every button on every page had to be clicked individually and screenshotted. If a page had ten buttons, and each led to different pages, the number of clicks and screenshots increased exponentially. Whenever anything was modified, everything had to be retested. In practice, even clicking until your hands went numb was not enough to finish.

5. In addition to the code, we had to produce large amounts of documents and Excel files that no one ever read, severely reducing development time. When the project fell behind schedule, Mr. J would stab you in the back, completely avoiding discussion of issues such as clients adding requirements at the last minute, missing documentation, the poor client-site environment, outdated technology, the lack of CI/CD, and schedules with no contingency buffer.

The technology environment was outdated, using non-mainstream and extremely old language versions. We often discovered only after finishing the code that the test server did not support the syntax; sometimes even the IDE could not detect the issue. The work was primarily maintenance. Individual methods could easily be several thousand or even tens of thousands of lines long. No time was allocated for refactoring, yet we were still expected to deliver on schedule, including testing and documentation, resulting in consistently poor code quality.

There was no fixed annual salary-increase system, and salaries were far below market rates.

In one sentence:

The development experience was extremely poor. The system’s configuration and processes relied heavily on human judgment and manual attention, making errors inherently likely. However, the company refused to accept this premise, and whenever something went wrong, it was treated as your personal problem.

Reply
0
Agree
0
Disagree
0
Your reply should followQollie Posting Rules