Kiểm tra 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? [đóng cửa]


15

Khi tôi nhận được nó, có một lỗi (thậm chí là lỗi chính tả hoặc thiếu ";") trong mã bảng trắng của bạn thường sẽ khiến bạn mất một số điểm phỏng vấn. Tránh điều đó chắc chắn sẽ tạo ra một mã đọc bằng chứng lặp đi lặp lại (mất thời gian và có thể là năng lượng / nồng độ thần kinh) hoặc thậm chí sử dụng thuật toán đơn giản (và do đó ít hiệu quả hơn) - và cả hai cách này đều "tốn kém" một lần nữa!

Vì vậy, tại sao không chỉ viết mã nhanh chóng thanh lịch và hiệu quả như bạn sẽ có một khung kiểm tra (đơn vị) theo ý của bạn và sau đó chỉ kiểm tra nó một cách bình thường (chỉ trên bảng trắng)?

Có ai đã thử / xem phương pháp này chưa? Là toàn bộ ý tưởng xứng đáng?

[điều này cũng áp dụng cho trường hợp bút và giấy]


23
Nếu tôi muốn ai đó viết mã trên bảng trắng hoặc giấy trong một cuộc phỏng vấn, tôi sẽ không hy vọng nó đúng 100% về mặt cú pháp - điều đó khiến họ chịu quá nhiều áp lực. Đúng, nó nên được chính xác rộng rãi, nhưng thiếu dấu hai chấm hoặc thậm chí nhận được một tên phương thức / hồ sơ tham số hơi sai là (hoặc nên) OK.
ChrisF

17
Tôi là một fan hâm mộ lớn của mã hóa bảng trắng trong các cuộc phỏng vấn, nhưng bất cứ ai mong đợi mã bảng trắng của bạn hoàn hảo về mặt cú pháp đều làm sai. Vấn đề là để xem cách bạn tấn công một vấn đề, chứ không phải để thấy rằng bạn có thể tạo mã hoàn hảo về mặt cú pháp trong một môi trường hoàn toàn phi thực tế.
Tim Goodman

3
bạn sẽ có thể nói đó là cái gì bằng cách yêu cầu họ đưa ra một bình luận đang chạy về những gì họ đang làm chẳng hạn hoặc thảo luận về giải pháp với họ sau khi họ kết thúc.
ChrisF

6
Quá quan tâm về cú pháp và chính tả chính xác sẽ làm mất điểm của người phỏng vấn trong cuốn sách của tôi.
JeffO

2
đây là những gì mã psuedo dành cho
jk.

Câu trả lời:


49

Tôi hoàn toàn muốn bạn kiểm tra mã bảng trắng tôi yêu cầu bạn viết. Tôi muốn bạn nói to trong khi bạn viết nó, xem nó, phát hiện ra hầu hết các lỗi cú pháp bạn đã thực hiện và chỉ ra làm thế nào nó có thể hiệu quả hơn. Trong thực tế, đó là loại điểm của việc làm nó ở bảng trắng. Không phải là một kiểu bắn một lần, viết ra tất cả, uh-huh-you-get-70/100. Đó là một cuộc trò chuyện, qua trung gian mã và được tổ chức tại bảng trắng thay vì trên bàn của tôi.

Dưới đây là một số cách tuyệt vời để thất bại trong bài kiểm tra "Mã hóa bảng trắng":

  • từ chối nó
  • đừng hỏi một câu hỏi làm rõ (ngôn ngữ, nền tảng, điều gì đó về các yêu cầu) VÀ đừng cho tôi biết những giả định của bạn về bất kỳ câu hỏi nào VÀ đưa ra những giả định loại bỏ những gì tôi sẽ trả lời

