Có phải là khôn ngoan khi hỏi về các quyết định thiết kế được thực hiện trên một sản phẩm trong một cuộc phỏng vấn? [đóng cửa]

Gần đây tôi đã suy nghĩ về các câu hỏi phỏng vấn và tôi đã suy nghĩ về những kinh nghiệm phỏng vấn tồi tệ mà tôi đã có trong quá khứ. Một lưu ý đặc biệt là nơi tôi đã hỏi người phỏng vấn tại sao nhóm chọn sử dụng EJB 3 trên Spring trong sản phẩm của họ. Người phỏng vấn gần như xé mặt tôi ra, hét lên "Bởi vì Spring không phải là tất cả và chấm dứt tất cả sự phát triển phần mềm Java, bạn có muốn công việc này hay không?". Đáp lại, tôi nói với anh ấy rằng đây có lẽ không phải là công việc dành cho tôi và tôi nhanh chóng rời khỏi cuộc phỏng vấn.

Tôi đã được thông báo khi bắt đầu cuộc phỏng vấn rằng công ty có doanh thu nhân viên cao, sản phẩm họ đang làm việc ban đầu được tạo ra trong Modula-3 sau đó được chuyển đến Perl và cuối cùng là Java. Tôi đã được trao một tập sách gồm 10 trang về các câu hỏi kỹ thuật bao gồm Java, EJB, SQL và JDBC và tôi đã được hỏi về các ngăn xếp công nghệ mà tôi đã làm việc cùng. Khi được nhắc đặt câu hỏi, tôi cảm thấy thật hợp lý khi hỏi họ về ngăn xếp công nghệ của họ và nhận lại câu trả lời hợp lý, không khiến người phỏng vấn nổi lửa.

Câu hỏi: Có phải là một ý tưởng tốt để thăm dò các lựa chọn kiến ​​trúc được thực hiện trong một cuộc phỏng vấn? Nếu không, tại sao?

Theo quan điểm của riêng tôi, một cuộc phỏng vấn là một quá trình hai chiều. Nếu những người phỏng vấn đang kiểm tra tôi về các kỹ năng kỹ thuật của tôi, tôi có quyền hỏi họ những câu hỏi tương tự để:

1) Tìm hiểu suy nghĩ và thái độ của họ đối với việc phát triển phần mềm là gì. 2) Xác định xem cách tiếp cận của họ có phù hợp với cách tôi sẽ tiếp cận các vấn đề thuộc loại đó không.

Có thể người phỏng vấn tức giận có kỹ năng phỏng vấn kém và quên rằng một cuộc phỏng vấn là một cuộc trao đổi hai chiều. Nếu tôi được hỏi điều này, tôi sẽ đưa ra một câu trả lời hợp lý, nhưng tôi chắc chắn sẽ không cố gắng đưa một người được phỏng vấn vào trạng thái hiền lành mà đầu chỉ lắc lư lên xuống mà không nói chuyện.

Cá nhân, tôi thấy việc phỏng vấn mọi người gần như mệt mỏi và căng thẳng như được phỏng vấn. Nhưng đó là vì tôi đồng ý với bạn rằng quá trình phỏng vấn là một cuộc trao đổi hai chiều.

Tôi không quan tâm bạn giỏi đến mức nào, tôi không muốn thuê bạn nếu bạn không hạnh phúc khi làm việc ở đó. Đó là một trò chơi đắt tiền để chơi. Vì vậy, tôi muốn trả lời bất kỳ mối quan tâm nào của bạn và cho bạn thấy đội ngũ và sản phẩm như hiện tại, để bạn có thể đưa ra quyết định sáng suốt.

Khi tôi đang tìm việc, tôi muốn làm việc với một người có chung thái độ đó. Và, ngay cả khi tôi nghi ngờ tôi biết câu trả lời cho câu hỏi, tôi sẽ hỏi họ chỉ để xem phản ứng. Sự xâm lược không bao giờ là dấu hiệu của một người thoải mái với một tình huống.

Tôi không nói dối trong một cuộc phỏng vấn, ở hai bên bàn làm việc, bởi vì sau đó họ nghĩ rằng họ đang thuê một người khác / đi làm ở một nơi khác. Và tôi mong đợi điều tương tự trở lại, từ người ở phía bên kia của cuộc phỏng vấn.

Thật không may, điều đó có nghĩa là thỉnh thoảng tôi gặp các cuộc phỏng vấn giống như bạn đã mô tả. Có phải họ là những trải nghiệm khủng khiếp? Đúng. Tôi có đi ra khỏi đó biết chính xác cuộc phỏng vấn đã sai ở đâu không? Đúng.

