thảo luận Review phỏng vấn vị trí Unity ở Sky Mavis

Aluminum21

Senior Member
Chào các thím, tôi vừa trải qua 7 tuần (tính từ ngày submit CV) để hoàn thành xém xong 1 process phỏng vấn vị trí Unity ở Sky Mavis (SM). Nay cuối tuần rảnh rỗi nên review full quy trình phỏng vấn cho các thím nộp sau có thể đỡ tốn thời gian hơn tôi.

Job này tôi được 1 bạn headhunt gởi, giới thiệu là 1 vị trí trong 1 project AAA của SM (Link JD cho thím nào cần tham khảo, thời điểm tôi viết bài thì nó vẫn open). Ban đầu tôi nghĩ headhunt nói vậy chỉ để câu CV thôi chứ nhân sự SM đâu trên dưới 200 thì làm gì đủ lực làm AAA. Nhưng sau khi đọc JD thấy có "AAA" nên tôi đã submit CV tìm hiểu thử. Sau hơn 1 tuần headhunt báo lại SM muốn mời tôi phỏng vấn mặc dù theo đánh giá sơ bộ thì SM cho rằng tôi vẫn chưa đến level Senior, chỉ tầm Mid thôi, SM sẽ đánh giá lại dựa vào performance phỏng vấn sau đó.

Vòng đầu tiên là phone interview với HR. Nội dung xoay quanh kinh nghiệm làm việc, vì sao nghỉ chỗ cũ... những thứ thường có ở vòng HR interview. Ở vòng này tôi cũng có hỏi về project AAA bên SM đang làm là gì thì được HR confirm, mặc dù JD có ghi AAA nhưng thật ra vị trí này là của team Origins (project game đầu tiên của SM), tương lai có thể SM sẽ làm AAA nhưng với nguồn lực hiện tại thì chưa đủ. Tôi có hơi cụt hứng khi nghe vậy nhưng thôi, vào project lâu năm cũng được, ít ra thì game nó cũng đang run ổn và benefit package của SM tốt.

Vòng 2 là bài test làm game với Unity. Tôi nhận đề ngay sau khi phỏng vấn xong với HR. Bài test có thời gian làm bài là 7 ngày. Thể loại game trong bài test là turn based, tôi thấy đề bài hợp lý vì vị trí tôi ứng tuyển cũng làm game có gameplay dạng turn based. Thời gian khá thư thả nên tôi sau khi xong phần requirement của đề thì polish, thêm tí logic cân bằng và document cho test project. Tôi nộp bài sớm 1 ngày vì lúc đó tôi có việc đột xuất. Sau 1 tuần tôi nhận được kết quả đã pass bài test.

Vòng 3 là technical interview tại văn phòng ở tòa nhà Đức bên Lê Duẩn. Interviewers là leader và 1 thành viên (tôi nghĩ là Senior) của team Origins, người hỏi chủ yếu là anh leader. Ngay câu hỏi đầu tiên tôi đã hơi khựng:
  • Interviewer: Nguyện vọng em muốn vào team nào ở đây
  • Tôi: Ủa anh, em được chọn hả, vòng trước HR nói em vị trí này của team Origins mà.
  • Interviewer: HR nói em vậy hả. Umh... cái đó thì anh cũng không chắc.
  • Tôi: Vậy nếu được chọn thì anh cho em vào team nào làm 3d là được.

Câu hỏi tiếp theo liên quan về ưu nhược điểm của structure design tôi sử dụng trong bài test. Các thím làm Unity chắc đã từng coi qua video này, 1 cách drive logic bằng asset cụ thể ở đây là ScriptableObject, đây cũng là cách tôi sử dụng để structure cho bài test. Cách này thường sẽ bị team source code driven bài trừ vì họ cho rằng không phù hợp cho project lớn, khó trace logic, phát sinh nhiều SO... Và interviewer là 1 người như vậy. Việc dùng asset driven hay source code driven với tôi nó là vấn đề về khẩu vị nên tôi không sa đà vào tranh cãi, tôi chỉ nêu ưu nhược điểm mà tôi đã thấy sau vài năm sử dụng. Không biết do tôi trình bày kém hay interviewer có tư tưởng bài trừ hơi mạnh nên kết thúc phần này, interviewer kết luận "cách này vẫn chỉ phù hợp cho project nhỏ và nó cũng không tốt nên tới giờ vẫn không phổ biến". Các câu hỏi tiếp theo thì về những project tôi đã làm, về decouple, so sánh 2d và 3d rendering...

