Tôi tiếp tục thất bại trong một phần của cuộc phỏng vấn, đề nghị? [đóng cửa]


13

Vì vậy, tôi có một vài phần mềm / trang web trong danh mục đầu tư của tôi. Họ kiếm tiền nhưng không phải là toàn bộ.

Vì vậy, tôi quyết định nhận một số kinh nghiệm công việc, chủ yếu áp dụng cho các vị trí phát triển cơ sở Java / PHP.

Vấn đề là tôi trả lời đúng tất cả các câu hỏi kỹ thuật và chúng tôi lên lịch để thực hiện một "bài kiểm tra" mã hóa, giai đoạn cuối của cuộc phỏng vấn. Tôi không bao giờ có thể thư giãn và suy nghĩ quá nhiều và cuối cùng làm bài kiểm tra rất chậm. HOẶC đôi khi tôi chỉ đánh một khối và cảm thấy rất khó để suy nghĩ trên đôi chân của mình.

Tôi không hiểu điều này bởi vì những thứ khác tôi đã viết đang giải quyết các vấn đề phức tạp hơn nhiều trong khi "Thử nghiệm" thực sự đơn giản một cách tàn bạo như viết và kiểm tra palindrom.

Những lần khác, họ sẽ cho tôi một bài kiểm tra logic với các luồng đến các phép toán và một lần nữa tôi sẽ không thể làm điều đó trong thời gian họ giao.

Tôi biết tôi có thể viết phần mềm / trang web có thể bán được, có thể tạo doanh thu nhỏ và tìm cách giải quyết vấn đề nhưng tôi gặp khó khăn lớn với các bài kiểm tra mã hóa đơn giản trong các cuộc phỏng vấn.

Bất kỳ đề xuất?



Rõ ràng ít nhất bạn nghĩ rằng các bài kiểm tra phỏng vấn có thể đơn giản, nhưng có vẻ như bạn không đơn độc khi gặp rắc rối với các bài kiểm tra này: infoworld.com/d/application-development/ Lỗi
Một số lập trình viên dude

2
Tôi phải không đồng ý với liên kết này. Với sự khác biệt giữa một nhà phát triển tốt và một người xấu, bạn thực sự muốn mạo hiểm với một số ứng cử viên tốt hơn là nhận được những người xấu.
deadalnix

7
@deadalnix Tôi không đồng ý với sự bất đồng của bạn. :-) Tôi đã thấy đủ các lập trình viên giỏi bỏ qua các bài kiểm tra và các lập trình viên xấu vượt qua các bài kiểm tra mà tôi nghĩ rằng kiểm tra không hữu ích và thường phản tác dụng. IMO, tất cả những gì họ làm là làm cho người phỏng vấn / nhân sự cảm thấy tốt.
Brian Knoblauch

2
@BJoachim và tất cả: nếu bạn đọc qua các đoạn đầu tiên trong liên kết đó, thì thực sự lời khuyên tốt về việc giữ các bài kiểm tra có liên quan và hữu ích: không nói các bài kiểm tra là vô ích.
MarkJ

Câu trả lời:


18

Tiếp tục tham dự các cuộc phỏng vấn. Cuối cùng bạn sẽ tìm thấy một nơi sẽ đặt câu hỏi phù hợp hơn với thế mạnh của bạn. Bạn cũng sẽ trở nên tốt hơn và thoải mái hơn với việc phỏng vấn, điều này chỉ có thể giúp đỡ. Hãy xem nó như một trò chơi, bởi vì đó thực sự là những gì nó được. Tiếp tục chơi và cuối cùng bạn sẽ thắng.


2
Tôi không nghĩ đó là vấn đề công đức / nội dung của các câu hỏi, chỉ là điều kiện của câu trả lời. Tôi đã viết sai bool isPalindrome(string)bởi vì tôi đã viết nó trên giấy, trong một thời gian giới hạn (trong 15 phút?). Đưa ra một trình soạn thảo văn bản và không giới hạn thời gian, tôi tin rằng tôi có thể làm điều đó một cách hoàn hảo dưới một phút.
SF.

9
@SF: bạn đã thử nó sau cuộc phỏng vấn? nó đã mất bao lâu?
kevin cline

