Tôi đã thất bại FizzBuzz, bạn sẽ thuê tôi chứ? [đóng cửa]

Tôi là một nhà phát triển có bằng CS và có kinh nghiệm làm việc về phát triển một số ngôn ngữ trong gần 3 năm.

Hôm nay tôi đã có một cuộc phỏng vấn, nói chung nó diễn ra khá tốt, tôi đã chuẩn bị cho hầu hết các câu hỏi và cảm thấy sẵn sàng cho mọi thứ. Vào cuối cuộc phỏng vấn, họ đã đưa cho tôi MỘT câu hỏi lập trình ... một vấn đề như FizzBuzz (không có phần in số). Tôi tin rằng tôi đã phạm quá nhiều sai lầm và do đó đã "thất bại". Là tất cả hy vọng đã mất cho tôi?

Đây là mã của tôi:

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

Như bạn có thể thấy tôi đã làm rối các bool nên có cú pháp i% 3 == 0; Nếu tôi nhớ đúng câu hỏi, tôi cũng đặt một câu hỏi khác thay vì câu trả lời khác bằng isThree && isFive. Tôi đã khá căng thẳng, nhưng đó không phải là lý do để bỏ lỡ một vấn đề đơn giản.

Vì vậy, câu hỏi là, làm thế nào quan trọng là có thể tạo ra mã làm việc tại chỗ so với các yếu tố khác, chẳng hạn như kinh nghiệm và tính cách? Ví dụ, mã trên sẽ là một công cụ thỏa thuận?

Quan điểm của FizzBuzz là cho thấy rằng bạn thực sự biết cách lập trình , chứ không phải bạn đã ghi nhớ tất cả các quy tắc cú pháp tốt hơn của ngôn ngữ mà bạn được yêu cầu lập trình (mặc dù điều đó quan trọng, nếu họ muốn biết có kinh nghiệm như thế nào bạn đang ở trong ngôn ngữ)

Nếu bạn gặp vấn đề này trong môi trường phỏng vấn và có thể cho thấy rằng bạn hiểu các lỗi mà bạn đã gây ra, tôi sẽ nói bạn đã vượt qua.

Vâng

Hầu hết những người tôi đã phỏng vấn đã thất bại trong phần bài tập mã về cú pháp nhỏ hoặc logic hơi tắt cuối cùng là những người tuyển dụng tốt hơn.

Làm cho ý tưởng cốt lõi của logic trở nên thẳng thắn (mà bạn đã làm) và chuyển đổi nó thành một cái gì đó đàng hoàng và súc tích từ quan điểm mã (mà tôi nghĩ rằng bạn hầu hết đã làm) đối với tôi hoàn toàn quan trọng hơn là làm cho nó hoàn hảo.

Tôi mua một IDE để kiểm tra cú pháp không thuê một nhà phát triển cho nó và bạn sẽ nhận ra những lỗi khác trong giây lát của lần gỡ lỗi đầu tiên.

Bạn đã đi từ yêu cầu ban đầu đến lần thử đầu tiên khá trực tiếp và không làm điều gì ghê gớm. Điều đó có giá trị hơn trong nhiều môi trường sau đó là sự hoàn hảo khi không có phản hồi. Nếu nhà tuyển dụng treo lên những chi tiết bạn bỏ lỡ thì đó có thể là dấu hiệu của môi trường sắp tới.

Nếu tác vụ là biến thể số in, thiếu chi tiết sẽ trông hơi tệ, nhưng nó sẽ không đủ sức nặng để thay đổi quyết định của tôi nếu tôi thích bạn cho vị trí khác.

