Nó quan trọng như thế nào về mặt cú pháp trong một cuộc phỏng vấn? [đóng cửa]

Khi yêu cầu một ứng viên phỏng vấn viết một chương trình trên bảng trắng, bạn có mong đợi ứng viên đó viết mã đúng về mặt cú pháp không?

Tôi đã có hai ứng cử viên, một trong số họ đã viết một chương trình đúng về mặt cú pháp nhưng logic không đúng, và cái còn lại có logic được viết tốt hơn nhưng cú pháp thì tào lao.

Tôi ủng hộ ứng cử viên đầu tiên.

Tôi sẽ ủng hộ người có thể suy luận vấn đề, đưa ra giải pháp tốt và sau đó giải thích giải pháp của họ cho tôi. Ngay cả khi logic của họ không phải là 100%, nếu họ đi đúng hướng và suy luận vấn đề, đặt câu hỏi đúng và đi đúng hướng, đó sẽ là người chiến thắng của tôi.

Khi bạn đang phát triển mã trong công việc, bạn có nhiều công cụ - IDE, trình biên dịch, phân tích tĩnh, kiểm tra đơn vị, kiểm tra tích hợp và quy trình kiểm tra chấp nhận - để tìm lỗi trong cú pháp và logic. Nếu bạn đang viết trên bảng trắng, bạn không có các công cụ này và bạn nhất định mắc lỗi cú pháp (quên tên phương thức, dấu chấm phẩy, dấu ngoặc nhọn) và tôi có thể tha thứ cho điều đó.

Câu hỏi duy nhất của tôi cho bạn: Tại sao bạn yêu cầu ứng viên của mình viết mã thực tế trên bảng trắng, thay vì tập trung vào các thuật toán, chiến lược thiết kế và tư duy logic? Ngôn ngữ lập trình thay đổi, giải quyết vấn đề không.

Tôi sẽ ủng hộ ứng cử viên thứ hai. Logic có thể khó ( rất khó, đôi khi) để có được chính xác . Cú pháp có thể rất dễ dàng để có được ngay khi IDE và trình biên dịch và các công cụ các loại khác trợ giúp.

Ứng cử viên đầu tiên có thể không bao giờ gây ra lỗi trình biên dịch, nhưng nếu mã của anh ta thường thất bại trong tất cả các trường hợp ranh giới kỳ lạ (và ít kỳ lạ hơn), việc anh ta biết đặt dấu chấm phẩy ở đâu không đáng bao nhiêu.

Tùy thuộc vào các lỗi cú pháp thực tế, tôi đoán tôi sẽ thích ứng viên thứ hai hơn , bởi vì việc kiểm tra cú pháp thường tốt hơn để lại cho các máy .

Các lỗi như thiếu dấu chấm phẩy, quên dấu ngoặc, quên dấu phẩy trong danh sách đối số, v.v. , tất cả những thứ người ta thường sử dụng, nhưng không có sẵn trên bảng trắng.

Tuy nhiên, có một số lỗi, trong khi về mặt kỹ thuật chỉ có lỗi cú pháp, cho thấy sự hiểu lầm sâu sắc hơn.

Như một ví dụ hơi giả tạo để hiểu rõ vấn đề: hãy xem xét một lập trình viên python có tiền tố tất cả các biến của anh ta bằng $ hoặc viết for-loop as for list as item. Về mặt kỹ thuật, cả hai đều là lỗi cú pháp, nhưng ngay cả khi chỉ tiếp xúc hạn chế với python, người ta cũng nên biết về các ký tự pháp lý và vòng lặp for. Sẽ là một phỏng đoán tốt khi ứng viên biết php (hoặc perl?) Và cố gắng nói về kỹ năng python của mình

Tôi thích ứng cử viên thứ hai, theo lý thuyết rằng một bảng trắng có tác động đến cú pháp nhiều hơn logic và các lỗi cú pháp dễ sửa hơn - IDE hoặc trình biên dịch thường có thể làm điều đó.

Tôi đã viết SQL và CSS (ngôn ngữ đơn giản và cơ bản nhất mà tôi biết) trong gần 13 năm và tôi không thể luôn nhớ cú pháp.

Bạn tôi (cũng là một nhà phát triển) làm việc cho một quỹ phòng hộ, anh ta không bao giờ có thể nhớ cú pháp cho một câu lệnh chèn.