2
Cũng tiếp tục thực hành làm việc trên các điểm yếu của bạn. Trong trường hợp này, tìm những vấn đề nhỏ, tương tự và thời gian tự mình giải quyết chúng trên giấy. Thực hành để có được một cái gì đó làm việc đầu tiên (ngay cả khi nó sai) sau đó lặp đi lặp lại thông qua làm cho nó đúng. Bằng cách đó bạn có thể cho thấy quá trình suy nghĩ của bạn như là một phần của cuộc phỏng vấn. Có vẻ như đây là kỹ năng lớn nhất mà bạn thiếu (ngay bây giờ) có thể cung cấp tối thiểu ngay bây giờ, sau đó cải thiện nó theo thời gian. Nhiều doanh nghiệp thích điều này :-)
Al Biglan

Chỉ thấy điều này được liên kết từ slashdot; phần nào liên quan: infoworld.com/d/application-development/ trên
Kevin Hsu

Nếu vấn đề là bạn không thể lập trình trên giấy, thì đó là một vấn đề thực sự theo ý kiến ​​của tôi. "isPalindrom" không cần bất kỳ lệnh gọi API hay tính năng ngôn ngữ tối nghĩa nào; bạn sẽ có thể tạo một chương trình có thể biên dịch như thế mà không có lợi ích intellisense hoặc IDE.
Eoin Carroll

12

Điều này rất phổ biến. Hầu hết các lập trình viên có thể lập trình hiệu quả khi họ ở trong vùng thoải mái của họ. Ví dụ: tôi chỉ có thể làm việc trên Ubuntu, với vim, nếu tôi không có không gian làm việc đó, tôi sẽ không cảm thấy như lập trình. Tôi cũng yêu cầu , ở một mức độ nào đó Google để nghiên cứu.

Tôi chắc chắn rằng bạn đã phát triển một số vùng thoải mái để lập trình. Tôi muốn giới thiệu, làm quen với môi trường nơi một người nào đó đứng sau bạn chờ mã của họ được hoàn thành. Cách tốt nhất để làm quen với nó là tiếp tục đi phỏng vấn.

Bạn có thể nghĩ rằng nó không có nhiều tác động, và nó có thể không. Nhưng đối với một số người trong chúng ta ngoài kia, lập trình với âm nhạc hoặc không, sử dụng IDE hoặc trình soạn thảo văn bản đơn giản, sử dụng ghế gỗ hoặc ngồi trên ghế sofa, phòng tối hoặc phòng sáng ... tạo ra sự khác biệt lớn trong sự phát triển của chúng tôi tốc độ.

Lưu ý, một khi bạn nhận được công việc, bạn thường có thể tạo vùng thoải mái của riêng bạn trong không gian văn phòng họ cung cấp cho bạn.

EDIT : Câu hỏi này nhắc nhở tôi với một nhân viên bán hàng, hỏi làm thế nào để có được sự thoải mái và tốt hơn khi gọi điện lạnh. Câu trả lời tốt nhất là tiếp tục thực hiện cuộc gọi lạnh và suy ngẫm về từng cuộc gọi. Sau một thời gian, người bán hàng cải thiện kỹ năng và sự thoải mái của họ. Tôi nghĩ lập trình viên không khác gì khi tham dự các cuộc phỏng vấn, sau tất cả những điểm chính là bán mình cho người phỏng vấn


Ai là ai? Sinh đôi xinh đẹp của Sophie?
uɐɪ

@Rick: thật không may, là một người phỏng vấn, tôi không thể nói với ai đó rằng họ là một lập trình viên hiệu quả. Tôi cần phải thấy rằng họ thực sự có thể lập trình. Không báo cáo kinh nghiệm, hoặc GPA, hoặc chứng nhận, hoặc mẫu mã có thể cho tôi biết điều đó. Tôi cần phải xem các ứng cử viên làm một số chương trình.
kevin cline

@kevincline Tôi đồng ý, đó là lý do tại sao tôi khuyên anh ấy tiếp tục đi phỏng vấn và làm quen với những người phỏng vấn như mình.
Rick Rhodes

6

Đây chỉ là đề xuất của tôi, tại sao không thử làm một doanh nhân. Có thể có nhiều người phải đối mặt với vấn đề tương tự. Nếu bạn có thể viết các trang web cho doanh thu nhỏ thì chắc chắn bạn có thể kiếm được lớn từ nó.


1
+1, và một tinh thần tùy tùng có thể được coi là một phẩm chất rất tích cực.
maple_shaft

5

Bạn đã xác định được vấn đề của bạn là gì - giải quyết vấn đề dưới áp lực (ei khi ai đó đang theo dõi bạn). Có phải vì bạn thiếu tự tin hoặc bạn không có đủ kinh nghiệm hoặc bạn bị áp lực?