Nhưng tôi có chắc chắn rằng mọi trải nghiệm khủng khiếp sẽ tồi tệ hơn đáng kể nếu tôi nhận được công việc hoặc thuê nhầm người? Đồng ý luôn.

Vâng, bạn có thể hỏi xem bạn có thực sự tò mò không và câu trả lời có quan trọng không. Tôi nghĩ rằng việc hỏi cho thấy bạn hiểu có nhiều hơn một cách để làm mọi thứ và nó cho thấy bạn quan tâm đến cách phần mềm được viết.

Điều đó đang được nói, bạn đã phải rất cẩn thận trong cách bạn đặt câu hỏi và cẩn thận gấp đôi về cách bạn tiếp tục cuộc trò chuyện. Thật dễ dàng để đi qua như thách thức quyết định của họ. Điều cuối cùng bạn muốn là người phỏng vấn tin rằng bạn nghĩ bạn thông minh hơn họ. Nếu bạn thực sự tò mò, hãy hỏi. Nếu bạn nghĩ rằng họ đã lựa chọn kém, hãy im miệng.

Nếu tôi đã ở trong tình huống được mô tả trong câu hỏi, thay vì đi ra ngoài, tôi có thể đã nói điều gì đó như "oh yeah, tôi đồng ý rằng mùa xuân chắc chắn không phải là giải pháp phù hợp cho mọi thứ. Cảm ơn vì đã cho tôi biết một chút về kiến ​​trúc của bạn! Tôi luôn tìm kiếm cái nhìn sâu sắc về cách chọn công cụ phù hợp ". (mặc dù, câu hỏi của bạn là kỳ quặc - bạn hỏi tại sao họ chọn mùa xuân và họ chọn nó bởi vì đó không phải là tất cả kết thúc?)

Là một người thường xuyên phỏng vấn mọi người, cá nhân tôi hoan nghênh một cuộc thảo luận về lý do tại sao các lựa chọn công nghệ hoặc thiết kế cụ thể được thực hiện, bây giờ chúng tôi sẽ làm gì khác nếu chúng tôi có nguồn lực xa xỉ hoặc đang bắt đầu một dự án mới. Tôi thường xem đó là một dấu hiệu về một người quan tâm đến nghề của họ, và trừ khi tín điều của họ và của chúng tôi không tương thích, tôi có thể đánh giá ứng viên đó cao hơn so với người chỉ trả lời các câu hỏi kỹ thuật thành thạo.

Tôi hiện đang làm việc trong một dự án cho một khách hàng có di sản của một số quyết định kiến ​​trúc có ý nghĩa nhưng được triển khai kém, và các ứng cử viên thể hiện sự tò mò về thế giới, và con đường phía trước như chúng ta thấy, thường là loại người chúng tôi muốn làm việc cùng. Chúng tôi muốn những người có thể thực hiện thẩm định và xác nhận phù hợp về các quyết định thiết kế và triển khai trong nhóm của chúng tôi. Chúng tôi thường đánh giá cao những người mang thứ gì đó đến bàn mà chúng tôi không có hoặc không có đủ.

Khi tôi là một ứng cử viên trong một cuộc phỏng vấn, tôi có bất kỳ dấu hiệu thù địch hoặc phòng thủ nào khi những kiểu thảo luận này xảy ra như một dấu hiệu xấu, vì một tổ chức không có khả năng tự kiểm tra thường là một vấn đề công nghệ và xử lý mà họ không có khả năng và có thể không sẵn lòng tìm cách thoát ra. Nếu tôi không thấy động lực để liên tục cải thiện đội ngũ hiện tại, có một cơ hội tốt tôi sẽ không hạnh phúc ở đó.

người đã ngủ với nhân viên bán hàng của Oracle một lần và quyết định tất cả sự phát triển trong tương lai sẽ được thực hiện bằng cách sử dụng các dịch vụ web Java 1.4, Oracle ERP và giao diện Borland C ++ bằng cách sử dụng các thành phần GUI của bên thứ 3 đã ngừng hoạt động và chúng tôi muốn chi 60.000 đô la mỗi tháng để cắm lỗ cho khách hàng từ việc nhảy tàu hơn là xem lại bất kỳ quyết định nào và thực hiện các cải tiến vĩnh viễn có thể mang lại doanh thu mới nếu chúng ta may mắn. Đừng khuấy thuyền, có chuyện gì với em vậy. "