Cả hai chúng tôi đều kết thúc với W3CSchools , tôi đoán chúng ta nên ngượng ngùng (anh ấy có bằng cấp, và tôi có bằng tiến sĩ).

Tuy nhiên, thành thật mà nói, tôi nghĩ rằng chúng tôi có những ưu tiên chính xác. Cú pháp không phải là một kỹ năng quan trọng.

Vài suy nghĩ về lỗi cú pháp ... Tôi đã tự hỏi nếu bạn đã làm rõ cả hai cú pháp đó cần phải chính xác. Đôi khi mọi người cho rằng mã giả là OK.

Ngoài ra, nếu ai đó yêu cầu nhiều năm kinh nghiệm trong một ngôn ngữ và không thể thực hiện cú pháp cơ bản chính xác, bạn nên nghi ngờ yêu cầu đó.

Lỗi cú pháp có thể khác nhau, vì vậy nếu ai đó quên tên phương thức thì không sao (với tôi) nhưng nếu ai đó không biết cách tham chiếu một phương thức trong một lớp (ký hiệu dấu chấm) hoặc không biết một suy nghĩ cơ bản như cú pháp cho một Lớp học đơn giản, thì rất có thể người này đã không sử dụng ngôn ngữ trong một thời gian dài.

Đối với anh chàng không hiểu đúng cú pháp, bạn có nghĩ rằng những lỗi của anh ta có thể dễ dàng sửa chữa với trình soạn thảo ngôn ngữ phù hợp không? Nếu vậy, tôi bỏ phiếu cho anh ta.

Tôi đoán những gì tôi nghĩ ở đây là lỗi cú pháp được chấp nhận trong giới hạn.

Một lập trình viên trợ lý cấp cơ sở hoặc thậm chí là một công cụ phần mềm có thể có thể tìm và sửa lỗi cú pháp xấu nếu logic tốt. Logic tồi ... mọi sửa chữa đều ít được đảm bảo hơn. Tất cả các lập trình viên sẽ vít lên. Tôi sẽ chọn một trong những người bắt vít dễ dàng phát hiện và sửa chữa hơn.

Trừ khi vấn đề là tế nhị, và hầu hết các câu hỏi phỏng vấn không có, ứng cử viên đầu tiên bị loại. Học cú pháp ngôn ngữ dễ hơn nhiều so với thiết kế thuật toán. Tôi sẽ thuê một lập trình viên có lịch sử làm việc thành công bằng nhiều ngôn ngữ, ngay cả khi anh ta không có kinh nghiệm trong công nghệ hiện tại của tôi. Đây không phải là chiến lược tốt nhất nếu tôi cần một cái gì đó được thực hiện ngày hôm nay, nhưng nếu tôi cần nhiều thứ được thực hiện trong mười hai tháng tới, thì tôi sẽ luôn chọn khả năng chung qua kinh nghiệm cụ thể.

Kiểm tra cú pháp là những gì một trình biên dịch dành cho. Trình biên dịch không thể làm cho logic của bạn tốt hơn, nhưng nó có thể cho bạn biết cách sửa cú pháp của bạn. Điều đó có nghĩa là bất kỳ công việc nào mà bạn viết mã bằng trình biên dịch, logic vốn có giá trị hơn rất nhiều so với việc đúng về mặt cú pháp.

Các cuộc phỏng vấn luôn là những tình huống khó xử - bạn có thể nói điều này bởi vì khi bạn bước ra ngoài, bạn nghĩ ngay đến tất cả những điều bạn nên nói, hoặc câu trả lời đúng cho những câu hỏi và những điều bạn muốn hỏi họ nhưng quên mất. Vì vậy, với điều này, mong đợi mã được viết hoàn hảo không có lỗi cú pháp là không thực tế.