(vd

  • hỏi tôi ngôn ngữ nào tôi muốn sử dụng, nhận câu trả lời trong phần mô tả công việc và sau đó viết nó bằng ngôn ngữ khác vì bạn không thoải mái với ngôn ngữ tôi yêu cầu.

(Chúng tôi là chuyên gia tư vấn ở đây. Tôi đang thử nghiệm hành vi tư vấn cũng như mã hóa. Hỏi khách hàng chỉ đúng nếu khách hàng thực sự có lựa chọn. Điều khiển cuộc trò chuyện với những người sẽ trả tiền cho bạn là khó khăn. Đây là bài 1. Đó là một đánh dấu bạn vào bất kỳ chủ đề nào, nhưng đối với cụ thể "bạn đang thuê một lập trình viên X nhưng tôi không muốn viết bằng X cho bạn" thì bây giờ bạn có hai dấu đen lớn.)

  • cho tôi thấy bạn là một phi hành gia kiến ​​trúc bằng cách lấp đầy hai bảng trắng với các giao diện, mẫu nhà máy, trừu tượng, tiêm và kiểm tra khi tôi muốn bạn "in các số từ một đến 5".

(bạn nghĩ tôi đang phóng đại nhưng tôi đã có một anh chàng khái quát vấn đề của mình một cách đáng kể - bám vào ví dụ trên, hãy nói thay vì 1 đến 5, giải pháp của anh ta sẽ thực hiện bất kỳ chuỗi số nguyên tùy ý nào (lấy từ đâu? Tôi tự hỏi) và là 5 nhiều lần miễn là bất kỳ ai khác - và anh ta quên thực sự gọi hàm đã thực hiện công việc. Lặp đi lặp lại nhắc nhở và đề nghị anh ta đi qua nó như thể anh ta là trình gỡ lỗi không dẫn đến việc anh ta nhận ra rằng hàm này không bao giờ được gọi.)

Tôi luôn nói "bạn có thích điều đó không?" "bạn có thể cải thiện điều đó?" "Đưa tôi qua đó" và tương tự. Điển hình là dấu chấm phẩy bị mất được phát hiện, hoặc từng phần một, trong cuộc trò chuyện đó. Nếu không, tôi thường đánh dấu nó lên dây thần kinh.

Những điều khác bạn có thể không nghĩ là vấn đề ở bảng trắng quan trọng với tôi:

  • khi bạn hoàn thành, tôi vẫn có thể đọc nó chứ? Bạn đã bị nhòe, viết nguệch ngoạc, chuyển màu, rút ​​mũi tên, gạch bỏ và nói chung là để lại một mớ hỗn độn không thể sử dụng? Hoặc bạn có biết rằng bảng trắng có thể xóa được, chỉ vào các dòng mã trong không khí thay vì khoanh tròn / mũi tên và để lại cho tôi thứ gì đó tôi có thể chụp ảnh và giữ trong tệp thiết kế?
  • bạn đã hỏi tôi bao nhiêu? Bạn có thích bị bỏ lại một mình và không thảo luận về mã của mình không, hoặc bạn có thấy mã là một thứ hợp tác không? Làm thế nào bạn trả lời khi tôi hỏi bạn những điều trong khi bạn vẫn đang viết nó?
  • bạn đã chế nhạo nhiệm vụ "dễ dàng" hay mờ nhạt ở nhiệm vụ "khó"? Bạn có thô lỗ về việc được yêu cầu cho thấy bạn có thể viết mã không? Bạn có dễ dàng bị đe dọa bởi một vấn đề kỹ thuật, hoặc kiêu ngạo về khả năng của bạn để đưa ra một thuật toán tốt?
  • bạn đang làm việc đó trong đầu, hoặc nhớ một giải pháp bạn đọc ở đâu đó? Tôi thường có thể nói cho các vấn đề khó khăn.
  • bạn đã lên kế hoạch trước về nơi bạn bắt đầu viết chưa? Những người hết bảng trắng thường bắt đầu quá thấp hoặc viết quá lớn - tôi có thể nói rằng họ không biết đây sẽ là 20 dòng mã và vì vậy chỉ còn lại 5 chỗ - tin hay không chi tiết nhỏ này được nhân đôi trong nhiệm vụ ước tính lớn hơn là tốt.
  • bạn đã xem qua trước khi bạn nói bạn đã làm xong chưa? Tôi có thấy bạn chỉ hoặc gõ theo cách của bạn thông qua nó và tự kiểm tra nó trước khi tôi yêu cầu bạn không? Khi tôi nhắc bạn, hoặc hỏi bạn những câu hỏi cụ thể về nó, bạn có nhìn lại nó không, hay chỉ đi từ bộ nhớ? Bạn có sẵn sàng xem xét rằng bản thảo đầu tiên của bạn có thể không hoàn thành?

Tôi thực sự khuyên bạn nên thực hành mã hóa tại bảng trắng. Tôi luôn cảnh báo những người được phỏng vấn rằng họ sẽ được yêu cầu làm điều đó. Nếu bạn có quyền truy cập vào một bảng trắng thực tế thì hãy đặt cho mình một số vấn đề đơn giản và thực hành làm chúng ở đó. Nó sẽ giúp hiệu suất và sự tự tin của bạn.

Xin lỗi tôi biết tôi đang ở trong lãnh thổ TL; DR nhưng đây là điều - mã hóa trong bảng trắng không chỉ là mã hóa . Đó là một bài kiểm tra nhiều hơn sự nắm bắt cú pháp của bạn. Có rất nhiều hành vi của các lập trình viên giỏi được thể hiện trong phản ứng của bạn với nhiệm vụ này. Nếu bạn nghĩ rằng đó chỉ là về mã hóa thì bạn đang thiếu điểm.

Trong các cuộc trò chuyện khác về thử nghiệm bảng trắng, mọi người nói với tôi rằng tôi có thể từ chối một ứng cử viên tốt với nó. Thành thật mà nói, đó là một rủi ro tôi sẵn sàng chấp nhận. Mỗi vòng tuyển dụng đều có vài người tôi có thể thuê. Một số người có sơ yếu lý lịch tuyệt vời, những người đang làm tốt trong phần hỏi và trả lời của cuộc phỏng vấn, bị ngã ở bảng trắng và rõ ràng không thể (với bất kỳ số lượng nhắc nhở nào) viết mã đơn giản bằng ngôn ngữ mà họ tuyên bố biết. Tôi có thể đã thuê một số trong số này. Bất kỳ công cụ nào ngăn chặn đó là một công cụ tôi sẽ tiếp tục sử dụng. Tôi chưa bao giờ kết thúc việc không có ai thuê thuyền vì tất cả các ứng cử viên của tôi đã gửi nhầm vào bảng trắng và tôi không hy vọng mình sẽ làm được.


2
Có vẻ là một câu trả lời tuyệt vời (và thành thật mà nói nhiều hơn nữa mà tôi hy vọng nhận được ban đầu). Rất rất cảm ơn.
mlvljr

9
@KingOfHypocites bạn đã thực sự đọc câu trả lời? Tôi không quan tâm đến việc bỏ lỡ một dấu chấm phẩy. Hãy nhìn những gì nó nói tôi quan tâm. 20 phút tại bảng trắng cho tôi biết rất nhiều về bạn.
Kate Gregory

7
Tôi tò mò nếu có nghiên cứu nào xác nhận cuộc phỏng vấn bảng trắng. Tiết lộ đầy đủ: Tôi trở nên tò mò sau khi thất bại trong một cuộc phỏng vấn bảng trắng, khó khăn. Tôi đã không được phỏng vấn trong một vài năm, chưa bao giờ là một người biểu diễn / người dẫn chương trình giỏi và bị đóng băng khá nhiều. Những hiểu biết của bạn là tuyệt vời và tôi đã đọc điều này đầu tiên tôi sẽ nghĩ về phần đó của quá trình phỏng vấn khác đi nhiều (và nói nhiều hơn). Điều đó nói rằng, nhiều người có ý kiến ​​mạnh mẽ về chủ đề này nhưng dường như là tất cả. Tôi cho rằng có một sự biện minh khách quan cho thực tiễn này, được hỗ trợ bởi dữ liệu hỗ trợ. Lanhung?
Suboptimus

3
+1 Thành thật mà nói, tôi đã tiếp cận bảng trắng như một ủy quyền cho một bài tập trong lập trình cặp, hy vọng sẽ tiếp tục cuộc trò chuyện về nhiệm vụ như Kate gợi ý - mặc dù tôi muốn có một máy và thực sự ghép chương trình với ứng viên (hoặc là ứng viên lập trình cặp với người phỏng vấn). Cách bạn viết mã cùng nhau cũng quan trọng như cách bạn viết mã một mình, trong một tổ chức có quy mô bất kỳ.
Julia Hayward

4
Tôi biết điều này đã cũ nhưng tôi mới được liên kết với nó và tôi muốn chỉ ra: một trong những đặc điểm của rối loạn xử lý hình ảnh là thiếu khả năng ước tính không gian bạn đang viết và do đó cuối cùng hết phòng . Nếu người mà bạn đánh giá không chỉ hết phòng vì nhiều dòng hơn mà còn có các nhân vật nhỏ dần về cuối dòng khi họ nhận ra rằng họ đã bắt đầu quá lớn, họ có thể bị khuyết tật học tập thay vì không hiểu Mã sẽ kéo dài bao lâu. Yêu cầu họ ước tính một cái gì đó không phải không gian và bạn có thể nhận được kết quả tốt hơn.
Yamikuronue

17

Tôi nghĩ rằng bạn đã thực hiện một giả định không chính xác ở đây. Không có cách nào tôi mong đợi một ứng cử viên viết mã lên bảng trắng để có thể nhận được mọi ';' hoàn hảo tại chỗ. Nếu bạn đang phỏng vấn tại một nơi phạt bạn vì điều đó thì tôi khuyên họ không phải là một tổ chức bạn muốn làm việc cho :-).