Giả sử bạn đang ở trong một khu vực với các công việc công nghệ khác, hoặc bạn sẵn sàng di chuyển, bạn có thể có sự lựa chọn xa xỉ. Không có buổi biểu diễn nào là hoàn hảo, nhưng bạn muốn làm việc với những người muốn làm việc với bạn. (Tôi quan tâm nhiều hơn về điều này hơn các lựa chọn công nghệ cụ thể hầu hết thời gian.) Nếu một cái gì đó có mùi hôi, có lẽ là như vậy.

Vì vậy, yeah, hỏi đi. Càng tò mò về doanh nghiệp, quy trình và thiết kế của chúng tôi, tôi càng có khả năng nhận ứng cử viên nghiêm túc hơn. Nhưng tôi không làm việc tại một cửa hàng Blub, vì vậy tôi không thể nói liệu nó có giúp bạn có được một công việc Blub hay không. Tôi chỉ có thể nói rằng nó sẽ làm việc cho bạn nếu bạn muốn làm việc với những người khác quan tâm đến nghề của họ.

Câu hỏi: Có phải là một ý tưởng tốt để thăm dò các lựa chọn kiến ​​trúc được thực hiện trong một cuộc phỏng vấn? Nếu không, tại sao?

Nó hoàn toàn tốt, tôi sẽ xem nó là một tích cực.

Nếu người phỏng vấn của bạn không thể xử lý điều đó, nó nói rất nhiều về họ - không phải bạn.

Tôi sẽ lo lắng nếu một thiếu niên KHÔNG quan tâm đến các quyết định thiết kế, nó sẽ thể hiện sự thiếu tò mò / hứng thú trong lĩnh vực chủ đề và thể hiện không muốn cải thiện bản thân.

Tôi nghĩ rằng nó rất cần thiết . Tôi đã làm việc ở quá nhiều công việc với các quyết định thiết kế vô nghĩa vì không ai biết rõ hơn, không quan tâm đến việc học hoặc có sự ủy nhiệm từ ban quản lý để sử dụng bất cứ điều gì CEO đọc trên tạp chí / xem trực tuyến / có ai đó nói với anh ta là "điều lớn tiếp theo" mà không có sự xem xét thay thế. Những công việc này đều là những nơi khốn khổ để làm việc.

Bạn không nhất thiết phải chỉ trích một quyết định thiết kế trừ khi đó là điều gì đó nảy sinh khi đối mặt với lẽ thường hoặc nghe có vẻ như nói chuyện điên rồ, nhưng người ta thường đặt câu hỏi về những điều có vẻ "tắt" để tìm hiểu xem có lý do kế thừa hoặc điều gì đó xảy ra không điều đó tạo thuận lợi cho nhu cầu sử dụng một cách tiếp cận không chính thống.

Đặt câu hỏi như thế này cũng có tác dụng đo lường sự quan tâm của công ty đối với sự cải thiện và năng lực. Như một người khác đã nói ở trên, đó là một điều nếu bạn nhận được câu trả lời như (Tôi không biết Java nhưng sử dụng .NET nên sẽ sử dụng các ví dụ .NET) Khi chúng tôi viết ứng dụng không có ORM trưởng thành, vì vậy chúng tôi đã sử dụng các quy trình được lưu trữ với một lớp cổng dữ liệu. Chúng tôi muốn chuyển sang Entity Framework trong tương lai và một điều nữa hoàn toàn để có câu trả lời như Chúng tôi chỉ sử dụng các thủ tục được lưu trữ. Entity Framework trông đáng sợ và có thể cần phải tái cấu trúc và chúng tôi không thể cấu trúc lại bất cứ thứ gì vì CEO có một danh sách các tính năng mới mà anh ấy muốn chúng tôi làm việc và nếu chúng tôi dành thời gian nhìn vào Entity Framework, anh ấy sẽ sa thải chúng tôi lãng phí thời gian. Một cái cho thấy sự hiểu biết và mong muốn cải thiện, cái còn lại chỉ ra một môi trường tầm thường ở nơi tốt nhất mà mọi người đều làm tối thiểu để cạo.

Một công ty xúc phạm bạn khi đặt câu hỏi về quyết định của họ hoặc muốn thảo luận lý do tại sao họ chọn sử dụng Sản phẩm A thay vì Sản phẩm B đang chơi và cho thấy rằng họ không muốn một người suy nghĩ tự do mà là một người không biết hỏi và rất có thể đó không phải là loại công ty mà bất kỳ nhà phát triển có thẩm quyền nào cũng muốn làm việc.

Trả lời: Đó là một ý tưởng tốt để hỏi về việc ra quyết định kiến ​​trúc. Nhưng bạn cần cẩn thận với cách bạn đặt câu hỏi như vậy.

