Why Coding Interviews?

Most of your time as a software engineer will probably be spent coding or reviewing code, so it is important that we see how well you can do it during the interview process. In addition to assessing your coding skill, coding interviews also let us see what it is like to collaborate with you on a difficult problem.

With a coding question, what are interviewers trying to judge in a candidate?

Through a coding question, the interviewer is judging three main things: critical thinking, attention to detail, and working attitude.

Critical thinking

• The most challenging part of software engineering is solving difficult problems. In an interview, we do not have the time to partner with you to solve one of our company’s real-world problems. The next closest thing is to solve a difficult problem with you. Therefore, most coding interviews will include a difficult algorithmic component to assess how you solve challenging problems.

Attention to detail

• In coding, a single mistyped character can break a program in many ways. Having you actually write code during an interview lets us see how well you do this, including how well you are able to review and correct your own mistakes.

Working attitude

• Nobody likes to work with people with a bad attitude or incompatible culture. During the process of the interview, while working through a difficult problem and while pointing out mistakes or issues in your thinking/solution, we see how you respond and interact with the interviewer. This helps us assess what kind of peer you would be like to work with.

What can candidates do to prepare for interviews?

As with any kind of test, there are test-specific preparations you should make, but more importantly are the broader learnings you should engage in to push your career to the next level. There are many books / sites dedicated to this topic, but here are some of our recommendations:

Interview-specific skills

• Practice interviewing: Do coding interviews on a whiteboard with your friends first, then acquaintances that you do not know that well, and even strangers if you can! This will help you practice solving a problem with a stranger and explaining your thoughts out loud.
• Write code by hand: Some IDEs write a huge portion of code for you, but there are environments/languages where these IDEs can’t be used. We prefer hiring people that can code without any support.
• Write code on a whiteboard: You only need to do this once or twice to figure this out. Don’t let the interview be your first experience doing this.

Job skills

Learn how to think about algorithms:

• Most candidates should have done a lot of this during school.
• Websites like geeksforgeeks or leetcode or hackerrank, etc. are all excellent resources for practicing algorithms.
• During your work, you usually won’t have a beautifully stated dynamic programming question to solve, but the concepts of caching, precomputing, and removing redundant work will come up constantly.

Focus on how you figure out these algorithms from first principles

• Do not just memorize the questions/solutions you see.
• We will not proceed with a question if we suspect you’ve seen it before (it’s quite easy to tell when this happens), so it’s not useful to memorize algorithm questions.

A bit about Front-end engineers, what the job looks like, what's your responsibilities, skills and also some facts, some challenges that you have to face when being a Front-end engineer.

Hi, this is Văn Linh from the Seller Center team, Teko Vietnam.

Is it worth being a Front-end engineer?

Some of you must have thought that Front-end is just a simple job which is easy to achieve, the work just revolves around doing the UI for an application. For example: you only have to cut the HTML, use CSS for styling some buttons, images... of the page, and include some JavaScript codes for the functionality. That's all, sounds easy? 😎

Let me tell you a story, it might upset you but it's a truth, a true story which happened at a company in Vietnam. I will call it company X - of course this company is not Teko 😁

There's a man, he led a Back-end team in company X. There's a member in his team who made mistakes frequently and made him very unhappy. One day, he couldn't take it anymore and told that member: "If you make mistakes more and more, contact HR to see if the Front-end team has slots and join it instead". Of course, we all thought it was a joke from that guy. However, he repeated his bad thought about Front-end many times, even he organized games for his team and told other members: "Who win can code Back-end, who lose will have to code Front-end instead". The CTO of company X always troll him by telling him: "Can you code CSS?" 🙂

So, is Front-end job really as cheap as the TL from company X thinks? Is it worth being a Front-end engineer? 🤔

Myths and Facts

I will go through a few examples about something that you might think it's good but it's really not, also the facts that Front-end engineers have to face, and how are these things being applied in Teko. You will know what is the real job of a Front-end engineer. It's not as simple as you think, but it's not too complicated 😉

Front-end is not a job which you have to do in a stereotypical way, but you should work in a flexible way instead. To be a strong Front-end engineer, you will need not only to own the Front-end skills, but also to show your creativity, thinking, responsibility and even art in work.

Myth #1: It's good to design features with complex logic

Situation: Your boss defines 10 features for a screen with complex logic. He defines the requirement very clearly with a very high confidence and gives it to you 😎 Your job is to develop a screen that can meet most requirements.

Fact: After you deploy this screen on production for a while, you, your team and your boss realize that end-users only use 1 out of 10 features that's been well-defined 😞 LOL, why?