2
Tôi đã thất bại trong một cuộc phỏng vấn bởi vì, như họ đã nói, tôi đã không viết mã được tối ưu hóa hoàn hảo trong lần đầu tiên vượt qua bài kiểm tra bằng giấy (từ trường get-it-work-with-unit-tests-then-tối ưu hóa ). Sau đó, một lần nữa, họ không có khung thử nghiệm tại chỗ, họ chỉ cho rằng họ có lập trình viên đã làm điều đó ngay lần đầu tiên!
Julia Hayward

3
@JuliaHayward - Một lối thoát may mắn cho bạn bằng âm thanh! Không thể tin mọi người vẫn làm điều đó.
Martijn Verburg

7

Các bài kiểm tra giấy hoặc bảng trắng là cực kỳ không hiệu quả. Tôi nhớ một lần tôi có một cuộc phỏng vấn mà tôi phải tìm lỗi trong một số mã trên giấy. Một trong số đó là lớp được kế thừa từ một giao diện nhưng thiếu việc triển khai thành viên. Tôi biết đây có thể là một trong những lỗi, tôi đã tìm kiếm nó và vì bất kỳ lý do gì tại chỗ tôi không thể nhìn thấy nó (mặc dù tôi đã đề cập rằng tôi đang tìm kiếm đó là một trong những vấn đề).