[Chỉnh sửa] Như Alex chỉ ra, cũng có khía cạnh phản ứng và bình tĩnh. Cá nhân tôi cố gắng giải quyết vấn đề đó trước khi đến với các bài tập thực tế bằng cách cố gắng đưa người được phỏng vấn vào một cái gì đó ngoài kinh nghiệm của họ nhưng một số người có thể chọn kết hợp cả hai. Thỉnh thoảng tôi tình cờ gặp một người chỉ có kiến ​​thức trong sách giáo khoa và họ lướt qua các vấn đề lý thuyết và lý lịch nhưng nghiêm túc bị treo lên về nơi bắt đầu với bài tập thực hành. Một số thậm chí không thể tìm ra nơi để bắt đầu.

Những cá nhân này chính xác là những gì tôi muốn loại bỏ với bài tập này.

Vì vậy, trừ khi bạn mất 20 phút để làm cho người phỏng vấn làm rõ yêu cầu, tôi tưởng tượng giải pháp của bạn ít nhiều là nỗ lực đầu tiên của bạn với một vài sửa chữa khi bạn đi. Nếu bạn có những gì bạn đặt ở trên dưới 5 phút, bạn cho thấy bạn có thể nghĩ đủ cho tiêu chuẩn của tôi.

Đoạn mã trên có lẽ sẽ là một công cụ đối phó với tôi nếu tôi không có điều gì khác để tiếp tục. Nếu họ theo phong cách phỏng vấn của Microsoft, thì người đưa ra câu hỏi này cho bạn có thể sẽ chặn bạn - và người ta thường làm tất cả.

Điều gây khó khăn cho tôi là người phỏng vấn đã không hỏi bạn về mã này. Một người phỏng vấn giỏi đã nhìn thấy đủ mã của riêng họ để biết rằng mọi người mắc lỗi - đặc biệt là khi vội vàng. Thông thường họ nói, "Bây giờ bạn có thấy điều gì sai với mã này không?" "Không? Vâng, hãy kiểm tra nó". Bạn đưa ra một số bộ kết quả và sau đó chạy nó thông qua chức năng. Sau đó, bạn nói, "Ôi chết tiệt, điều đó đã không làm việc." "Ok, làm thế nào bạn sẽ sửa nó ..." và như vậy. Nếu bạn sống sót qua hộp thoại đó, nó thực sự khá ấn tượng và thể hiện khả năng suy nghĩ nghiêm túc, đưa ra các trường hợp thử nghiệm và gỡ lỗi mã của riêng bạn.

Cũng lưu ý, họ thường không tìm kiếm "mã làm việc". Ai sản xuất rằng đầu tiên thử dù sao? Nhưng chính xác về mặt logic với xử lý lỗi và bộ kiểm tra tốt là một mục tiêu tốt.

Ngoài ra, điều này có thể làm bạn ngạc nhiên, nhưng bạn đang cạnh tranh với nhiều người thậm chí không thể bắt đầu trên fizzbuzz. Chúng ta có xu hướng cho rằng mọi người khác đang đi ngang qua cây b + trong giấc ngủ của họ .... nhưng thực tế, họ thậm chí không thể tìm ra bội số của 3 và 5 và sử dụng toán tử mô đun. Bạn có thể ngạc nhiên thú vị về việc bạn đã làm tốt hơn nhiều so với các ứng cử viên khác.

Lời khuyên của tôi, chỉ cần chải nó đi. Tôi đã phỏng vấn tại các công ty phần mềm lớn gần đây (Microsoft, Amazon, v.v.), và đây là lần đầu tiên tôi trải qua quá trình phỏng vấn kỹ lưỡng như vậy. Tôi đã tự đánh lừa mình tại một cuộc phỏng vấn tại chỗ của Microsoft phần lớn là do căng thẳng, nhưng đồng thời, tôi chỉ không biết những gì mong đợi hoặc chính xác những gì họ đang tìm kiếm. Tôi đóng đinh một vấn đề con đường ngắn nhất chỉ để thổi một số vấn đề thực sự đơn giản. Tôi đã bật các giá trị ra khỏi đầu sai của ngăn xếp, quên trong một int atoi(char* value)triển khaiint val = value[i] - '0';sẽ cho tôi giá trị nguyên của ký tự và một số lỗi ngớ ngẩn khác. Tôi rất vui vì phần lớn cuộc phỏng vấn, nhưng vẫn hiểu tại sao tôi không nhận được lời đề nghị. Tôi phải nhận ra rằng đây không phải là một sự phản ánh về khả năng của tôi vì nó là một chỉ số mà tôi chỉ cần tiếp tục thử nó cho đến khi tôi có thể làm chủ được thần kinh của mình. Cuối cùng, tôi đóng đinh một số cuộc phỏng vấn với những câu hỏi khó hơn nhiều và đạt được công việc mơ ước của mình. Nó thực sự là - đối với hầu hết những người thực sự biết những gì họ đang làm - chỉ là vấn đề tìm ra những gì người phỏng vấn muốn, tự tin vào bản thân và đưa nó cho họ. Nó sẽ mất một lúc.