Đi đến rất nhiều cuộc phỏng vấn để có được một số kinh nghiệm và thực hành có thể là một ý tưởng tốt nhưng cũng có thể tạo ra hiệu ứng ngược. Thất bại liên tục trong các cuộc phỏng vấn có thể làm lung lay sự tự tin của bạn hơn nữa, vì vậy hãy cẩn thận.

Tôi sẽ đề nghị bạn thử lập trình ngang hàng để bạn có thể thoải mái giải quyết vấn đề khi ai đó đang theo dõi bạn. Ngoài ra, hãy cố gắng tìm ra điều gì ngăn bạn khỏi hiệu quả dưới áp lực (đó là căng thẳng từ chính thử nghiệm thực tế, căng thẳng do làm việc dưới sự giám sát chặt chẽ, căng thẳng do làm việc trong một giới hạn thời gian cụ thể, v.v.).


1
Bạn cũng nên google lên một số loại câu hỏi kiểm tra. In chúng ra theo cách bạn có được chúng trong một cuộc phỏng vấn và giải quyết chúng. Ngồi vào bàn không phải máy tính của bạn. Bạn cần cố gắng và tạo lại áp lực của cuộc phỏng vấn.
Bill Leeper

3

Nghe có vẻ như bạn bị sặc dưới áp lực. Vì bạn phải thực hiện các ví dụ được định thời như một phần của quy trình phỏng vấn, bạn sẽ phải học cách vượt qua điều này. Đây là tất cả về quản lý nỗi sợ, không phải về kỹ năng lập trình.

Một lựa chọn sẽ là thực hành viết các vấn đề mẫu và thời gian cho chính bạn. Một khi bạn biết rằng bạn có thể thực hiện chúng dưới mười phút, bạn có thể sợ bị hẹn giờ ít hơn.

Một lựa chọn khác là đưa ra một kỹ thuật để làm dịu nỗi sợ hãi của bạn và sử dụng nó để tự làm mình nghẹt thở. Học một kỹ thuật thiền có thể giúp bạn. Hoặc ghi nhớ litany chống lại nỗi sợ hãi (từ Dune .) Tìm hiểu một số loại mẹo để giảm phản ứng sợ hãi của bạn.


3

Tôi khá ngạc nhiên khi chưa có ai hỏi điều này, nhưng làm thế nào để bạn tiếp cận các nhiệm vụ lập trình ?

Nếu bạn chỉ đơn giản là nhảy vào mã, thì rất có thể bạn sẽ bị lạc và cuối cùng mắc phải những lỗi đơn giản và khiến bản thân bối rối. Bước từng bước một:

  1. Thu thập các yêu cầu : Chính xác thì đó là gì mà người phỏng vấn của bạn đang hỏi. Hãy chắc chắn rằng có zero câu hỏi lên trong không khí trước khi mã hóa. Ví dụ: nếu đối mặt với câu hỏi "isPalindrom" cũ, hãy hỏi những câu như "nếu chuỗi có ký tự đặc biệt thì sao?" hoặc "các chuỗi có độ dài lẻ như 'ada' được tính là palindromes?". Bạn cần biết cách làm rõ các yêu cầu trước khi thiết kế một thuật toán.
  2. Thiết kế thuật toán của bạn : Chia nó thành các phần hợp lý nếu nó hợp lý. Nói về nó .. Có thể viết một số mã giả nếu bạn đang viết bảng trắng. Đi bộ phỏng vấn của bạn thông qua các bước của bạn. Hãy thử chạy qua nó với một vài đầu vào khác nhau (cả hợp lệ và không hợp lệ) để đảm bảo bạn nhận được kết quả mong muốn.
  3. Bây giờ bắt đầu viết mã : Đến thời điểm này, bạn nên rất tự tin vào những gì bạn sắp viết. Về cơ bản, bạn chỉ nên trải qua các chuyển động với bất kỳ ngôn ngữ nào bạn quen thuộc. Tại thời điểm này, sẽ không có vấn đề gì nếu có lỗi cú pháp vì người phỏng vấn đáng đồng tiền sẽ tha thứ cho những người trong phiên thảo luận trắng (nếu bạn được cấp PC / IDE để giải quyết vấn đề trên, đó là một câu chuyện khác).

