Từng làm bài test kỹ thuật ở đây. Khâu Test kỹ thuật không phù hợp với những người có tinh thần teamwork cao và nhiều kinh nghiệm trong việc làm các dự án lớn. Mình có nhiều năm kinh nghiệm, có viết cả bài báo khoa học và luận văn master. Ở cty cũ mình là người phỏng vấn tuyển dụng, review code, train thành viên mới. Mình cũng là người trực tiếp trao đổi với khách hàng để phân tích rõ yêu cầu của dự án, nhưng khi làm bài test kỹ thuật ở đây thì người ra đề không chịu hợp tác làm rõ yêu cầu kỹ thuật. Bài test yêu cầu khá dễ, sinh viên cũng làm được. Làm xong nộp bị thông báo fail. Mình hỏi thì bạn HR chụp 1 đoạn đánh giá tiêu chí khá vô lý. Ví dụ Kotlin 2 điểm, Java 1 điểm. Mình nói đề ghi dùng Java hay Kotlin đều được, nếu thích Kotlin sao không nói từ đầu, mình có thể viết lại bằng Kotlin. /> Đánh giá lại cho rằng cấu trúc code chưa tốt giữa View, Data. Mình nói cấu trúc code dựa trên Sample MVVM của Google, có cả link project dẫn chứng. Mình hỏi hay là muốn làm theo MVP, hoặc muốn chỉnh chỗ nào cứ nói mình sửa lại. Nhưng không thấy trả lời. Ngoài ra còn trừ điểm vì có comment trong code. Thực ra comment không phải để giải thích code mà là code cũ không dùng nữa nên mình 'Ctrl + /' chứ không delete. Mình giải thích khi làm việc thực tế, khách hàng thường xuyên thay đổi yêu cầu, nên những đoạn code cũ không dùng chỉ nên comment lại, sau này có khi cần dùng. Nếu không thích thì mình delete hẳn code cũ. Tóm lại mình hỏi làm lại được không thì bên HR đồng ý. Mình cũng đề nghị bên ra đề nói rõ các tiêu chí, thích thế nào cứ nói rõ, mình sửa lại được hết, nhưng họ nói tiêu chí là bí mật, không lộ ra được và trả lời "Đề thế nào cứ làm như vậy"???!!! Khi mình tuyển dụng, mình luôn nghĩ rằng đang tìm đồng nghiệp để hợp tác. Trong thực tế làm việc cần phải trao đổi để hiểu rõ yêu cầu. Trong khi người ra đề tuyển dụng ở NVG có vẻ đang ra đề thi cho học sinh, rất thiếu tâm và tầm.
129
9
9
Trước Tết mình apply vị trí senior. Lương mong muốn 1600 USD. Còn đề là làm 1 ứng dụng, sử dụng các API có sẵn để load data và hiển thị lên list. Chỉ cần biết Retrofit, RecyclerView, ViewPager, có khả năng đọc hiểu tài liệu bằng tiếng Anh. Quan trọng là làm đúng ý người ra đề thôi. Hiện giờ mình làm tập đoàn khác lương 1800 rồi :v.
Bổ sung thêm. Bài test cho vị trí Senior thì họ tạo git và add account bạn vào, bạn làm và push code lên remote repo. Vì vậy nên biết sử dụng git. Trong lúc làm thì API bị giới hạn số lần request, phải tự vào website của github đọc hướng dẫn, tạo account để đăng ký và tạo chuỗi token cho app thì mới tăng giới hạn request lên được. Ngoài ra đọc thêm hướng dẫn sử dụng các API khá nhiều (đề không có hướng dẫn) Cho nên kỹ thuật thì dễ nhưng phải chịu khó tìm đọc hướng dẫn API.
Cám ơn bác bác cho em hỏi lương 1k8 là công ty nào được ko ạ.PHỏng vấn có khó không ạ.
Nói cụ thể không tiện. Vì sẽ lộ mức lương hiện tại của mình cho đồng nghiệp hoặc các công ty khác biết. Về phỏng vấn thì không làm bài test như NVG. Chỉ gặp phỏng vấn trực tiếp chừng hơn 1 tiếng, lúc đầu hỏi tiếng Anh, sau đó hỏi sâu quá nên cho nói tiếng Việt luôn. Mới đầu hỏi mấy thứ những thứ cơ bản hầu như dev nào cũng biết như Google Map, Firebase (clound, authentication), Facebook SDK, QR Code, Sau hỏi hỏi những dự án đã làm, kinh nghiệm làm việc, hỏi sâu về kỹ thuật, cách test phát hiện bug và fix bug liên quan các vấn đề sau: - Context - Activity/fragment lifecyle - Multithreading - Memory leak - Stack overflow - Service, IntentService, AIDL - Security. - Base64 - Checksum - Bitwise operator - Big number - Socket - Image processing - Linux, Kernel
Cám ơn bác ạ.
Bác cho em hỏi bác mấy năm exp rồi mà deal 1k8 ạ
Mình làm nhiều năm rồi mà lương chỉ có 1k8 nên cũng không tiện nói ra đâu. Nhưng mà mình 3x rồi nha.
Bác nói đúng vãi, tặng 1 like
Hay là do mình yếu kém quá nên bị người ta loại ra rồi tự ái lên đây khóc nhè? Tự like thêm cho đủ 11 like hả ? :))
Bạn ở trên chắc là lead của NVG bị bóc phốt. Những cái mình nêu có phản bác dc chút nào ko
Trình bạn có tới đâu cần mình phản bác làm cái éo gì ? =)))))))))))))))))))
Ko phản bác được gì rồi xạo xạo.
Kotlin đc giới thiệu từ 2017, mà bạn vẫn xài java. bạn cũng yêu java thật
Thế bạn đã làm custom Android, AOSP (Android Open Source Project) bao giờ chưa? Toàn dùng Java, C++. Giỏi thì dùng Kotlin custom Android xem. Java, kotlin đều cần, tùy trường hợp mà làm nhé.
Với lại kotlin tôi vẫn code được. Do đề ghi "Java hoặc Kotlin" chứ không có ghi ưu tiên Kotlin nên tôi chọn ngôn ngữ tôi đang làm hiện tại cho mấy dự án chính. Tôi cũng có nói nêu rõ yêu cầu rồi mới viết lại bài test mà NVG không chịu nêu rõ.
Kinh nghiệm nhiều, viết báo cáo khoa học, luận văn master mà fail cty này, nhục vậy sống sao :))
Đọc review thấy ứng viên này đúng mà. Quan trọng là cty đéo đủ tiền thuê hoặc nó đéo ưa nên nó chê bài thôi. Mà tầm cỡ vậy thì đôi co với HR làm gì, đầy chỗ tốt đẹp. Còn thằng cù loi kia kêu JAVa lỗi thời các kiểu thì cũng đủ hiểu trình của nó ko bằng ông ƯV này rồi
Thằng lz trên khích cc gì vậy, chắc lại là team member rr nào đó của nvg à.
Việc 1 người có experient java check qua kotlin quá easy thì việc gì phải sợ viết bằng ngôn ngữ nào??? vãi cả ko biết kotlin.
Mình ít chấm bài nhưng cũng có chấm 1 vài bài. Lên đây clarify với các bạn để mọi người có cái nhìn đa chiều. - Tổng điểm của các tiêu chí là 120. Tuy mình k thích kiểu chấm quá chi tiết thế này nhưng dù gì nó cũng phải có measurement rõ ràng để HR trust người chấm. - Nếu đạt từ 80/120 điểm là pass. - Kotlin hay Java rõ ràng không quan trọng vì nó chỉ chiếm 1 đến 2 điểm trên 120 điểm. Các bạn đừng focus vào những điểm rất nhỏ để đánh giá tổng thể, nó thể hiện các nhìn phiến diện và 1 phần mindset chưa thực sự tốt. Cũng như khi giải quyết 1 vấn đề, mình cần nhìn ở nhiều khía cạnh, từ technical craftsmanship cho tới product roadmap, expected outcome, user values, business impacts... Yêu cầu từ đề bài mình cho là khá rõ ràng, nếu bạn đã từng làm việc với khách hàng thì chắc không khó để hiểu được bên mình expect gì. Mình clarify luôn trên này là expectation ở đây focus khá nhiều vào clean code, architecture, maintainability, testability. Vì bên mình phát tri ển những products rất lớn đang leading marketplace platforms bên Thụy Sỹ, mức độ impact khá lớn. Tất cả các product đều đã stable, k phải startup, có rất nhiều users, thị trường khó tính; nhưng vẫn đang phát triển nhanh, thay đổi liên tục theo business và market changes, nên cần ADAPTABILITY tốt, để có thể thực sự AGILE. Còn về mức lương thì trên IT việc có đề range rất rõ ràng, không như các cty khác kiểu 1-3K mà thực tế là 1k2 :D. Nếu mình vẫn thấy không hiểu lắm expectation, và muốn trao đổi thêm thì bên mình rất rất welcome bạn tới tận nơi để gặp mặt trực tiếp trao đổi, nhưng đừng ngần ngại nói với HR bên mình. Quan điểm là tìm hiểu nhau coi có phù hợp không, chứ k hẳn là hỏi đáp. Fair 1 - 1 giữa interviewer và interviewee. Cheer, Duy
À thêm 1 điều nữa: bên mình khá serious về leadership skills, có 1 câu thế này: "giving problems, not solutions". Đề bài cần có độ mở đủ để ứng viên làm theo "bản năng" mới có thể đánh giá thực chất được.
đã hiểu, cảm ơn Duy
Yêu cầu nhiều vậy mà mức lương 1k2 thì...
Lương min 2k nhé bạn
Lương ở đây min là 1k6 nhé bạn
Câu trả lời của bạn Duy không thuyết phục. Những tiêu chí chấm bài của bạn không rõ ràng minh bạch trong đề bài. Ví dụ nhỏ, Kotlin 2 điểm Java 1 điểm, sao không nói rõ? Nếu nói rõ thì tôi viết bằng Kotlin rồi (Không phải như bạn nào nói là mình không biết kotlin. Mình biết Java, Kotlin, C++, và cả JS nhé). Vì đề không nêu rõ nên mình chọn Java là ngôn ngữ mà mình đang làm việc với khách hàng nhiều nhất. Ở trên chỉ là một ví dụ nhỏ thôi, còn lại rất nhiều tiêu chí "ngầm" mà đề hoàn toàn không nói tới. Ví dụ việc comment trong bài sẽ bị trừ điểm. Mình chưa gặp 1 dự án lớn nào mà không có comment trong source code. Mình cũng giải thích rằng việc bỏ comment cũng không ảnh hưởng tới ý nghĩa code, vì tôi viết code rất rõ ràng. Việc tôi comment chỉ để cho bạn chấm bài hiểu mình có thể làm cách khác, hoặc biết cách khác nhưng không tốt bằng cách hiện tại. Mình cũng giữ comment để lỡ bạn có thay đổi yêu cầu thì tôi dễ dàng thấy chỗ cần sửa. Trong team do mình quản lý, mình luôn yêu cầu m ember khi sửa code không tự ý xóa code cũ, mà chỉ comment lại, đều có mục đích cả. Nếu yêu cầu của bạn là không có comment, OK, nói trước mình làm theo. Lại ví dụ khác là phê bình không tối giản hóa, tách rõ view và data, mình đã đưa cho link sample về MVVM của Google không biết bạn đã xem chưa? Tóm lại, chưa biết tiêu chí của bạn đúng hay sai, nhưng việc không nói tới rồi apply vào việc chấm thì rõ ràng không thực tế. Bởi vì khi làm việc thì phải rõ ràng minh bạch, và khi có gì không hiểu thì phải trao đổi, hợp tác. Thật ra mình cũng không có vấn đề gì, vì thời điểm đó cách đây gần nửa năm mình pv nhiều cty và cũng không có thời gian làm lại bài test khi yêu cầu không rõ ràng minh bạch. Tuy nhiên sau khi vào làm chính thức rồi mình muốn vào đây để review lại cho ae dev nắm thông tin thôi.
Nãy quên trả lời vấn bạn Duy đề nghị trao đổi 1 - 1. Bạn đưa đề nghị này quá muộn, mình đã từng đề nghị với bạn nhân sự cho gặp bạn ra đề hoặc chấm đề để trao đổi làm rõ yêu cầu hoặc hỏi đáp. Nhưng bạn ấy trả lời rằng anh ra đề bảo "đề đã rõ ràng, có sao làm vậy". Chắc bạn không phải người chấm bài mình:v Bây giờ thì mình đã làm chính thức gần 3 tháng trong tập đoàn khác rồi.
Bác nói đúng vãi, tặng 1 like
Đồng ý ở chỗ không chịu hợp tác làm rõ vấn đề. Thua xa những công ty product có tiếng khác, muốn làm khó dễ hãy làm khó dễ ở vòng face to face chứ ba cái bài test sẽ không đánh giá 100% năng lực ứng viên.
Code đã comment lại vì ko dùng hiện tại thì nên xoá, ai cũng phòng ngờ thì project đều nhiều comment thì ko đc tốt, later mean never. Sr nếu làm bạn buồn, đây là ý kiến cá nhân thôi ạ.
Tôi nghĩ bạn nào thiếu kinh nghiệm làm dự án lớn, nhiều dev cùng code mới thích delete code cũ thay vì comment out. Có nhiều tình huống mà việc comment out code cũ rất có ích. Lấy 1 ví dụ, ngày hôm nay bạn viết 1 đoạn code tính năng A, vài ngày sau khách hàng đòi đổi tính năng A thành B, bạn chỉ nên comment đoạn code A lại và thêm một số ghi chú thay vì delete. Rất có thể một vài tháng sau khách hàng đòi đổi lại tính năng B. Lúc ấy thay vì bạn phải dùng git tool hoặc git command để dò lại thì bạn có thể dễ dàng bỏ comment code A, và comment code B lại. Rồi sau đó, có thể khách hàng lại yêu cầu đổi từ A sang B. Tôi đã từng gặp những tình huống như thế rồi. Chưa kể là khi bạn giao code cho người khác maintain, có thể họ không biết là bạn đã từng chuyển từ code A sang B trước đó. Nếu muốn code delete code cũ, bạn nên làm điều đó sau khi đã hoàn thành phase hiện tại khoảng 3 đến 6 tháng. Làm vậy bạn tránh phải ngồi code lại hoặc phải dò trên git history khi khách hàng đổi yêu cầu, rất mất thời gian.
Đã pv ở đây hên là không phải gặp mấy thằng Phỏng vấn kiểu thách đố nên lọt vào vòng cuối =)) xui cho bác thôi. Công ty nào chả có thằng that, thằng this, nó đã không ưa bác thì nó cũng đánh rớt thôi, vì làm chung không ưa đc thì sao làm tiếp đc . Giỏi thì thiếu gì công ty.
Quên chốt. Cuối cùng mình quyết định không làm lại bài test, vì họ không cho biết rõ tiêu chí mà lại có công ty lớn offer rồi.
Bài test android là gì cho em than khảo với bác.Có test giải thuật ko ạ.
Bác apply lead hay senior android ạ,rank lương là bao nhiêu vậy bác
Trước Tết mình apply vị trí senior. Lương mong muốn 1600 USD. Còn đề là làm 1 ứng dụng, sử dụng các API có sẵn để load data và hiển thị lên list. Chỉ cần biết Retrofit, RecyclerView, ViewPager, có khả năng đọc hiểu tài liệu bằng tiếng Anh. Quan trọng là làm đúng ý người ra đề thôi. Hiện giờ mình làm tập đoàn khác lương 1800 rồi :v.
Bổ sung thêm. Bài test cho vị trí Senior thì họ tạo git và add account bạn vào, bạn làm và push code lên remote repo. Vì vậy nên biết sử dụng git. Trong lúc làm thì API bị giới hạn số lần request, phải tự vào website của github đọc hướng dẫn, tạo account để đăng ký và tạo chuỗi token cho app thì mới tăng giới hạn request lên được. Ngoài ra đọc thêm hướng dẫn sử dụng các API khá nhiều (đề không có hướng dẫn) Cho nên kỹ thuật thì dễ nhưng phải chịu khó tìm đọc hướng dẫn API.
Cám ơn bác bác cho em hỏi lương 1k8 là công ty nào được ko ạ.PHỏng vấn có khó không ạ.
Nói cụ thể không tiện. Vì sẽ lộ mức lương hiện tại của mình cho đồng nghiệp hoặc các công ty khác biết. Về phỏng vấn thì không làm bài test như NVG. Chỉ gặp phỏng vấn trực tiếp chừng hơn 1 tiếng, lúc đầu hỏi tiếng Anh, sau đó hỏi sâu quá nên cho nói tiếng Việt luôn. Mới đầu hỏi mấy thứ những thứ cơ bản hầu như dev nào cũng biết như Google Map, Firebase (clound, authentication), Facebook SDK, QR Code, Sau hỏi hỏi những dự án đã làm, kinh nghiệm làm việc, hỏi sâu về kỹ thuật, cách test phát hiện bug và fix bug liên quan các vấn đề sau: - Context - Activity/fragment lifecyle - Multithreading - Memory leak - Stack overflow - Service, IntentService, AIDL - Security. - Base64 - Checksum - Bitwise operator - Big number - Socket - Image processing - Linux, Kernel
Cám ơn bác ạ.
Bác cho em hỏi bác mấy năm exp rồi mà deal 1k8 ạ
Mình làm nhiều năm rồi mà lương chỉ có 1k8 nên cũng không tiện nói ra đâu. Nhưng mà mình 3x rồi nha.
Bác nói đúng vãi, tặng 1 like
Hay là do mình yếu kém quá nên bị người ta loại ra rồi tự ái lên đây khóc nhè? Tự like thêm cho đủ 11 like hả ? :))
Bạn ở trên chắc là lead của NVG bị bóc phốt. Những cái mình nêu có phản bác dc chút nào ko
Trình bạn có tới đâu cần mình phản bác làm cái éo gì ? =)))))))))))))))))))
Ko phản bác được gì rồi xạo xạo.
Kotlin đc giới thiệu từ 2017, mà bạn vẫn xài java. bạn cũng yêu java thật
Thế bạn đã làm custom Android, AOSP (Android Open Source Project) bao giờ chưa? Toàn dùng Java, C++. Giỏi thì dùng Kotlin custom Android xem. Java, kotlin đều cần, tùy trường hợp mà làm nhé.
Với lại kotlin tôi vẫn code được. Do đề ghi "Java hoặc Kotlin" chứ không có ghi ưu tiên Kotlin nên tôi chọn ngôn ngữ tôi đang làm hiện tại cho mấy dự án chính. Tôi cũng có nói nêu rõ yêu cầu rồi mới viết lại bài test mà NVG không chịu nêu rõ.
Kinh nghiệm nhiều, viết báo cáo khoa học, luận văn master mà fail cty này, nhục vậy sống sao :))
Đọc review thấy ứng viên này đúng mà. Quan trọng là cty đéo đủ tiền thuê hoặc nó đéo ưa nên nó chê bài thôi. Mà tầm cỡ vậy thì đôi co với HR làm gì, đầy chỗ tốt đẹp. Còn thằng cù loi kia kêu JAVa lỗi thời các kiểu thì cũng đủ hiểu trình của nó ko bằng ông ƯV này rồi
Thằng lz trên khích cc gì vậy, chắc lại là team member rr nào đó của nvg à.
Việc 1 người có experient java check qua kotlin quá easy thì việc gì phải sợ viết bằng ngôn ngữ nào??? vãi cả ko biết kotlin.
Mình ít chấm bài nhưng cũng có chấm 1 vài bài. Lên đây clarify với các bạn để mọi người có cái nhìn đa chiều. - Tổng điểm của các tiêu chí là 120. Tuy mình k thích kiểu chấm quá chi tiết thế này nhưng dù gì nó cũng phải có measurement rõ ràng để HR trust người chấm. - Nếu đạt từ 80/120 điểm là pass. - Kotlin hay Java rõ ràng không quan trọng vì nó chỉ chiếm 1 đến 2 điểm trên 120 điểm. Các bạn đừng focus vào những điểm rất nhỏ để đánh giá tổng thể, nó thể hiện các nhìn phiến diện và 1 phần mindset chưa thực sự tốt. Cũng như khi giải quyết 1 vấn đề, mình cần nhìn ở nhiều khía cạnh, từ technical craftsmanship cho tới product roadmap, expected outcome, user values, business impacts... Yêu cầu từ đề bài mình cho là khá rõ ràng, nếu bạn đã từng làm việc với khách hàng thì chắc không khó để hiểu được bên mình expect gì. Mình clarify luôn trên này là expectation ở đây focus khá nhiều vào clean code, architecture, maintainability, testability. Vì bên mình phát tri ển những products rất lớn đang leading marketplace platforms bên Thụy Sỹ, mức độ impact khá lớn. Tất cả các product đều đã stable, k phải startup, có rất nhiều users, thị trường khó tính; nhưng vẫn đang phát triển nhanh, thay đổi liên tục theo business và market changes, nên cần ADAPTABILITY tốt, để có thể thực sự AGILE. Còn về mức lương thì trên IT việc có đề range rất rõ ràng, không như các cty khác kiểu 1-3K mà thực tế là 1k2 :D. Nếu mình vẫn thấy không hiểu lắm expectation, và muốn trao đổi thêm thì bên mình rất rất welcome bạn tới tận nơi để gặp mặt trực tiếp trao đổi, nhưng đừng ngần ngại nói với HR bên mình. Quan điểm là tìm hiểu nhau coi có phù hợp không, chứ k hẳn là hỏi đáp. Fair 1 - 1 giữa interviewer và interviewee. Cheer, Duy
À thêm 1 điều nữa: bên mình khá serious về leadership skills, có 1 câu thế này: "giving problems, not solutions". Đề bài cần có độ mở đủ để ứng viên làm theo "bản năng" mới có thể đánh giá thực chất được.
đã hiểu, cảm ơn Duy
Yêu cầu nhiều vậy mà mức lương 1k2 thì...
Lương min 2k nhé bạn
Lương ở đây min là 1k6 nhé bạn
Câu trả lời của bạn Duy không thuyết phục. Những tiêu chí chấm bài của bạn không rõ ràng minh bạch trong đề bài. Ví dụ nhỏ, Kotlin 2 điểm Java 1 điểm, sao không nói rõ? Nếu nói rõ thì tôi viết bằng Kotlin rồi (Không phải như bạn nào nói là mình không biết kotlin. Mình biết Java, Kotlin, C++, và cả JS nhé). Vì đề không nêu rõ nên mình chọn Java là ngôn ngữ mà mình đang làm việc với khách hàng nhiều nhất. Ở trên chỉ là một ví dụ nhỏ thôi, còn lại rất nhiều tiêu chí "ngầm" mà đề hoàn toàn không nói tới. Ví dụ việc comment trong bài sẽ bị trừ điểm. Mình chưa gặp 1 dự án lớn nào mà không có comment trong source code. Mình cũng giải thích rằng việc bỏ comment cũng không ảnh hưởng tới ý nghĩa code, vì tôi viết code rất rõ ràng. Việc tôi comment chỉ để cho bạn chấm bài hiểu mình có thể làm cách khác, hoặc biết cách khác nhưng không tốt bằng cách hiện tại. Mình cũng giữ comment để lỡ bạn có thay đổi yêu cầu thì tôi dễ dàng thấy chỗ cần sửa. Trong team do mình quản lý, mình luôn yêu cầu m ember khi sửa code không tự ý xóa code cũ, mà chỉ comment lại, đều có mục đích cả. Nếu yêu cầu của bạn là không có comment, OK, nói trước mình làm theo. Lại ví dụ khác là phê bình không tối giản hóa, tách rõ view và data, mình đã đưa cho link sample về MVVM của Google không biết bạn đã xem chưa? Tóm lại, chưa biết tiêu chí của bạn đúng hay sai, nhưng việc không nói tới rồi apply vào việc chấm thì rõ ràng không thực tế. Bởi vì khi làm việc thì phải rõ ràng minh bạch, và khi có gì không hiểu thì phải trao đổi, hợp tác. Thật ra mình cũng không có vấn đề gì, vì thời điểm đó cách đây gần nửa năm mình pv nhiều cty và cũng không có thời gian làm lại bài test khi yêu cầu không rõ ràng minh bạch. Tuy nhiên sau khi vào làm chính thức rồi mình muốn vào đây để review lại cho ae dev nắm thông tin thôi.
Nãy quên trả lời vấn bạn Duy đề nghị trao đổi 1 - 1. Bạn đưa đề nghị này quá muộn, mình đã từng đề nghị với bạn nhân sự cho gặp bạn ra đề hoặc chấm đề để trao đổi làm rõ yêu cầu hoặc hỏi đáp. Nhưng bạn ấy trả lời rằng anh ra đề bảo "đề đã rõ ràng, có sao làm vậy". Chắc bạn không phải người chấm bài mình:v Bây giờ thì mình đã làm chính thức gần 3 tháng trong tập đoàn khác rồi.
Bác nói đúng vãi, tặng 1 like
Đồng ý ở chỗ không chịu hợp tác làm rõ vấn đề. Thua xa những công ty product có tiếng khác, muốn làm khó dễ hãy làm khó dễ ở vòng face to face chứ ba cái bài test sẽ không đánh giá 100% năng lực ứng viên.
Code đã comment lại vì ko dùng hiện tại thì nên xoá, ai cũng phòng ngờ thì project đều nhiều comment thì ko đc tốt, later mean never. Sr nếu làm bạn buồn, đây là ý kiến cá nhân thôi ạ.
Tôi nghĩ bạn nào thiếu kinh nghiệm làm dự án lớn, nhiều dev cùng code mới thích delete code cũ thay vì comment out. Có nhiều tình huống mà việc comment out code cũ rất có ích. Lấy 1 ví dụ, ngày hôm nay bạn viết 1 đoạn code tính năng A, vài ngày sau khách hàng đòi đổi tính năng A thành B, bạn chỉ nên comment đoạn code A lại và thêm một số ghi chú thay vì delete. Rất có thể một vài tháng sau khách hàng đòi đổi lại tính năng B. Lúc ấy thay vì bạn phải dùng git tool hoặc git command để dò lại thì bạn có thể dễ dàng bỏ comment code A, và comment code B lại. Rồi sau đó, có thể khách hàng lại yêu cầu đổi từ A sang B. Tôi đã từng gặp những tình huống như thế rồi. Chưa kể là khi bạn giao code cho người khác maintain, có thể họ không biết là bạn đã từng chuyển từ code A sang B trước đó. Nếu muốn code delete code cũ, bạn nên làm điều đó sau khi đã hoàn thành phase hiện tại khoảng 3 đến 6 tháng. Làm vậy bạn tránh phải ngồi code lại hoặc phải dò trên git history khi khách hàng đổi yêu cầu, rất mất thời gian.
Đã pv ở đây hên là không phải gặp mấy thằng Phỏng vấn kiểu thách đố nên lọt vào vòng cuối =)) xui cho bác thôi. Công ty nào chả có thằng that, thằng this, nó đã không ưa bác thì nó cũng đánh rớt thôi, vì làm chung không ưa đc thì sao làm tiếp đc . Giỏi thì thiếu gì công ty.
Quên chốt. Cuối cùng mình quyết định không làm lại bài test, vì họ không cho biết rõ tiêu chí mà lại có công ty lớn offer rồi.
Bài test android là gì cho em than khảo với bác.Có test giải thuật ko ạ.
Bác apply lead hay senior android ạ,rank lương là bao nhiêu vậy bác
Trước Tết mình apply vị trí senior. Lương mong muốn 1600 USD. Còn đề là làm 1 ứng dụng, sử dụng các API có sẵn để load data và hiển thị lên list. Chỉ cần biết Retrofit, RecyclerView, ViewPager, có khả năng đọc hiểu tài liệu bằng tiếng Anh. Quan trọng là làm đúng ý người ra đề thôi. Hiện giờ mình làm tập đoàn khác lương 1800 rồi :v.
Bổ sung thêm. Bài test cho vị trí Senior thì họ tạo git và add account bạn vào, bạn làm và push code lên remote repo. Vì vậy nên biết sử dụng git. Trong lúc làm thì API bị giới hạn số lần request, phải tự vào website của github đọc hướng dẫn, tạo account để đăng ký và tạo chuỗi token cho app thì mới tăng giới hạn request lên được. Ngoài ra đọc thêm hướng dẫn sử dụng các API khá nhiều (đề không có hướng dẫn) Cho nên kỹ thuật thì dễ nhưng phải chịu khó tìm đọc hướng dẫn API.
Cám ơn bác bác cho em hỏi lương 1k8 là công ty nào được ko ạ.PHỏng vấn có khó không ạ.
Nói cụ thể không tiện. Vì sẽ lộ mức lương hiện tại của mình cho đồng nghiệp hoặc các công ty khác biết. Về phỏng vấn thì không làm bài test như NVG. Chỉ gặp phỏng vấn trực tiếp chừng hơn 1 tiếng, lúc đầu hỏi tiếng Anh, sau đó hỏi sâu quá nên cho nói tiếng Việt luôn. Mới đầu hỏi mấy thứ những thứ cơ bản hầu như dev nào cũng biết như Google Map, Firebase (clound, authentication), Facebook SDK, QR Code, Sau hỏi hỏi những dự án đã làm, kinh nghiệm làm việc, hỏi sâu về kỹ thuật, cách test phát hiện bug và fix bug liên quan các vấn đề sau: - Context - Activity/fragment lifecyle - Multithreading - Memory leak - Stack overflow - Service, IntentService, AIDL - Security. - Base64 - Checksum - Bitwise operator - Big number - Socket - Image processing - Linux, Kernel
Cám ơn bác ạ.
Bác cho em hỏi bác mấy năm exp rồi mà deal 1k8 ạ
Mình làm nhiều năm rồi mà lương chỉ có 1k8 nên cũng không tiện nói ra đâu. Nhưng mà mình 3x rồi nha.
Bác nói đúng vãi, tặng 1 like
Hay là do mình yếu kém quá nên bị người ta loại ra rồi tự ái lên đây khóc nhè? Tự like thêm cho đủ 11 like hả ? :))
Bạn ở trên chắc là lead của NVG bị bóc phốt. Những cái mình nêu có phản bác dc chút nào ko
Trình bạn có tới đâu cần mình phản bác làm cái éo gì ? =)))))))))))))))))))
Ko phản bác được gì rồi xạo xạo.
Kotlin đc giới thiệu từ 2017, mà bạn vẫn xài java. bạn cũng yêu java thật
Thế bạn đã làm custom Android, AOSP (Android Open Source Project) bao giờ chưa? Toàn dùng Java, C++. Giỏi thì dùng Kotlin custom Android xem. Java, kotlin đều cần, tùy trường hợp mà làm nhé.
Với lại kotlin tôi vẫn code được. Do đề ghi "Java hoặc Kotlin" chứ không có ghi ưu tiên Kotlin nên tôi chọn ngôn ngữ tôi đang làm hiện tại cho mấy dự án chính. Tôi cũng có nói nêu rõ yêu cầu rồi mới viết lại bài test mà NVG không chịu nêu rõ.
Kinh nghiệm nhiều, viết báo cáo khoa học, luận văn master mà fail cty này, nhục vậy sống sao :))
Đọc review thấy ứng viên này đúng mà. Quan trọng là cty đéo đủ tiền thuê hoặc nó đéo ưa nên nó chê bài thôi. Mà tầm cỡ vậy thì đôi co với HR làm gì, đầy chỗ tốt đẹp. Còn thằng cù loi kia kêu JAVa lỗi thời các kiểu thì cũng đủ hiểu trình của nó ko bằng ông ƯV này rồi
Thằng lz trên khích cc gì vậy, chắc lại là team member rr nào đó của nvg à.
Việc 1 người có experient java check qua kotlin quá easy thì việc gì phải sợ viết bằng ngôn ngữ nào??? vãi cả ko biết kotlin.
Mình ít chấm bài nhưng cũng có chấm 1 vài bài. Lên đây clarify với các bạn để mọi người có cái nhìn đa chiều. - Tổng điểm của các tiêu chí là 120. Tuy mình k thích kiểu chấm quá chi tiết thế này nhưng dù gì nó cũng phải có measurement rõ ràng để HR trust người chấm. - Nếu đạt từ 80/120 điểm là pass. - Kotlin hay Java rõ ràng không quan trọng vì nó chỉ chiếm 1 đến 2 điểm trên 120 điểm. Các bạn đừng focus vào những điểm rất nhỏ để đánh giá tổng thể, nó thể hiện các nhìn phiến diện và 1 phần mindset chưa thực sự tốt. Cũng như khi giải quyết 1 vấn đề, mình cần nhìn ở nhiều khía cạnh, từ technical craftsmanship cho tới product roadmap, expected outcome, user values, business impacts... Yêu cầu từ đề bài mình cho là khá rõ ràng, nếu bạn đã từng làm việc với khách hàng thì chắc không khó để hiểu được bên mình expect gì. Mình clarify luôn trên này là expectation ở đây focus khá nhiều vào clean code, architecture, maintainability, testability. Vì bên mình phát tri ển những products rất lớn đang leading marketplace platforms bên Thụy Sỹ, mức độ impact khá lớn. Tất cả các product đều đã stable, k phải startup, có rất nhiều users, thị trường khó tính; nhưng vẫn đang phát triển nhanh, thay đổi liên tục theo business và market changes, nên cần ADAPTABILITY tốt, để có thể thực sự AGILE. Còn về mức lương thì trên IT việc có đề range rất rõ ràng, không như các cty khác kiểu 1-3K mà thực tế là 1k2 :D. Nếu mình vẫn thấy không hiểu lắm expectation, và muốn trao đổi thêm thì bên mình rất rất welcome bạn tới tận nơi để gặp mặt trực tiếp trao đổi, nhưng đừng ngần ngại nói với HR bên mình. Quan điểm là tìm hiểu nhau coi có phù hợp không, chứ k hẳn là hỏi đáp. Fair 1 - 1 giữa interviewer và interviewee. Cheer, Duy
À thêm 1 điều nữa: bên mình khá serious về leadership skills, có 1 câu thế này: "giving problems, not solutions". Đề bài cần có độ mở đủ để ứng viên làm theo "bản năng" mới có thể đánh giá thực chất được.
đã hiểu, cảm ơn Duy
Yêu cầu nhiều vậy mà mức lương 1k2 thì...
Lương min 2k nhé bạn
Lương ở đây min là 1k6 nhé bạn
Câu trả lời của bạn Duy không thuyết phục. Những tiêu chí chấm bài của bạn không rõ ràng minh bạch trong đề bài. Ví dụ nhỏ, Kotlin 2 điểm Java 1 điểm, sao không nói rõ? Nếu nói rõ thì tôi viết bằng Kotlin rồi (Không phải như bạn nào nói là mình không biết kotlin. Mình biết Java, Kotlin, C++, và cả JS nhé). Vì đề không nêu rõ nên mình chọn Java là ngôn ngữ mà mình đang làm việc với khách hàng nhiều nhất. Ở trên chỉ là một ví dụ nhỏ thôi, còn lại rất nhiều tiêu chí "ngầm" mà đề hoàn toàn không nói tới. Ví dụ việc comment trong bài sẽ bị trừ điểm. Mình chưa gặp 1 dự án lớn nào mà không có comment trong source code. Mình cũng giải thích rằng việc bỏ comment cũng không ảnh hưởng tới ý nghĩa code, vì tôi viết code rất rõ ràng. Việc tôi comment chỉ để cho bạn chấm bài hiểu mình có thể làm cách khác, hoặc biết cách khác nhưng không tốt bằng cách hiện tại. Mình cũng giữ comment để lỡ bạn có thay đổi yêu cầu thì tôi dễ dàng thấy chỗ cần sửa. Trong team do mình quản lý, mình luôn yêu cầu m ember khi sửa code không tự ý xóa code cũ, mà chỉ comment lại, đều có mục đích cả. Nếu yêu cầu của bạn là không có comment, OK, nói trước mình làm theo. Lại ví dụ khác là phê bình không tối giản hóa, tách rõ view và data, mình đã đưa cho link sample về MVVM của Google không biết bạn đã xem chưa? Tóm lại, chưa biết tiêu chí của bạn đúng hay sai, nhưng việc không nói tới rồi apply vào việc chấm thì rõ ràng không thực tế. Bởi vì khi làm việc thì phải rõ ràng minh bạch, và khi có gì không hiểu thì phải trao đổi, hợp tác. Thật ra mình cũng không có vấn đề gì, vì thời điểm đó cách đây gần nửa năm mình pv nhiều cty và cũng không có thời gian làm lại bài test khi yêu cầu không rõ ràng minh bạch. Tuy nhiên sau khi vào làm chính thức rồi mình muốn vào đây để review lại cho ae dev nắm thông tin thôi.
Nãy quên trả lời vấn bạn Duy đề nghị trao đổi 1 - 1. Bạn đưa đề nghị này quá muộn, mình đã từng đề nghị với bạn nhân sự cho gặp bạn ra đề hoặc chấm đề để trao đổi làm rõ yêu cầu hoặc hỏi đáp. Nhưng bạn ấy trả lời rằng anh ra đề bảo "đề đã rõ ràng, có sao làm vậy". Chắc bạn không phải người chấm bài mình:v Bây giờ thì mình đã làm chính thức gần 3 tháng trong tập đoàn khác rồi.
Bác nói đúng vãi, tặng 1 like
Đồng ý ở chỗ không chịu hợp tác làm rõ vấn đề. Thua xa những công ty product có tiếng khác, muốn làm khó dễ hãy làm khó dễ ở vòng face to face chứ ba cái bài test sẽ không đánh giá 100% năng lực ứng viên.
Code đã comment lại vì ko dùng hiện tại thì nên xoá, ai cũng phòng ngờ thì project đều nhiều comment thì ko đc tốt, later mean never. Sr nếu làm bạn buồn, đây là ý kiến cá nhân thôi ạ.
Tôi nghĩ bạn nào thiếu kinh nghiệm làm dự án lớn, nhiều dev cùng code mới thích delete code cũ thay vì comment out. Có nhiều tình huống mà việc comment out code cũ rất có ích. Lấy 1 ví dụ, ngày hôm nay bạn viết 1 đoạn code tính năng A, vài ngày sau khách hàng đòi đổi tính năng A thành B, bạn chỉ nên comment đoạn code A lại và thêm một số ghi chú thay vì delete. Rất có thể một vài tháng sau khách hàng đòi đổi lại tính năng B. Lúc ấy thay vì bạn phải dùng git tool hoặc git command để dò lại thì bạn có thể dễ dàng bỏ comment code A, và comment code B lại. Rồi sau đó, có thể khách hàng lại yêu cầu đổi từ A sang B. Tôi đã từng gặp những tình huống như thế rồi. Chưa kể là khi bạn giao code cho người khác maintain, có thể họ không biết là bạn đã từng chuyển từ code A sang B trước đó. Nếu muốn code delete code cũ, bạn nên làm điều đó sau khi đã hoàn thành phase hiện tại khoảng 3 đến 6 tháng. Làm vậy bạn tránh phải ngồi code lại hoặc phải dò trên git history khi khách hàng đổi yêu cầu, rất mất thời gian.
Đã pv ở đây hên là không phải gặp mấy thằng Phỏng vấn kiểu thách đố nên lọt vào vòng cuối =)) xui cho bác thôi. Công ty nào chả có thằng that, thằng this, nó đã không ưa bác thì nó cũng đánh rớt thôi, vì làm chung không ưa đc thì sao làm tiếp đc . Giỏi thì thiếu gì công ty.
Quên chốt. Cuối cùng mình quyết định không làm lại bài test, vì họ không cho biết rõ tiêu chí mà lại có công ty lớn offer rồi.
Bài test android là gì cho em than khảo với bác.Có test giải thuật ko ạ.
Bác apply lead hay senior android ạ,rank lương là bao nhiêu vậy bác
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bạn có thê cho biết là tại NVG làm bài test Android như của bạn trong thời gian bao lâu ko? và làm tại company hay ở nhà? Thanks!
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bạn có thê cho biết là tại NVG làm bài test Android như của bạn trong thời gian bao lâu ko? và làm tại company hay ở nhà? Thanks!
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bạn có thê cho biết là tại NVG làm bài test Android như của bạn trong thời gian bao lâu ko? và làm tại company hay ở nhà? Thanks!
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Bác nói đúng vãi, tặng 1 like
Kiểu phỏng vấn này thì hên xui, đúng gu ông phỏng vấn thì pass, ngược lại có điểm gì đó không hợp cạ thì fail. Nói chung dạng công ty này tốt nhất đừng nên vào (nếu bạn cảm thấy khó hợp gu), vì trong lúc làm việc sẽ đụng chạm nhiều, trước sau gì ông không hợp gu cũng phải bật bãi thôi.
Đây là 1 cái cmt khá cũ nhưng phải nói là rất chi tiết và bổ ích, phải nói là thuộc hàng cực hiếm ở 1 trang chuyên chửi (dù mang tên là review :v) như trên đây Cmt của bạn này giúp củng cố chi mình 2 điều: 1/ Pv chắc chắc sẽ luôn có yếu tố hên xui (ko nhiều thì ít). Như hên gặp người có tâm thì rất dễ, người ta sẽ có cách đánh giá đúng còn ngược lại gặp dạng người thích đánh đố thì chắc dù có là ex-FAANG cũng tạch :)) 2/ Căn bản thì mấy cái conflict của bạn này và interviewer là do khác biệt về mindset, culture chứ ko có ai đúng hay sai hẳn nên nếu thấy ko hợp được culture (nói chung luôn chứ ko phải mỗi trường hợp bạn này) thì cũng mn ko nên vào, vào cty sẽ rất dễ có xích mích
Viết nhiều là like cái đã
Bác nói đúng vãi, tặng 1 like
Kiểu phỏng vấn này thì hên xui, đúng gu ông phỏng vấn thì pass, ngược lại có điểm gì đó không hợp cạ thì fail. Nói chung dạng công ty này tốt nhất đừng nên vào (nếu bạn cảm thấy khó hợp gu), vì trong lúc làm việc sẽ đụng chạm nhiều, trước sau gì ông không hợp gu cũng phải bật bãi thôi.
Đây là 1 cái cmt khá cũ nhưng phải nói là rất chi tiết và bổ ích, phải nói là thuộc hàng cực hiếm ở 1 trang chuyên chửi (dù mang tên là review :v) như trên đây Cmt của bạn này giúp củng cố chi mình 2 điều: 1/ Pv chắc chắc sẽ luôn có yếu tố hên xui (ko nhiều thì ít). Như hên gặp người có tâm thì rất dễ, người ta sẽ có cách đánh giá đúng còn ngược lại gặp dạng người thích đánh đố thì chắc dù có là ex-FAANG cũng tạch :)) 2/ Căn bản thì mấy cái conflict của bạn này và interviewer là do khác biệt về mindset, culture chứ ko có ai đúng hay sai hẳn nên nếu thấy ko hợp được culture (nói chung luôn chứ ko phải mỗi trường hợp bạn này) thì cũng mn ko nên vào, vào cty sẽ rất dễ có xích mích
Viết nhiều là like cái đã
Bác nói đúng vãi, tặng 1 like
Kiểu phỏng vấn này thì hên xui, đúng gu ông phỏng vấn thì pass, ngược lại có điểm gì đó không hợp cạ thì fail. Nói chung dạng công ty này tốt nhất đừng nên vào (nếu bạn cảm thấy khó hợp gu), vì trong lúc làm việc sẽ đụng chạm nhiều, trước sau gì ông không hợp gu cũng phải bật bãi thôi.
Đây là 1 cái cmt khá cũ nhưng phải nói là rất chi tiết và bổ ích, phải nói là thuộc hàng cực hiếm ở 1 trang chuyên chửi (dù mang tên là review :v) như trên đây Cmt của bạn này giúp củng cố chi mình 2 điều: 1/ Pv chắc chắc sẽ luôn có yếu tố hên xui (ko nhiều thì ít). Như hên gặp người có tâm thì rất dễ, người ta sẽ có cách đánh giá đúng còn ngược lại gặp dạng người thích đánh đố thì chắc dù có là ex-FAANG cũng tạch :)) 2/ Căn bản thì mấy cái conflict của bạn này và interviewer là do khác biệt về mindset, culture chứ ko có ai đúng hay sai hẳn nên nếu thấy ko hợp được culture (nói chung luôn chứ ko phải mỗi trường hợp bạn này) thì cũng mn ko nên vào, vào cty sẽ rất dễ có xích mích
Viết nhiều là like cái đã
Thời nào rồi còn phân biệt ngôn ngữ lập trình và bắt lỗi mấy cái nhỏ nhặt như commented code, đúng mấy thằng tuyển dụng trẻ ranh, ng* dốt. Người ta review tử tế lại còn vào seeding trả đũa nữa. Tránh xa kiểu văn hoá công ty này ra.
Sorry, bấm nhầm "Dislike", trả lại bằng "Like".
Thời nào rồi còn phân biệt ngôn ngữ lập trình và bắt lỗi mấy cái nhỏ nhặt như commented code, đúng mấy thằng tuyển dụng trẻ ranh, ng* dốt. Người ta review tử tế lại còn vào seeding trả đũa nữa. Tránh xa kiểu văn hoá công ty này ra.
Sorry, bấm nhầm "Dislike", trả lại bằng "Like".
Thời nào rồi còn phân biệt ngôn ngữ lập trình và bắt lỗi mấy cái nhỏ nhặt như commented code, đúng mấy thằng tuyển dụng trẻ ranh, ng* dốt. Người ta review tử tế lại còn vào seeding trả đũa nữa. Tránh xa kiểu văn hoá công ty này ra.
Sorry, bấm nhầm "Dislike", trả lại bằng "Like".