Tôi sẽ phải nói không, nhưng không phải vì lý do bạn đưa ra, mà là bạn đặt phần FizzBuzz cuối cùng. Với cách mã của bạn hoạt động, nó sẽ không bao giờ in FizzBuzz khi bạn mong đợi. Như Lee nhận xét, nó sẽ in nó cho mọi giá trị không chia hết cho 3 hoặc 5.

Nhưng điểm chính là bạn học hỏi từ nó. Tôi thích thực tế là bạn đang ở đây hỏi về cách bạn có thể làm tốt hơn. Hãy chắc chắn rằng bạn làm một số câu đố mã và nghiên cứu các câu hỏi phỏng vấn phổ biến. Ngoài ra, có thể thử tự định thời gian hoặc làm điều gì đó khác sẽ làm tăng áp lực để bạn có thể cố gắng bắt chước cảm giác bạn sẽ nhận được trong một cuộc phỏng vấn. Và chuẩn bị, chuẩn bị, và chuẩn bị nhiều hơn cho cuộc phỏng vấn nếu bạn thực sự muốn loại nó ra khỏi công viên.

Không. Quan điểm của FizzBuzz là xem bạn có thể tìm ra logic điều kiện cơ bản hay không, bao gồm tất cả các trường hợp. Trái với ý kiến ​​của một số người, FizzBuzz không nói về toán tử mô đun, biết các toán tử ternary hoặc toán hạng boolean. Đó là một bài tập đơn giản trong điều kiện và bạn đã thất bại.

Vấn đề được cấu trúc sao cho tất cả các mã trông "thanh lịch" không thể bao gồm ít nhất một trường hợp.

Câu trả lời chấp nhận được:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

Tôi cung cấp cho mọi người các vấn đề lập trình tầm thường để làm tại bảng trắng. Cho dù mã kết quả là không có lỗi hay không không phải là điểm quyết định. Thay vào đó tôi quan tâm đến một số hành vi được thể hiện trong quá trình viết mã. Nó tương tác và tôi đang tìm hiểu rất nhiều về các ứng cử viên trong khi nó đang diễn ra.

Tôi đi vào chi tiết hơn tại "thử nghiệm" Bảng trắng trong một cuộc phỏng vấn: cách hợp pháp để sao lưu mã (bảng trắng) của bạn?

Tất nhiên, người phỏng vấn của bạn có thể không có gì giống tôi. Nhưng bạn hoàn toàn có thể vượt qua một cuộc phỏng vấn với tôi trong khi sản xuất mã đó là một chút nhỏ xíu và hoàn toàn có thể thất bại với mã giống hệt nhau.

Nếu tôi đang đánh giá điều này, tôi sẽ tìm kiếm những điều sau đây:

1. Ứng viên có cố gắng để có được sự hiểu biết rõ ràng về các yêu cầu trước khi chuyển sang thực hiện không? Ứng viên có tìm cách giải quyết vấn đề của tôi hoặc sử dụng các công cụ thú cưng của mình trong hộp công cụ lập trình không? Làm thế nào để ứng viên đi giải quyết vấn đề?
2. Là ứng viên thông thạo ít nhất một ngôn ngữ lập trình?
3. Ứng viên có nắm bắt được logic boolean không?
4. Ứng viên làm gì để đảm bảo chất lượng giải pháp của mình?
5. Làm thế nào để ứng viên trả lời phản hồi về mã của mình?

-

Thật khó để nói về # 1. Câu hỏi của bạn nói rằng vấn đề của bạn không bao gồm phần "số in" và thực tế giải pháp của bạn không bao gồm điều đó. Tôi không có lựa chọn nào khác ngoài việc nhận lời của bạn cho nó, nhưng nếu thực tế đó là vấn đề FizzBuzz cổ điển bao gồm việc in các số không chia hết cho một trong hai, thì có vẻ như bạn đã nhảy vào một giải pháp trước khi hiểu đầy đủ các yêu cầu, điều này sẽ là một dấu hiệu tắt.

Tôi sẽ cung cấp cho bạn một phần tín dụng cho # 2 và # 3. Bạn đã biết sử dụng toán tử mô đun và có cấu trúc của một giải pháp làm việc, nhưng đã bỏ lỡ các phần của cả hai.

Có vẻ như bạn đã không làm # 4, điều này sẽ đánh dấu bạn xuống. Trong tương lai, tôi khuyên bạn nên lùi một bước khỏi bảng trắng và xem xét giải pháp của bạn trước khi gọi nó xong. Tôi cũng sẽ (không được nhắc nhở) bước qua một vài bài kiểm tra đơn vị cho giải pháp của bạn, điều này sẽ nhanh chóng chứng minh bạn đã nhầm lẫn ở đâu.

Họ đã không cho bạn cơ hội ở vị trí thứ 5, điều này thật đáng tiếc. Nhưng vấn đề là tôi không muốn ai đó nghĩ rằng mọi dòng mã họ từng viết là vàng nguyên chất không thể cải thiện được, mà là ai đó sẵn sàng chấp nhận phản hồi về các giải pháp của anh ta và tham gia vào một số cuộc trò chuyện về cách tiếp cận của anh ta .

-

Vì vậy, nếu tôi đánh giá về điều này một mình, tôi sẽ bỏ phiếu "Không thuê." Những thứ như thế này là loại đo lường một nghệ thuật trình diễn hơn là khả năng lập trình , nhưng thành thạo nó vẫn có thể hỗ trợ cho sự nghiệp của bạn. Vì vậy, các khuyến nghị của tôi cho các cuộc phỏng vấn công nghệ trong tương lai sẽ là:

1. Trước khi phỏng vấn, hãy thực hành một vài loại bài tập lạnh này, sử dụng càng ít tài nguyên bên ngoài càng tốt. Không ghi nhớ các giải pháp, nhưng để chắc chắn rằng bạn cảm thấy thoải mái với ngôn ngữ ưa thích của mình

2. Đặt câu hỏi về vấn đề để xác nhận các giả định của bạn.

3. Trước khi thông báo giải pháp của bạn hoàn tất, hãy lùi lại từ bảng trắng và xem xét nó, và đi qua một vài trường hợp thử nghiệm đơn vị đơn giản.

Yêu cầu ai đó giải quyết vấn đề mà không cho họ khả năng nhận phản hồi về giải pháp của họ là một cách tiếp cận đáng ngờ, vì họ không được phép cải thiện.

Tất cả bài kiểm tra này cho chúng tôi biết rằng bạn đã không thể hiện được các kỹ năng giải quyết vấn đề "đỉnh cao" rất tốt.

Đây có thể là một trong những yếu tố trong quyết định thuê bạn hay không, nhưng với tôi chắc chắn nó không phải là duy nhất.

Họ có cung cấp cho bạn một môi trường thử nghiệm hoặc thực thi đơn vị không, những lỗi bạn mắc phải sẽ ít gây ra hơn.