Thực sự, khi giải quyết các vấn đề về mã hóa, một người phỏng vấn không tìm kiếm quá nhiều cho mã tuyệt vời .. Đó là nhiều hơn để xem cách bạn giải quyết một vấn đề nhất định. Lặn thẳng vào mã là một điều xấu, thời gian.

Bạn cũng sẽ thấy rằng khi bạn nói về vấn đề (thu thập và thiết kế yêu cầu), bạn sẽ thấy thoải mái hơn một chút và ít có khả năng mắc lỗi ngớ ngẩn trong phần mã hóa.


3

Dự án Euler

Dường như với tôi rằng bạn đang thất bại với fizzbuz bài kiểm tra . Lưu ý các thuật toán đơn giản thường không phục vụ bất kỳ mục đích thực tế nào ngoại trừ xác định xem bạn có hiểu các khái niệm cốt lõi của lập trình hay không.

Chải lên những điều cơ bản của bạn

Những gì tôi muốn giới thiệu là bạn tiếp tục những điều cơ bản của bạn.

http://projecteuler.net/

Đăng ký và bắt đầu thực hành, bạn sẽ thấy rằng bằng cách xem qua các ví dụ đó, bạn sẽ hiểu sâu hơn về các khái niệm lập trình cốt lõi. Tôi nghĩ rằng bạn sẽ tìm thấy một câu hỏi nhạt nhẽo trong đó cùng với các chuỗi của Wikipedia và các khái niệm toán học khác (nghe có vẻ quen thuộc).


2

Yêu cầu phản hồi tại hoặc sau cuộc phỏng vấn. Họ đã thích gì? Họ đã không thích điều gì? Bạn có thể ngạc nhiên với câu trả lời.

Những người khác nhau tìm kiếm những thứ khác nhau, tất nhiên, nhưng cách bạn cố gắng giải quyết vấn đề thường quan trọng hơn là viết một giải pháp đúng 100%. Bạn có thể lo lắng về tất cả những điều sai trái.

Cách tốt nhất để cải thiện mọi thứ là luyện tập. Hãy thử viết ra một danh sách các vấn đề ngắn. Sau đó, đối với mỗi mục trong danh sách, hãy viết một chương trình nhỏ để giải quyết vấn đề. Bắt đầu với những vấn đề rất dễ dàng, như FizzBuzz , và khắc phục khó khăn khi bạn đi. Bạn có thể giải quyết các vấn đề mà bạn đã thấy trong các cuộc phỏng vấn trước đây không? Tìm chuỗi con lớn nhất mà hai chuỗi có điểm chung? Tính hệ số nguyên tố của n!?

Ý tưởng không phải là tìm ra giải pháp cho mọi vấn đề bạn có thể gặp phải, mà là hãy nhanh chóng thực hiện việc viết các chương trình nhỏ và tìm ra điểm yếu của bạn để bạn có thể cải thiện. Nhiều vấn đề rất dễ giải quyết với cấu trúc dữ liệu phù hợp, nhưng khó khăn khác, vì vậy hãy chắc chắn rằng bạn đã có một nền tảng vững chắc trong cấu trúc dữ liệu.


2

Thực hành và tìm ai đó để giúp hướng dẫn bạn thông qua những điều cơ bản về cách vượt qua nó. Nó có thể mất một vài lần thử nhưng có thể đáng ngạc nhiên những gì sẽ được khám phá nếu bạn có thể nhận được một số phản hồi và thực hành về điều này. Tôi đã có một nhà tuyển dụng hướng dẫn tôi cách xử lý vấn đề bảng trắng một lần có vẻ giống với vấn đề của bạn ở đây.

Tôi không gợi ý việc ghi nhớ các câu trả lời nhiều như nó đang có một kế hoạch chi tiết phải làm gì khi đưa ra một vấn đề như vậy và làm thế nào để giải quyết nó. điều này như thế nào? Bạn đã thấy vấn đề tương tự? Một số cách tiếp cận đơn giản có thể mang lại điều gì về thuật toán? Ít nhất đó là đề nghị của tôi cho bạn.


2

Điều khá phổ biến đối với các nhà phát triển phần mềm là lúng túng khi được yêu cầu ngồi kiểm tra mã hóa hoặc viết một đoạn mã nhỏ trong cuộc phỏng vấn. Như ai đó đã đề cập, đó là bởi vì hầu hết chúng ta chỉ có thể viết mã khi chúng ta ở trong "vùng thoải mái" và ngồi trong một căn phòng nhỏ, được bao quanh bởi 2-5 người phỏng vấn không thực sự thêm nhiều sự thoải mái.