Khi nó xảy ra, tôi vẫn nhận được công việc đó, nhưng nó khiến tôi suy nghĩ về những gì đã xảy ra. Trong một kịch bản thực tế cho loại điều đó, tôi sẽ nhận được những dòng nguệch ngoạc vào thời điểm có gì đó không ổn (đây là C # trong Visual Studio) và điều đó sẽ không được biên dịch. Tôi không bao giờ kiểm tra điều này trong cuộc sống thực bởi vì nó không bao giờ xảy ra (điều đó là không thể) và do đó tôi không muốn nhìn thấy thứ này. Thiếu dấu hai chấm là một ví dụ thậm chí còn cực đoan hơn về điều này - hoàn toàn không thực tế trong thế giới thực trừ khi bạn viết bằng notepad và gửi e-mail mã của mình cho người khác biên dịch!

Nếu ai đó yêu cầu sử dụng bảng trắng trong một cuộc phỏng vấn để hỗ trợ điều họ muốn nói thì thật tuyệt, nhưng tôi sẽ không bao giờ làm theo cách khác.


2
Câu chuyện của bạn dường như chứng minh rằng bài kiểm tra của bạn có hiệu quả. Thay vì thường hỏi "Làm thế nào để bạn xem lại mã?" họ đã cho bạn một số để xem xét. Bạn nói to và nói điều gì đó như "phải chắc chắn rằng nó thực hiện mọi thứ" và mặc dù bạn không phát hiện ra người mất tích, bạn đã cho họ thấy rằng bạn thực sự biết cách xem lại mã lỗi, không chỉ trả lời câu hỏi về nó. . Bạn cũng có thể đã không chỉ ra một loạt các lỗi không phải là lỗi mà một số người có thể mắc phải và có lẽ bạn cũng đã thấy một số lỗi khác. Và sau đó bạn đã có được công việc. Điều đó nghe có hiệu quả với tôi, cho tất cả mọi người!
Kate Gregory

2
Ngoài ra, thiếu dấu hai chấm tiếp tục bị loại bỏ vì không phải là một tiêu cực thực sự. Liên tục nhầm lẫn cú pháp của ngôn ngữ ưa thích của bạn có nghĩa là bạn là nhà phát triển chậm hơn so với người đã nội hóa tất cả cú pháp đó. Bạn liên tục quay trở lại và sửa chữa những thứ bạn quên. Có một cơ hội tốt để bạn thoát khỏi nhịp điệu của mình với sự cằn nhằn liên tục từ IDE. Ngoài ra, những người bỏ hết dấu hai chấm của họ vào bảng trắng và không để ý khi bạn nhắc họ không ở cùng cấp độ với các nhà phát triển giỏi một lần một tuần quên gõ dấu hai chấm trong IDE và sau đó sửa nó
Kate Gregory

2
+1 nó không hiệu quả. Nó chứng minh hoàn toàn không có gì. Tôi khá chắc chắn rằng nhiều người thất bại trong bài kiểm tra tốt hơn những người bình thường vượt qua nó.

3
@Kate - Tôi đến nơi bạn đến, nhưng tôi không đồng ý - đặc biệt là khi tôi ngồi ở phía bên kia của bàn. Nếu ai đó bị thiếu dấu hai chấm thường xuyên, tôi muốn thấy rằng trong IDE không phải trong một thiết lập nhân tạo. Nó giống như mã khóa cho văn phòng của tôi - Tôi có thể nhập số mà không cần suy nghĩ, yêu cầu tôi viết nó với độ tin cậy 100% và tôi sẽ phải vật lộn. Một cuộc phỏng vấn sẽ không bao giờ thành hiện thực 100% vì vậy tôi không muốn đi ra ngoài để làm cho nó thậm chí còn ít hơn thế.
FinnNk

1
Tôi ít có khả năng bỏ qua cú pháp quan trọng trên bàn phím so với bảng trắng, vì gõ được củng cố bởi bộ nhớ cơ. Tuy nhiên, việc nhập sai (và một lời cằn nhằn từ biên tập viên của tôi hoặc đối tác cặp), đặc biệt là trong tình huống lập trình cặp, có khả năng ném tôi vào vòng phản hồi trong đó các lỗi củng cố các dây thần kinh gây ra lỗi. Tôi nghĩ rằng các polyglots có khả năng bị thiệt thòi hơn các ứng cử viên đơn ngữ.
dcorking 18/03/2015

5

Tôi đã làm điều đó. Trong một cuộc phỏng vấn, tôi được yêu cầu thực hiện mã hóa độ dài chạy trên bảng trắng và trong khi tôi rút ngắn một số mã (giải thích những gì tôi viết tắt) để phù hợp với bảng trắng, tôi vẫn đưa ra một bộ sưu tập các bài kiểm tra cho đơn vị này, và chạy qua một trong số họ để xác nhận giải pháp của tôi và cho thấy thử nghiệm sẽ giúp ích như thế nào. Tôi đã được cung cấp vị trí đó vì vậy tôi cho rằng thử nghiệm là hữu ích, hoặc tệ nhất là không gây phiền nhiễu.


4

Tôi sử dụng phương pháp này khi làm bài kiểm tra cho trường học. Trước tiên tôi viết hàm, sau đó sang bên tôi viết một bảng nhỏ đầu vào, đầu ra và vars. Tôi đã bắt gặp một vài lỗi ngu ngốc theo cách này. Kiểm tra, ngay cả kiểm tra trên giấy / bảng trắng, luôn luôn tốt hơn so với không kiểm tra.

Mặc dù vậy, tôi không đồng ý với việc tạo ra dấu chấm phẩy trong môi trường chuyên nghiệp.


4

Yêu cầu một ứng cử viên viết mã trên bảng trắng là ngớ ngẩn. Có các công cụ hiện đại như snippits, jsfiddle và intellisense. Ngoài ra, không yêu cầu kỹ sư ghi nhớ cú pháp. Cú pháp được tra cứu và tham chiếu. Nếu bạn đang ghi nhớ mã, có lẽ bạn đã không dành thời gian trong sự nghiệp để học cách viết mã trong môi trường nhiều người thuê, tối ưu hóa cú pháp hoặc thậm chí là môi trường được lưu trữ.


3
Bất cứ ai nửa chừng trong một ngôn ngữ cụ thể nên ghi nhớ cú pháp từ việc sử dụng nó rất nhiều. Nếu một chàng trai viết mã C # cả ngày và không biết hầu hết cú pháp trên đỉnh đầu, anh ta sẽ chậm và khủng khiếp. Bạn cũng có thể tra cứu 2 ^ 8 là gì, nhưng bất kỳ nhà phát triển nào xứng đáng với muối của họ nên biết nó nằm ngoài đỉnh đầu của họ chỉ vì đã gặp nó quá thường xuyên. Cú pháp cũng vậy.
whatsisname 18/03/2015

1
Đó chỉ đơn giản là không đúng sự thật. Cú pháp ghi nhớ trong thời đại ngày nay là không cần thiết. Để nói rằng các nhà phát triển biết cách viết mã bằng nhiều ngôn ngữ như sql, vb, c #, javascript và sử dụng json, angularjs, telerik và các ngôn ngữ khác không có giá trị vì họ không thể ghi nhớ cú pháp là ngớ ngẩn. Có nhiều thứ để trở thành một kỹ sư phần mềm giỏi hơn các nhà khai thác toán học như bạn liệt kê. Làm thế nào về hiểu biết yêu cầu, cấu trúc thiết kế, mô hình, kinh nghiệm ngành công nghiệp? Có đủ cú pháp trong ngôn ngữ và thư viện để lấp đầy phía sau xe tải.
James Bailey

Đây không phải là vấn đề "cần thiết". Đó là nếu bạn sử dụng một cái gì đó thường xuyên đủ, bạn sẽ nhớ nó. Nếu một người nào đó tự xưng là nhà phát triển SQL nhưng không thể viết một tuyên bố tham gia ra khỏi đỉnh đầu, thì đó là vì anh ta là một) bất tài b) đã nói dối về trình độ của mình, hoặc c) có bộ não rất kỳ lạ, tất cả ba tình huống tôi không muốn phải giải quyết.
whatsisname 19/03/2015