You must remember a very important principle when designing/developing Front-end features: what users think is not really what you think. You can build a very big feature that contains complex logic and you are very clear with the logic of this feature. However, users might not know how to use it, or the UX is really bad that makes them very confused, they feel that they receive zero-value when using your feature. That's why they get rid of using your feature, and they will give a lot of feedback for you/your team with an uncomfortable mood.

💡 Lessons learned

• Think about MVP (Minimum Viable Product) first. Build as simple as possible with enough features to serve customers quickly 👍
• Remember Pareto Principle which states that 20% of efforts bring 80% of results, and the other 80% of efforts bring only 20% of results.

• Tracking is very important ⭐ Everything you did should have a logging/tracking system. This will help you to trace error logs to optimize app performance, trace user behaviour to optimize app's UI/UX, functionality and more.

🚀 How do we apply these lessons in Teko?

• A lot of features have been done in MVP version to onboard quickly.
• When brainstorming a feature, we cut off a lot of useless functions that can bring zero-value to customers.
• Using tracker-js to trace all user behaviour and API-integration error logs to optimize app performance and UI/UX.
• Using Google Analytics, Facebook pixel for tracking ecommerce events, conversion rate, revenue... to optimize SEO, marketing strategies, advertising campaigns... for ecommerce apps.

Myth #2: It's easy to build features to meet the UI/UX design

Situation: Your PO/designer gives you a wireframe for a feature that acts A and he expects that you build this feature to exactly act A.

Fact: You build this feature that acts B which has a different UX behaviour than A, or the feature is not really worked as expected from the PO 💔

This is very normal and usually happens in many projects. There are many reasons why this case happens such as missing requirements, the wireframe is not clear and does not cover all cases, the Front-end developers build the feature according to their own understanding without raising any problems...

The drafted wireframe from PO/designer is only their overall thinking of a screen/feature. Of course, they cannot figure out all the cases (especially the corner cases) for you at the beginning, because they're not the person who implements the feature, but you are. When you build the feature, you will directly experience the user behaviour and find out there will be a lot of questions that need to be answered. That's why I say "Front-end engineers should work in a flexible way".

💡 Lessons learned

• Do not hesitate to ask as many questions as possible when receiving a wireframe. It will take your time at the beginning, but it will save much more time/effort later on, trust me 😉
• The requirements can be unexpectedly changed at any time, and you will need to face this instead of running away.
• As an engineer, you will have the right to raise any problems that you find unreasonable, or reject any nonsense requirements from the PO. If you can, show your UI/UX design skill and modify the wireframe or requirement to make the feature better that can bring a good user experience and more business value. So please be proactive !!! ⭐

🚀 How do we apply these lessons in Teko?

• Increasing time for the design phase to clear all problems about UI/UX design, business, API documentation... to make sure the coding phase is clear and not to be reworked too much.
• Front-end engineers are more proactive on raising problem when receiving a wireframe or an API documentation.

Myth #3: It's easy to build shareable components for team

Situation: You build a shared component for everyone in your team to reuse in some screens and you expect that everyone will use your component 😍

Fact: No one uses your component 😢 they build the component in their own way and duplicate this component in many variations.

There is one thing you will obviously know and I don't need to tell you: the code will be very messy and hard-maintained in this case.

For example: you build a component Price to format price currency. However, member A builds another component PriceLabel to format currency too, with a little difference in logic. In addition, member B also builds another component PriceInfo to format currency with other logic... When a new member joins the team, he will see at least 3 components that do the same functionality and a big question comes to his mind: "Which one should I use now?"

If the team scales more and more, it will be much more difficult to manage the code. Therefore, code management, responsibility, commitment and the initiative at work are very important.

💡 Lessons learned

• Document your components clearly. You might want to use the UI component explorer for better management (eg: Storybook, Styleguidist...), everyone will use it as the component documentation of the team.
• The TL should backup code for the team, ensure the code quality and the review-code process to make sure the code is clean and clear.
• Everyone should have the responsibility when building/contributing to any shared components, and follow the coding convention of the team.

🚀 How do we apply these lessons in Teko?