Câu trả lời là ba lần:

  • thực hành, và thực hành nhiều hơn cố gắng trong một tháng thực hiện 30 - 40 phút lập trình bằng giấy và bút và bạn sẽ ngạc nhiên về việc nó sẽ trở nên dễ dàng như thế nào. Trong khi thực hành - hãy thử loại nhiệm vụ lập trình mà bạn mong muốn được yêu cầu trong các phiên mã hóa phỏng vấn - ví dụ: thực hiện một chuỗi đơn, đảo ngược chuỗi, v.v ... Điều đó còn dễ dàng hơn với "đọc đoạn mã rác đó và tìm ra lỗi sai "- hãy thử in và họ phân tích các bản in này trong hai tuần và bạn sẽ cải thiện đáng kể kỹ năng đó.

  • học cách kiểm soát nỗi sợ hãi của bạn nếu bạn nghĩ rằng bài kiểm tra quá khó và bạn chỉ có thể hoàn thành 20% trong số đó - hãy làm 20% đó, đừng lo lắng về phần còn lại. Có thể là bài kiểm tra rất lớn một cách vô lý trong thời gian được thực hiện (ví dụ: những người trong cuộc phỏng vấn phải cho bạn 20 phút để hoàn thành nó nhưng họ cần kết thúc cuộc phỏng vấn trong 5 phút vì một số vụ nổ sản xuất, v.v.) . Cũng có thể các ứng cử viên khác chỉ hoàn thành bài kiểm tra 10%, vì vậy bằng cách hoàn thành 20%, bạn vẫn sẽ đi trước các ứng cử viên khác.

  • Khi viết mã khi phỏng vấn - đừng bận tâm làm cho nó hoàn hảo trong lần đầu tiên. chỉ thực hiện một "đường dẫn hạnh phúc hay còn gọi là kịch bản phổ biến nhất trước tiên" và bận tâm đến việc xử lý lỗi sau này. nếu bạn sắp hết thời gian - chỉ cần thêm một ghi chú nhanh ở cuối bảng phác thảo - những gì bạn sẽ làm để cải thiện mã nếu bạn có nhiều thời gian hơn.

[phải chạy, sẽ chỉnh sửa / cải thiện câu trả lời của tôi sau]


1

Như nhiều người đã nói tôi luyện tập là một trong những điều quan trọng nhất. Nếu bạn đã thực hiện một vấn đề tương tự, bạn sẽ có thể đưa ra giải pháp nhanh chóng.

Nếu bạn gặp khó khăn trong việc đưa ra các vấn đề để tự mình thử và giải quyết, hãy sử dụng tìm kiếm Google cho các câu hỏi phỏng vấn lập trình cho ngôn ngữ hoặc lựa chọn của bạn.

Ngoài ra, bạn có thể chọn những cuốn sách được thiết kế để dạy các khóa học CS cấp thấp hơn. Hầu hết những cuốn sách này chứa đầy các bài tập lập trình nhỏ và có thể được thực hiện nhanh chóng ở nhà. Chúng có thể được sử dụng để thực hành.


0

Tôi cũng rất tệ trong các bài kiểm tra và luôn luôn như vậy. Cả đời tôi không thể tìm ra lý do tại sao một lớp lập trình được đưa cho tôi các bài kiểm tra để thực hiện bằng bút chì và giấy. Tôi không bao giờ có được nó tốt. Tuy nhiên, những gì tôi đã làm là giải thích cho những người phỏng vấn rằng tôi có vấn đề này và biết về nó. Tôi cũng đã xoay sở để phỏng vấn cho các công ty không cho tôi những bài kiểm tra ngớ ngẩn.

Đề nghị của tôi là nói với công ty trước khi bạn đi phỏng vấn rằng bạn không làm như vậy với các loại thử nghiệm đó, tuy nhiên thay vào đó bạn rất vui với X. (Tìm ra một giải pháp thay thế hợp lý và bạn cảm thấy thoải mái khi thực hiện.) Đối với bản thân tôi, tôi đã đề nghị gửi mã cho họ và một lần tôi đề nghị họ đưa cho tôi một chương trình đơn giản để viết và tôi sẽ mang nó đến cho tôi phỏng vấn trong thời gian 3 ngày.

Tùy thuộc vào nơi bạn đang tìm kiếm việc làm, điều này có thể hoặc không thể làm việc cho bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.