Ngoài ra, kỳ vọng của bạn về mã hoàn hảo (trên bảng trắng!) Có thể không phù hợp với người phỏng vấn - ví dụ, trong một cuộc phỏng vấn tôi tham dự, tôi được yêu cầu viết một lớp, điều mà tôi đã làm, chỉ để người phỏng vấn kéo tôi lên mà không đưa tôi lên trong một constructor sao chép. Vì vậy, tôi đã viết một trong đó, không làm gì ngoài việc đặt a = b, nhưng điều đó là đủ để đáp ứng anh ta. Kỳ vọng của tôi về vấn đề không yêu cầu một ctor sao chép, vì vậy tôi đã bỏ qua vấn đề này vì nó không liên quan đến vấn đề đang được giải quyết - Tôi không mong đợi phải viết mã tuân thủ đầy đủ (theo các tiêu chuẩn mã hóa ẩn của mình), chỉ đơn giản là hiển thị sự hiểu biết của tôi về giải pháp. (người phỏng vấn này cũng không thích giải pháp của tôi, đó không phải là cách anh ta sẽ làm điều đó nên rõ ràng là tôi đã hiểu sai, thở dài).

Nếu bạn muốn mã làm việc từ một người được phỏng vấn, hãy cung cấp cho họ một trình biên dịch. Sau đó, đừng phàn nàn khi họ gửi hóa đơn cho bạn :)

Vì vậy, hãy tìm người biết anh ta đang làm gì, không phải người có thể nói ra những từ đó nhưng không hiểu ý nghĩa.

Trong một cuộc phỏng vấn, người phỏng vấn thích thú hơn khi nhìn thấy bạn

1. Tiếp cận vấn đề
2. Kỹ năng sử dụng để giải quyết vấn đề và
3. Thời gian để đưa ra một giải pháp thích hợp

Cú pháp mặc dù không quá quan trọng nhưng nó giữ một vị trí nổi bật trong khi giải quyết vấn đề, với những sai lầm lớn trong cú pháp mà bạn không thể mong đợi sẽ khiến người phỏng vấn ấn tượng.

Logic và cú pháp thích hợp kết hợp với nhau có thể thực hiện mẹo cho bạn trong một cuộc phỏng vấn.

Một lỗi nhỏ hoặc nhỏ sẽ không bao giờ khiến bạn phải trả giá nhiều nếu logic đủ tốt.

Hơn nữa có thể IDE có sẵn có thể dễ dàng tạo cú pháp của bất kỳ hình dạng phù hợp nào. Nhưng để sử dụng phương pháp nào ở đâu và khi nào và quan trọng nhất TẠI SAO , sẽ chỉ được biết đến với một anh chàng có logic và kiến ​​thức đúng đắn về chủ đề thực tế.

Tôi hy vọng và kêu gọi bạn cung cấp một cái gì đó nhiều hơn một bảng trắng hoặc một notepad để viết mã.

Tôi sẽ đi với ứng cử viên thứ hai. ..

Vâng, một số người muốn Nhà phát triển Java tuyệt vời, nhà phát triển C # tuyệt vời, nhà phát triển C ++ tuyệt vời, v.v ... Nếu đó là trường hợp của bạn thì hãy đi với A và tiếp thêm sức mạnh cho bạn. Một mối quan tâm tôi sẽ có là nếu họ không thể lý giải để giải quyết vấn đề, làm thế nào bạn có thể mong đợi họ giải thích và giải quyết vấn đề kinh doanh của bạn?

Những người khác chỉ muốn các nhà phát triển tuyệt vời có thể làm việc trong bất kỳ ngôn ngữ nào được yêu cầu. Họ nghĩ về / mô hình hóa vấn đề và sau đó thực hiện nó bằng bất kỳ ngôn ngữ nào. Nếu bạn đột nhiên quyết định .NET hút và chuyển sang Java hoặc ngược lại, đây là những nhà phát triển sẽ không nhảy tàu hoặc từ chối học hỏi. Ngoài ra nếu bạn nhận được một số loại gói tự động / gói tính toán có ngôn ngữ độc quyền và bạn cần một số tác vụ tự động, thì đây là những loại nhà phát triển có thể thực hiện. Ví dụ thực tế ... Tôi cần tìm ra một ngôn ngữ kịch bản độc quyền tùy chỉnh cho gói phần mềm ánh xạ để trích xuất mã zip cho các vùng được vẽ tùy chỉnh cho một chủ nhân cũ. Một ví dụ khác .... chủ nhân hiện tại của tôi có một hệ thống quản lý tài sản độc quyền chứa ngôn ngữ tùy chỉnh để viết báo cáo ... Trong mọi trường hợp,