Đến phần ứng viên đặt câu hỏi,
  • Tôi: Bên mình cần kinh nghiệm gì của người làm đã từng làm qua AAA, tại em thấy trong JD có nhắc.
  • Interviewer: Hiện tại thì không có project AAA nào, AA cũng chưa có. Còn JD cũng không phải anh viết.
  • Tôi: Anh mong đợi 1 người như thế nào vào team anh?
  • Interviewer: Anh đánh giá cao potential hơn là kinh nghiệm. Vì với anh kinh nghiệm nó có yếu tố may mắn.
  • Tôi: Bên mình lúc báo kết quả có thể đưa em coi luôn chi tiết đánh giá ứng viên không anh hay policy chỉ cho phép báo pass hay fail thôi?
  • Interviewer: Hình như được, nếu em muốn biết thì anh trả lời luôn bây giờ cho em cũng được. Em có potential nhưng thiếu kinh nghiệm làm việc ở project lớn. Em cũng chưa hiểu Unity đủ sâu để thấy ghét nó như anh. Anh cũng chưa rõ định hướng của em tại qua trao đổi thấy em muốn học nhiều quá.
  • Tôi: Cám ơn anh, em hết câu hỏi.

Sau 1 tuần thì headhunt báo tôi đã pass vòng 3, HR sẽ gọi điện process tiếp. Qua 1 ngày tôi nhận được điện thoại của HR, đại loại, kế hoạch phát triển của team Origins thay đổi nên SM offer tôi một vị trí ở project khác tên là Project T. Team Project T nằm ở văn phòng quận 2, làm ở team này thì sẽ không kí hợp đồng lao động với SM, mà sẽ kí với một bên thứ 3, do đó quyền lợi cũng sẽ thay đổi. Cụ thể thì sẽ chỉ có base lương và nghỉ public holiday (không thuế, bảo hiểm, phép năm và lương tháng 13). Không biết là process nội bộ bên SM có vấn đề gì không nhưng khi liệt kê các fact từ lúc ứng tuyển tới giờ, tôi thấy nó hơi "treo đầu dê bán thịt chó" và Project T gameplay cũng không hợp khẩu vị tôi nên sau 1 ngày suy nghĩ tôi quyết định dừng process.

Các thím nếu có ứng tuyển vô vị trí trên của SM thì nhớ confirm rõ với HR qua từng vòng, follow coi thử kế hoạch bển có thay đổi gì ảnh hưởng tới vị trí các thím đang apply không để tránh những thay đổi phút cuối giống tôi, mất thời gian, tại việc đánh giá kết quả ở mỗi vòng mất tới 1 tuần.

Bonus: Các thím nào đang mới structure project theo asset driven như trong bài mà cảm thấy hoang mang vì nó "chỉ hợp với các project nhỏ" như nhận xét của interviewer vòng 3 của tôi thì tôi nghĩ các thím cứ yên tâm xài nếu hợp khẩu vị. Người đưa ra ý tưởng trên và cũng đã ứng dụng vào các project thực tế là Principal Engineer của Schell Games, portfolio của studio ở đây. Những game như Among Us VR hay I Expect You To Die thì không gọi là nhỏ được, hoặc giả nếu nó có nhỏ thật thì cũng không nhỏ hơn 90% game các thím có thể làm ở VN.
 
Cái asset driven những thằng dev cùng dự án với thím nó chửi cho chết mẹ. Éo thích nghi được:shame:
Như hiện tại ở VN có công ty Archmage làm game casual loại midcore như God of Weapons khá thành công trên Steam, tuyển senior dev lương cũng khá cao nhưng project của họ toàn xài ECS, các lập trình viên có kinh nghiệm pass qua phỏng vấn cũng éo thích nghi được :shame:
 
Em từng thử asset driven như bác nhưng mà khó track logic lắm. Bác có kin nghiệm gì về việc này không?
Qua vài dự án thì tôi thấy để dễ trace logic hơn thì thường phải naming Variable hay Event tốt, chú thích nếu khó naming, xài tool tìm reference (đơn giản thì có cái này, hình như có tool tốn phí tốt hơn nhưng nhu cầu của tôi thì cái đơn giản như trên đã đủ để trace). Phần event thì tôi có viết thêm chút để show info ra inspector như hình (tính làm cái hiện Publisher nhưng lười với căn bản là cũng chưa cần xài tới).

1705143272551.png


Cái asset driven những thằng dev cùng dự án với thím nó chửi cho chết mẹ. Éo thích nghi được:shame:
Như hiện tại ở VN có công ty Archmage làm game casual loại midcore như God of Weapons khá thành công trên Steam, tuyển senior dev lương cũng khá cao nhưng project của họ toàn xài ECS, các lập trình viên có kinh nghiệm pass qua phỏng vấn cũng éo thích nghi được :shame:
Vậy nên tôi mới nói dùng hay không nó thuộc về khẩu vị. Ai ghét ớt mà bắt ăn thì cũng chửi bới thôi, ai ăn được thì lại ghiền. Món asset driven này tôi đi nhiều chỗ, chỉ mới gặp được ông thoxaycoder là cùng khẩu vị.
 
Vậy nên tôi mới nói dùng hay không nó thuộc về khẩu vị. Ai ghét ớt mà bắt ăn thì cũng chửi bới thôi, ai ăn được thì lại ghiền. Món asset driven này tôi đi nhiều chỗ, chỉ mới gặp được ông thoxaycoder là cùng khẩu vị.
Thế làm AAA như Genshin Impact 1 mình thím dev được à ? :shame:
 