• The consumer-app project: monorepo teko-web which defines shared components to reuse across many sites.
• The staff - back office project: monorepo staff-interface which defines a shared design system, layout and sidebar menu for a large system that includes many modules such as product, price & promotion, page builder, purchasing, warehouse, logistic...
• Storybook for the shared components used in consumer-app, staff - back office, design system (eg: https://design.teko.vn)...

Conclusion

The above Myths & Facts are just a few practical examples. There will be many other situations that you will meet when you work as a Front-end engineer. Being a Front-end engineer, you will learn how to satisfy the customers who directly use your products, although it's very very hard to do. You will make mistakes, sometimes you will feel bored with your work, but the more you fail and recover and improve, the more mature you become.

Front-end has a lot of things for you to learn, to grow in both technical and soft skills. Therefore, do not hesitate to be a Front-end engineer if you want 😄

1. Về các thông tin chung:

Một chiếc CV ngắn gọn và đủ ý nên được tóm lược trong 1-2 trang A4 ở định dạng PDF. CV của ứng viên trong ngành IT nên được viết bằng tiếng Anh và phải được kiểm tra lỗi chính tả một cách cẩn thận.

Chú ý: Để nhà tuyển dụng có cái nhìn tổng quan về chủ nhân của chiếc CV, bạn có thể giới thiệu vắn tắt về bản thân trong khoảng 2-3 câu. Phần này sẽ trả lời những câu hỏi “bạn có kinh nghiệm trong lĩnh vực gì?” “mối quan tâm/định hướng của bạn là gì?”. Phần này không bắt buộc, tuy nhiên nó giúp bạn trả lời câu hỏi “Bạn là ai?” và biết đâu sẽ có những cơ hội công việc tìm đến phù hợp với những mối quan tâm của bạn.

2. Thông tin cá nhân:

Phần này rất quan trọng với nhà tuyển dụng, tuy nhiên không nên dài dòng mà nên trình bày ngắn gọn, đủ ý thôi nhé! Ngoài ra nên có link Github, Linkedin hoặc website cá nhân với link ngắn hoặc dưới dạng link ẩn.

3. Học vấn:

Ngoài những thông tin cơ bản như Tên trường, ngành học, thời gian bắt đầu – tốt nghiệp … thì những thông tin về GPA/học bổng/thành tích mà bạn đã đạt được sẽ là những thông tin gây ấn tượng tốt với nhà tuyển dụng. Nếu phần này không có gì nổi bật thì cũng không sao, hãy tập trung vào phần Kinh nghiệm làm việc nhé!

4. Kinh nghiệm làm việc:

Nhà tuyển dụng thường quan tâm đến những kinh nghiệm mà bạn đã làm trong khoảng 5-7 năm gần nhất. Nếu bạn có nhiều năm kinh nghiệm hơn, có thể tóm lược thông tin dưới dạng “vị trí mà bạn đảm nhiệm – thời gian làm việc – công ty mà bạn làm – tóm lược về công việc bạn đã làm” trong 1-2 dòng.

Thông tin ở phần Kinh nghiệm làm việc nên được sắp xếp theo thứ tự thời gian đảo ngược, tức là những công việc gần nhất nên được đưa lên đầu tiên. Ở mỗi công việc nên có đủ thông tin về Vị trí, Tên công ty, Thời gian làm việc tại công ty (tháng, năm), Mô tả những công việc bạn đã làm và kết quả đạt được.

Chú ý: Phần mô tả công việc nên được viết bằng những câu ngắn, chỉ rõ rằng “bạn đã làm gì” “bằng cách nào” “kết quả như thế nào”. Ví dụ:

Redesigned and rebuilt the core of the platform by using gRPC, improved speed by more than two-fold and reduced memory-usage by almost 4 times.

5. Kỹ năng:

Một phần nữa mà các nhà tuyển dụng đặc biệt chú ý là phần Kỹ năng. Để ngắn gọn và hiệu quả, hãy liệt kê các thông tin theo thứ tự các kỹ năng bạn thành thạo nhất đến ít thành thạo hơn. Không cần tốn thời gian làm bảng biểu, đánh giá từ 1 đến 5 sao vì năng lực của bạn sẽ được kiểm chứng trong các bài test và buổi phỏng vấn.

6. Chứng chỉ/Giải thưởng:

Đây là phần highlight khiến CV của bạn nổi bật hơn. Nếu bạn có tham gia các cuộc thi coding, Hackathon hoặc những khóa học liên quan đến các kỹ năng công việc, đừng ngần ngại liệt kê chúng vào. Tuy nhiên đừng lạm dụng, hãy liệt kê 3-4 thông tin có giá trị nhất thôi nhé.

7. Thông tin khác:

Nếu bạn có những dự án riêng hay ho (Personal Projects) hoặc dự án nổi bật tại công ty, bạn có thể liệt kê những dự án đó vào trang sau của CV hoặc liệt kê chi tiết trên Linkedin để nhà tuyển dụng tham khảo thêm nhé!

Hi vọng với những tips đã nêu ở trên, CV của bạn sẽ dễ dàng vượt qua các vòng kiểm duyệt và ghi điểm với nhà tuyển dụng. Nào, giờ thì hãy bắt tay vào “thiết kế” 1 chiếc CV thật xịn xò và gửi cho team HR của Teko Vietnam thôi nào!