1
"Tham gia" không phải là những gì thường được hỏi trên bảng trắng. Nó thường là câu đố và những thứ không liên quan đến công việc. Điều gì sẽ xảy ra nếu ứng viên được chứng nhận, có bằng cấp và có một bản lý lịch mạnh mẽ. Bạn vẫn nghĩ anh ta "bất tài" vì anh ta không viết mã trên bảng trắng để kiếm sống? Những người tiếp thị không được yêu cầu đưa ra một chiến lược tiếp thị hàng quý trên các điểm phỏng vấn. Thật ngớ ngẩn. Bạn sẽ có thể nói chuyện với ứng viên và dễ dàng suy luận nếu họ có thể viết mã.
James Bailey

3

Khi một nhà hàng muốn thuê một đầu bếp, chủ sở hữu không yêu cầu anh ta nấu một "nồi au feu" bằng tăm và mũ lưỡi trai.

Đừng yêu cầu nhà phát triển viết mã trên bảng trắng trong một cuộc phỏng vấn.


3
Và khi được hỏi?
mlvljr

Trong cuộc phỏng vấn

3

Bảng mã trắng là khó khăn. Tôi chưa bao giờ được giới thiệu về điều đó cho đến khi tôi được Disney phỏng vấn. Không biết những gì mong đợi và không thể gỡ lỗi nó, tôi tình cờ thấy nó nói chuyện và giải quyết vấn đề, nhưng theo một cách giả mã. Khi họ hỏi nó có chạy được không.