Ngoài ra trên bảng trắng còn có thêm áp lực / căng thẳng nên không ai ở trạng thái tốt nhất. Thêm vào đó tôi rất nghi ngờ rằng khi mã hóa bạn sẽ có được nó hoàn hảo mọi lúc. Tôi nghi ngờ bạn biên dịch hoặc chỉ chạy và tìm thấy một số lỗi. Ngoài ra, nó phụ thuộc vào ngôn ngữ. C đủ nhỏ để bạn có thể ghi nhớ hầu hết các thư viện ngôn ngữ / cốt lõi (mặc dù tôi không yêu cầu nó). Java / C # có các thư viện lớn như vậy (với những thay đổi thường xuyên như vậy) mà việc ghi nhớ thư viện là không cần thiết.

Cũng biết nhiều ngôn ngữ có thể làm việc chống lại bạn. C # và Java can thiệp lẫn nhau với tôi. Nhưng biết nhiều ngôn ngữ cũng có thể mở rộng quan điểm của bạn, đặc biệt nếu bạn biết một ngôn ngữ kịch bản và ngôn ngữ chức năng ngoài C # / Java.

Tuy nhiên, nếu cả hai ứng viên giải quyết vấn đề với logic chính xác, anh chàng với cú pháp đúng có lẽ có lợi thế. Nếu một người giải quyết vấn đề và một người không giải quyết được thì cá nhân tôi sẽ đi cùng anh chàng có thể giải quyết vấn đề.

Tuy nhiên, nếu ai đó tuyên bố là một chuyên gia về Java và không thể khai báo một mảng sử dụng một câu lệnh if hoặc vòng lặp while, họ có thể đang nói dối. Nhưng tôi có thể hiểu nếu ai đó là một chuyên gia về Java nhưng gần đây đã nhận được rất nhiều C # và cố gắng thực hiện Bản đồ hoặc một cái gì đó .... Ngoài ra, nếu bạn đi vào chi tiết cụ thể của thư viện, hoặc ai đó làm myArray.length thay vì myArray .Lipse hoặc string.length () / string.Ldrops / string.length thay vì string.length () ... Những thứ nhỏ nhặt tôi sẽ tha thứ. Hoặc nếu họ quên thứ tự đối số của một số cuộc gọi thư viện. Hoặc một lỗi đánh máy / dấu hai chấm ở đây hoặc ở đó ....

Tôi sẽ không lấy bất cứ thứ gì trong số chúng.

Một cú pháp tốt là vô ích nếu lập trình viên không giỏi giải quyết vấn đề. Và một cú pháp kém cho một ngôn ngữ nhất định có nghĩa là ứng viên không cảm thấy thoải mái với ngôn ngữ cụ thể đó, có thể vì thiếu kinh nghiệm trực tiếp.

Dù sao, logic là quan trọng hơn nhiều so với cú pháp.

Nó, như mọi khi, phụ thuộc. Nếu lỗi cú pháp tương đối nhỏ, tôi sẽ bỏ qua chúng. Nếu chúng cực kỳ rung chuyển, tôi sẽ chú ý đến chúng và cố gắng suy luận tại sao chúng ở đó.

Tôi nghĩ rằng lỗi logic tệ hơn lỗi cú pháp, lỗi sau hầu như luôn luôn có thể bị bắt một cách máy móc, lỗi trước ít hơn (tùy theo mức độ, bạn đang viết ngôn ngữ nào, một số loại lỗi logic được bắt bởi loại đủ nâng cao suy luận và kiểm tra).

Nó chắc chắn sẽ phụ thuộc vào vị trí của cuộc phỏng vấn, và có lẽ là về ngôn ngữ.

Làm việc trên C ++, có một anh chàng nói lắp cú pháp thật đáng sợ. C ++ đầy những góc tối, những cái bẫy cơ bản nằm ở mọi nơi. Nói sai về cú pháp có nghĩa là sự thể hiện kém đối với ngôn ngữ và người mới bắt đầu C ++ mắc rất nhiều lỗi (không nói rằng người khác thỉnh thoảng không nói).

Để trả lời câu hỏi của bạn, sau đó:

• nếu tôi cần điền vào một vị trí nhà phát triển đơn giản, tôi sẽ nắm bắt được anh chàng nắm bắt tốt cú pháp C ++. Anh ta sẽ không tỏa sáng, nhưng không nên gây ra quá nhiều thảm họa.
• nếu tôi cần lấp đầy một vị trí nhà phát triển chính, tôi cũng sẽ không nhận. Một nhà phát triển chính được cho là có cả kinh nghiệm và logic.