Thế làm AAA như Genshin Impact 1 mình thím dev được à ? :shame:
Là sao thím. Đi làm thuê thì vào project họ structure như nào thì mình theo, tôi thích asset driven thì đâu có nghĩa source code driven tôi không làm được. Nhưng nếu để tự do thì tôi chọn cái mình thích. Vậy thôi.
 
Là sao thím. Đi làm thuê thì vào project họ structure như nào thì mình theo, tôi thích asset driven thì đâu có nghĩa source code driven tôi không làm được. Nhưng nếu để tự do thì tôi chọn cái mình thích. Vậy thôi.
Ý tôi là nếu thím làm lead của 1 team dev AAA thì thím vẫn chọn asset driven đúng không ?
 
Ý tôi là nếu thím làm lead của 1 team dev AAA thì thím vẫn chọn asset driven đúng không ?
Tôi không biết. Tôi chưa từng làm lead, cũng chưa làm AAA, không đủ kinh nghiệm để giả định. Lead chưa chắc đã tự do. Tôi có thể nói cho thím biết những nơi tôi đã chọn asset driven: project cá nhân (đương nhiên), project với teamate cùng khẩu vị asset driven hoặc những module trong project lớn hơn có độ độc lập tương đối.
 
Cái asset driven những thằng dev cùng dự án với thím nó chửi cho chết mẹ. Éo thích nghi được:shame:
Như hiện tại ở VN có công ty Archmage làm game casual loại midcore như God of Weapons khá thành công trên Steam, tuyển senior dev lương cũng khá cao nhưng project của họ toàn xài ECS, các lập trình viên có kinh nghiệm pass qua phỏng vấn cũng éo thích nghi được :shame:
Không biết bên đó còn tuyển k nhỉ bạn, mình có kinh nghiệm làm vài project dùng ECS rồi :D
 
Tôi chỉ thấy asset driven có rất nhiều vấn đề cần 1 người có exp lâu năm để giải quyết từ việc optimize mem, addressable, naming convention cần comment code với có document để người mới vào không tạo thêm những cái đã có rồi. À chưa tính tôi thấy xài nhiều game sẽ bị nhiều State. Làm dự án nhỏ 2 3 người thì tôi nghĩ okay chớ làm đông tầm chục người thì hơi khó để quản lí.
Kết luận: tui chê.
 
Cá nhân thì thấy phần nào thường thay đổi nhiều thì bê xuống asset. Chứ làm 1 lần rồi để đó luôn thì đem vô asset cực cho member khác trace logic.
 
Trông nghe có vẻ hơi treo đầu dê bán thịt chó nhỉ. Phỏng vấn thì Sky Marvis mà offer chỗ khác, benefit cũng không có.
 
Trông nghe có vẻ hơi treo đầu dê bán thịt chó nhỉ. Phỏng vấn thì Sky Marvis mà offer chỗ khác, benefit cũng không có.
Chắc lỡ define benefit package to quá, cắt bớt sợ người cũ la ó, để nguyên để tuyển mới thì hao. Với team làm game mới không hợp đồng ràng buộc với SM thì lỡ game flop thì cắt cụp, đỡ mang tiếng lay off.
 
Cá nhân e cũng thích asset driven. Giai đoạn đầu design codebase code nhiều nhưng đến actual implementation toàn kéo thả rất thích :big_smile: Decision makings, enemy waves, skill trees, tutorials blah blah đều là scriptable objects cả. Mà gameplay thôi còn UI, sdk các thứ vẫn làm code driven :smile:
1 trong những cái hay của nó là game designer cần tinh chỉnh gì thì ko cần qua dev nữa, tự balance hoặc chế thêm creep hay skill mới với QA mà ko cần thêm 1 dòng code nào :big_smile: Chỉ tội là ko có thời gian để viết custom editor nên dùng tạm default drawer khá í ẹ, GD cứ kéo nhầm :beat_shot:
 
Bonus: Các thím nào đang mới structure project theo asset driven như trong bài mà cảm thấy hoang mang vì nó "chỉ hợp với các project nhỏ" như nhận xét của interviewer vòng 3 của tôi thì tôi nghĩ các thím cứ yên tâm xài nếu hợp khẩu vị. Người đưa ra ý tưởng trên và cũng đã ứng dụng vào các project thực tế là Principal Engineer của Schell Games, portfolio của studio ở đây. Những game như Among Us VR hay I Expect You To Die thì không gọi là nhỏ được, hoặc giả nếu nó có nhỏ thật thì cũng không nhỏ hơn 90% game các thím có thể làm ở VN.
Cái Assets Driven này là một dạng implementation khác của Data-Driven programming trong Unity đúng không? Nếu như nó là Data-Driven thì dạng paradigm này đã được sử dụng trong game dev (từ Indie đến triple A) từ thời tiền sử rồi có gì mà phải tranh cãi nhỉ?
 
range lương cho mid vs senior ở SM ngon ko thím, cty game chắc game dev là lương cao nhất r thím nhỉ
 
Back
Top