Tôi có nghĩa là chắc chắn rằng bạn có thể phải sửa các lỗi cú pháp, chính xác. Tôi tin rằng họ đã mất một ứng cử viên rất tốt nếu tôi không được tuyển dụng vì bảng trắng. Tôi nhìn vào trình độ và có vẻ như tôi đủ điều kiện cho vị trí và có thể thực hiện công việc. Tôi xuất sắc trong công việc hiện tại và đang ước mình có thể làm việc với họ.

Cảm ơn cho Kate đầu vào của bạn, tôi đọc từng từ. Với tôi là một lập trình viên, bảng trắng thực sự không thể hiện kỹ năng của bạn. Tôi là một lập trình viên tuyệt vời làm việc trong nhiều ngôn ngữ. Tôi biết ngôn ngữ mà tôi được yêu cầu lập trình, nhưng trên bảng trắng tôi đột nhiên quên mất.

Tôi xây dựng tích hợp và xử lý thẻ tín dụng phức tạp, nhưng trên bảng trắng tôi không thể nhớ làm thế nào để thực hiện cú pháp đúng cách không có gì nhắc tôi.

Là một nhà tuyển dụng, tôi thích thử nghiệm bảng trắng; tuy nhiên, tôi đang thuê một lập trình viên mà tôi muốn xem các kỹ năng thực tế của họ nếu họ thực hiện công việc. Thật tuyệt nếu họ có thể giao tiếp, nhưng tôi cần thấy họ có thể giải quyết vấn đề.


1
Dường như cảm ơn về đầu vào, có vẻ đúng về những gì tôi đã nghĩ khi đặt câu hỏi - người ta thực sự có thể bị mắc kẹt trong mã bảng trắng mà không biết liệu nó có đúng hay không và không có nghĩa là "thực sự" kiểm tra nó. Một giải pháp khó khăn - viết một bài kiểm tra bảng trắng! ;)
mlvljr
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.