Chỉ có một cảnh báo: mọi người thừa nhận thiếu kinh nghiệm của họ. Lý tưởng nhất là mọi người nên viết mã bằng ngôn ngữ của họ, hoặc mã giả nếu họ thích (ví dụ sinh viên).

Câu chuyện có thật, tôi vẫn quên cú pháp của các sự kiện C # khi tôi phải viết chúng ra bằng tay. Nó xảy ra trong các cuộc phỏng vấn đôi khi. Tôi không gặp vấn đề gì khi viết mã trên bàn phím.

Chọn người có thể viết mã, không phải người không thể nhưng có thể nhớ cú pháp.

Khi tôi viết mã trên giấy / bảng trắng, ngay cả khi phỏng vấn xin việc, tôi về cơ bản bỏ qua một đoạn lớn cú pháp. Tôi không sử dụng dấu hai chấm, tôi thực hiện các cuộc gọi phương thức, v.v. Tôi có nhiều khả năng viết một câu giải thích 4 dòng mã thực sự cơ bản hơn chính mã. Thực sự, tôi sử dụng một mã giả giống như php và nói về những gì tôi đang làm, trong khi tôi đang làm và ghi lại những bình luận nhanh để giải thích những điều tôi che đậy (về lý thuyết, không có gì thực sự quan trọng đối với chương trình)

Mục tiêu của tôi khi viết mã trong một cuộc phỏng vấn là chỉ ra cách tôi giải quyết vấn đề, không phải chỉ ra điều gì đó mà một người đánh máy có thể nhập vào Notepad và đã chạy.

Câu chuyện dài: Tôi nghĩ bạn nên xem xét lý do tại sao lập trình viên đầu tiên có cú pháp tào lao. Anh ta rất có thể biết điều đó nhưng chỉ coi nó không liên quan đến cuộc phỏng vấn, và thích tập trung vào các phần của công việc khó khăn này (logic và giải quyết vấn đề).

Người không thể thỏa mãn một cách hợp lý câu trả lời là không đủ tiêu chuẩn. Có quá nhiều người trong ngành của chúng tôi sản xuất mã rác tuân thủ nhưng thực tế không làm những gì cần làm hoặc xử lý các lỗi hoặc các trường hợp cạnh.

Người thứ hai có thể hoặc không thể đủ tiêu chuẩn tùy thuộc vào loại và số lỗi và độ khó của những gì bạn đang mong đợi họ viết. Theo thuật ngữ SQL (ngôn ngữ tôi viết), người không thể nhớ cú pháp cho phép nối rõ ràng là không đủ điều kiện cho một công việc yêu cầu bạn truy vấn cơ sở dữ liệu - không có ngoại lệ; người không thể nhớ làm thế nào để CTE tái phạm (nhưng người biết họ tồn tại và cố gắng sử dụng một) thì không. Nói cách khác, tôi hy vọng cú pháp sẽ chính xác hơn cho mã cơ bản bạn viết mọi lúc nhưng không phải cho những thứ chỉ được thực hiện đôi khi và không phải cho cú pháp phức tạp.

Nếu tôi đang xem xét một người mà tôi biết có trình độ xuất sắc trong một lĩnh vực liên quan nhưng chỉ có kiến ​​thức tối thiểu về ngôn ngữ cụ thể của tôi, tôi có lẽ cũng sẽ tha thứ hơn cho các lỗi cú pháp. Tôi thà thuê một nhà phát triển Oracle tuyệt vời hơn là một nhà phát triển Máy chủ SQl tầm thường cho một công việc Máy chủ SQL (Tất nhiên một người SQL Server tuyệt vời sẽ là tốt nhất) và sẽ không mong đợi người đó biết cú pháp Máy chủ SQL nếu họ có thể chỉ cho tôi cách làm điều đó trong Oracle. Điều tương tự với người Java và C #, người có kỹ năng giải quyết vấn đề tuyệt vời đánh bại người có kỹ năng ngôn ngữ xuất sắc, nhưng người có cả hai chiến thắng mọi lúc (đôi khi họ rất khó tìm).