Nói một cách đơn giản: Bạn nên hỏi " Bạn đã chọn công nghệ X thay vì công nghệ Y như thế nào? ".

Bạn muốn diễn đạt nó theo cách để truyền đạt rằng bạn thường quan tâm đến quá trình ra quyết định trong nhóm. Không ai sẽ muốn đi qua mọi quyết định di sản mà công ty đã từng đưa ra với một ứng cử viên.

Khi bạn hỏi " Tại sao bạn chọn công nghệ X thay vì công nghệ Y? ", Có thể bạn sẽ không đồng ý với quyết định của họ (điều đó ổn ... nhưng có thể bị coi là thù địch) hoặc bạn muốn tự hào về mức độ của mình biết về các công nghệ trong câu hỏi (sẽ gây phiền nhiễu cho bất cứ ai), mặc dù ý định tốt của bạn.

Tôi thích yêu cầu một người phỏng vấn cho tôi biết về một quyết định thiết kế thất bại mà họ đã đưa ra, và những gì đã được thực hiện tiếp theo. Điều này cung cấp cho bạn một số thông tin tốt:

1. Nếu ông chủ không thể thừa nhận bất kỳ sai lầm hình thức hoặc thất bại tạm thời, đó là một ông chủ mà bạn có thể không muốn làm việc.
2. Bạn có thể cho biết cách công ty xử lý một tình huống căng thẳng.

Nó có thể không phổ biến, nhưng tôi luôn tôn trọng các nhà quản lý với những viên đá để nhận ra một dự án sẽ thất bại và giết nó để ngừng lãng phí, hoặc một cái gì đó đang đi sai hướng và cần phải bị giết hoặc khởi động lại .

Cuối cùng, nếu bạn đang nói về sự hài lòng của công việc, công nghệ (ngôn ngữ / nền tảng / trình biên dịch / bất cứ điều gì) không quan trọng bằng các tính cách liên quan và môi trường làm việc.

Vài năm trước, tôi đã tham gia một cuộc phỏng vấn và đã được hỏi nhiều câu hỏi kỹ thuật khác nhau về ngôn ngữ lập trình ... điều mà tôi đã không làm tốt (60/40 đúng / không chính xác). Cuộc thảo luận chuyển sang dự án họ có trong tay và tôi bắt đầu đặt câu hỏi về thiết kế và sau đó chỉ ra một vài vấn đề và hạn chế mà họ sẽ giới thiệu.

Tôi đã được mời làm việc vào ngày hôm sau. Thật không may, tôi đã không thể đưa nó lên vì lý do cá nhân.

Đặt câu hỏi về thiết kế không phải là một vấn đề nếu chúng là những câu hỏi thông minh đặc biệt là nếu sau đó bạn có thể liên hệ chúng với doanh nghiệp của họ.

Tôi đã không thực hiện nhiều cuộc phỏng vấn, nhưng, từ kinh nghiệm của bạn, tôi sẽ kết luận:

a) Sẽ ổn nếu bạn muốn đưa ra quyết định sáng suốt về việc bạn có muốn công việc đó không;

b) Không ổn nếu bạn đã quyết định bạn muốn công việc.

Mọi người có thể dễ dàng bị xúc phạm bởi những câu hỏi nhẹ nhàng về lựa chọn của họ. Đó là một đặc điểm hết sức tồi tệ, nhưng là một đặc điểm chung.

Đây là một số lời khuyên

1. Hỏi lý do tại sao họ chọn một số giải pháp hiện tại có thể là câu hỏi tồi, bởi vì có lẽ nhóm phát triển đã không có cơ hội để thay đổi hoặc chọn nó.
2. Ngoài ra, nhóm có thể đã biết tại sao công nghệ không phải là lựa chọn tốt nhất
3. Nhưng thật không may, điều cuối cùng mà bất kỳ nhóm phát triển nào cũng cần là mọi người đang cố gắng thay đổi kiến ​​trúc hoặc đặt câu hỏi cho các lựa chọn đã được đưa ra 10 năm trước - điều đó gây ấn tượng rằng công nghệ của họ đã là những thứ cũ và những thông điệp như vậy xuất hiện trong nhóm có thể khiến các nhà phát triển không hài lòng về tình hình hiện tại
4. Do đó, trong một cuộc phỏng vấn, điều cuối cùng bạn nên làm là tạo ấn tượng rằng bạn sẽ phàn nàn mọi lúc về các lựa chọn mà nhóm không kiểm soát được