Tại sao cấu trúc dữ liệu rất quan trọng trong các cuộc phỏng vấn? [đóng cửa]


106

Tôi phải thú nhận rằng tôi không quá mạnh về cấu trúc dữ liệu khi tôi tốt nghiệp đại học. Trong suốt các vị trí trong khuôn viên trường trong khi tốt nghiệp, tôi đã chứng kiến ​​rằng hầu hết các công ty công nghệ lớn như Amazon, Microsoft, vv tập trung chủ yếu vào các cấu trúc dữ liệu. Nó xuất hiện như thể cấu trúc dữ liệu là điều duy nhất mà họ mong đợi từ một sinh viên tốt nghiệp.

Thành thật mà nói, tôi cảm thấy tồi tệ về điều đó. Tôi viết mã tốt. Tôi tuân theo các mẫu thiết kế mã hóa tiêu chuẩn, tôi sử dụng các cấu trúc dữ liệu nhưng ở mức độ hời hợt như trong các API tiếp xúc với Java như ArrayList, LinkedList, v.v. Nhưng các công ty thường tập trung vào các khía cạnh phức tạp của Cấu trúc dữ liệu như thao tác bộ nhớ dựa trên con trỏ và độ phức tạp thời gian.

Có lẽ vì nền tảng Java của tôi, hồi đó, tôi chỉ hiểu hiệu quả mã và logic khi nói về Lập trình hướng đối tượng như các đối tượng, cá thể, v.v. nhưng tôi chưa bao giờ đi sâu vào mức độ bit và byte. Tôi không muốn mọi người coi thường tôi vì sự thiếu hụt kiến ​​thức này của tôi trong Cấu trúc dữ liệu.

Vì vậy, thực sự tại sao tất cả nhấn mạnh vào cấu trúc dữ liệu?


36
Tôi không thực sự nhận được câu hỏi của bạn. Bạn nói "Tôi viết mã tốt" - làm thế nào cấu trúc dữ liệu không phải là một phần của mã tốt. Và, tôi nghi ngờ bất kỳ người phỏng vấn chân thành nào sẽ bị ám ảnh quá mức với họ.
treecoder

6
@greengit: Có sự khác biệt giữa việc triển khai bản đồ băm và sử dụng API của nó. Những gì tôi sẽ đánh giá cao trong một cuộc phỏng vấn là nếu họ mô tả một ứng dụng cho tôi, sau đó yêu cầu tôi xây dựng các cấu trúc dữ liệu trung tâm và giải thích các lựa chọn của tôi.
Gyorgy Andottok

7
Bạn muốn được hỏi điều gì?
cám dỗ

13
@Jurily - Để hiểu khi nào nên sử dụng thư viện container, sẽ giúp có một số kiến ​​thức về cách cấu trúc dữ liệu cơ bản hoạt động. Thật khó chấp nhận rằng bạn biết về hiệu quả của mã nếu bạn không biết sự phức tạp về thời gian và không gian của các thư viện bạn đang sử dụng - chỉ vì nó hoạt động tốt trên các bộ dữ liệu thử nghiệm nhỏ không có nghĩa là nó sẽ mở rộng tốt cho các bộ dữ liệu lớn hơn trong thế giới thực. IMO, hiểu được sự phức tạp về thời gian và không gian cũng là một phần của việc hiểu API cũng như biết tên lớp và phương thức - có lẽ vì thế, vì intellisense sẽ không cho bạn biết sự phức tạp.
Steve314

2
Một cấu trúc dữ liệu tốt cho mã sạch, đơn giản. Một cấu trúc dữ liệu xấu cho mã phức tạp. Điều quan trọng là phải làm đúng.

Câu trả lời:


121

hầu hết các công ty công nghệ lớn như Microsoft tập trung chủ yếu vào cấu trúc dữ liệu. Nó xuất hiện như thể cấu trúc dữ liệu là điều duy nhất mà họ mong đợi từ một sinh viên tốt nghiệp.

Không, có nhiều hơn. Ví dụ: chúng tôi cũng hy vọng rằng bạn là người học nhanh, có thể học các khung, API mới hoặc thậm chí các ngôn ngữ lập trình trong một khoảng thời gian ngắn. Đó là một thanh tối thiểu trần. Một người mất nhiều thời gian để tìm hiểu một khuôn khổ, API hoặc ngôn ngữ mới sẽ không trở thành nhà phát triển thành công trên hầu hết các nhóm tại Microsoft.

Và tất nhiên còn nhiều khía cạnh khác mà chúng tôi tập trung vào trong các cuộc phỏng vấn ngoài việc chỉ là kiến ​​thức thô về cấu trúc dữ liệu. Khả năng xử lý các thông số kỹ thuật mơ hồ, ví dụ, hoặc khả năng nhận ra các mẫu mã hóa tạo ra mã không an toàn hoặc hàng tá thứ khác. Nhưng khả năng hiểu cấu trúc dữ liệu chắc chắn là một điều rất lớn.

Điều đặc biệt là các cuộc phỏng vấn thiên về kiểm tra kiến ​​thức về cấu trúc dữ liệu cho sinh viên tốt nghiệp CS gần đây. Sinh viên tốt nghiệp gần đây, hầu hết những người không có nhiều kinh nghiệm trong thế giới thực, không được kỳ vọng sẽ giỏi những điều tương tự mà một người có mười lăm năm kinh nghiệm trong ngành sẽ giỏi.

Tôi phải thú nhận rằng tôi không quá mạnh về cấu trúc dữ liệu

Thật tốt khi bạn biết điều đó về bản thân. Nếu bạn không thể hoặc không muốn thay đổi điều đó về bản thân thì lời khuyên của tôi là bạn không nên xin việc với cơ sở có cấu trúc dữ liệu.

có quan điểm chung rằng một lập trình viên giỏi nhất thiết phải là người có kiến ​​thức tốt về cấu trúc dữ liệu.

Điều quan trọng là một lập trình viên giỏi là một lập trình viên giỏi xây dựng các loại chương trình cần được xây dựng. Rất nhiều lập trình viên làm việc trên các nhiệm vụ không đòi hỏi kiến ​​thức sâu về cấu trúc dữ liệu. Một số trong số họ làm việc trên các nhiệm vụ đòi hỏi kiến ​​thức sâu về thiết kế giao diện người dùng, ví dụ. Hoặc chuẩn hóa cơ sở dữ liệu. Hay bất cứ cái gì. Những người đó vẫn có thể là "lập trình viên giỏi" trong lĩnh vực của họ.

Tại sao tất cả điều này nhấn mạnh vào Cấu trúc dữ liệu?

Tôi đặt câu hỏi phỏng vấn về cấu trúc dữ liệu bởi vì trong nhóm của tôi, các nhà phát triển thiết kế, thực hiện và thao tác các cấu trúc dữ liệu phức tạp cả ngày mỗi ngày. Hôm qua chúng tôi đã có bốn giờ họp trong đó một nửa nhà phát triển đã tranh luận về những ưu và nhược điểm của việc thêm trường Boolean duy nhất vào một nút cây cụ thể. Có lẽ không có kỹ năng nào trong nhóm của tôi quan trọng hơn khả năng hiểu cấu trúc dữ liệu ở mức độ sâu. Sẽ thật ngu ngốc nếu không đặt câu hỏi phỏng vấn về nó, vì đó là những gì chúng ta làm.

Không có kiến ​​thức về Cấu trúc dữ liệu có thực sự ảnh hưởng đến sự nghiệp lập trình của một người không?

Vâng, nó chắc chắn sẽ ngăn bạn nhận được một công việc trong nhóm của tôi. Nhưng như tôi đã nói trước đây, lập trình là một lĩnh vực rất lớn . Có rất nhiều loại lập trình máy tính không đòi hỏi kiến ​​thức về cấu trúc dữ liệu.

kiến thức trong môn học này có thực sự là cơ sở đủ để phân biệt một lập trình viên tốt và xấu không?

Không. Nhưng hầu như luôn luôn đủ để phát hiện các nhà phát triển không có khả năng thành công tại Microsoft. Vì đó là điều tôi chủ yếu quan tâm trong việc phát hiện, kiến ​​thức về cấu trúc dữ liệu là một trong những yếu tố tôi kiểm tra trong các cuộc phỏng vấn.


10
Cảm ơn rất nhiều Eric! Đây là câu trả lời ít gây khó chịu nhất mà tôi có cho câu hỏi của mình. :-)
Vamsi Emani

2
@EricLippert, cảm ơn bạn vì câu trả lời tuyệt vời này. Là một nhà phát triển tự học, người vẫn chưa bị cắn bởi sự thiếu hiểu biết chính thức về cấu trúc dữ liệu, bạn có đề xuất một cuốn sách có thể cho tôi thấy những gì tôi đã bỏ lỡ không?
Đóng cửa Cowboy

5
@Clenses Cowboy: Đối với những điều cơ bản về cấu trúc dữ liệu và thuật toán, "Giới thiệu về thuật toán" của Cormen, Leieserson và Rivest là sách giáo khoa tiêu chuẩn. Nếu bạn quan tâm đến cấu trúc dữ liệu theo phong cách chức năng, cuốn sách của Chris Okasaki rất hay nhưng khá tiên tiến.
Eric Lippert

2
@ClensesCowboy Kiểm tra khóa học 'Thuật toán tôi' của Coursera do Princeton cung cấp. Tôi cũng là một lập trình viên tự học và nó làm rất nhiều để giúp lấp đầy lỗ hổng kiến ​​thức về lý thuyết CS.
Evan Plaice

133

Một điểm quan trọng về cấu trúc dữ liệu là chúng có tính phổ quát và vượt thời gian, ít nhất là cho các mục đích thực tế. Bất cứ ai là nhà phát triển trong 30 năm qua nên biết các cấu trúc dữ liệu cơ bản như danh sách liên kết đơn / đôi, cây nhị phân hoặc biểu đồ. Nếu bạn hỏi hai nhà phát triển về họ, bạn có thể so sánh kiến ​​thức của nhà phát triển bằng câu trả lời của họ. Điều này khó có thể nói cho các khung hoặc thậm chí các ngôn ngữ: Nếu bạn hỏi hai nhà phát triển về Rails, và một người biết nhiều hơn cái kia, điều đó thực sự nói gì với bạn? Như bạn nói trong câu hỏi, một nhà phát triển thông minh có thể học một khuôn khổ mới đủ nhanh, vì vậy việc kiểm tra kiến ​​thức hiện tại của họ không có ý nghĩa gì nhiều.

Liệu, Không có kiến ​​thức về Cấu trúc dữ liệu có thực sự ảnh hưởng đến sự nghiệp của một người trong lập trình không?

Đúng. Chắc chắn rồi. Trừ khi bạn muốn dành cả đời để viết các ứng dụng CRUD.

Hay kiến ​​thức trong môn học này thực sự là một cơ sở đủ để phân biệt một lập trình viên tốt và xấu?

Không, nó không đủ. Nhưng có một vài điều bạn có thể yêu cầu trong một cuộc phỏng vấn việc làm là đủ. Và tôi muốn nói rằng kiến ​​thức về thuật toán là một trong những chỉ số tốt hơn, ít nhất là đối với những người mới ra trường, nơi bạn không thể hỏi về kinh nghiệm làm việc.


Một chút xíu, tôi sẽ không nói rằng các cơ sở dữ liệu là vô tận. Rất nhiều cấu trúc được mô hình hóa để giải quyết các vấn đề với phần cứng ngày nay. Chẳng hạn, chúng tôi sử dụng Cây B + để tối ưu hóa tìm kiếm trên các trang tệp nhưng phần cứng bên dưới đang thay đổi. Có lẽ SSD có thể yêu cầu các thuật toán khác nhau hoặc có thể di chuyển theo hướng truy cập RAM nhiều hơn so với đĩa io. Vì vậy, mặc dù thuật toán tự nó có thể là "vượt thời gian" nhưng đó là mục đích và mục đích không phải là
Homde

3
@konrad: Đó là ý của tôi "vì mục đích thực tế". Tôi không thể nghĩ về một cấu trúc dữ liệu hoặc thuật toán đã trở nên "lỗi thời" và tôi nghi ngờ bạn sẽ gặp một người trong một cuộc phỏng vấn xin việc. Và vì hầu hết các thuật toán / cấu trúc dữ liệu đã được phát triển từ lâu trước phần cứng hiện tại của chúng tôi và vẫn còn hữu ích, tôi thậm chí còn đoán được có một loại kết hợp nào đó đang diễn ra, nơi các phát triển phần cứng mới được hướng dẫn bởi các cấu trúc dữ liệu mà chúng tôi biết.
nikie

Nếu / Khi đồng thời trở thành bắt buộc trên thực tế, tôi có thể nghĩ về rất nhiều cấu trúc dữ liệu trở nên lỗi thời :)
Homde

9
@konrad: Và nếu / khi máy tính lượng tử trở thành tiêu chuẩn, tôi có thể nghĩ thêm một vài thứ nữa. Nhưng tôi cho rằng OP không muốn chờ đợi với các cuộc phỏng vấn xin việc của anh ấy cho đến lúc đó ;-)
nikie

3
... hoặc khi các lớp phủ AI mới của chúng ta làm cho các lập trình viên con người bị
trừng phạt

45

Tôi là người học nhanh và tôi có thể học các khung, API hoặc thậm chí các ngôn ngữ lập trình mới trong khoảng thời gian ngắn đáng kể.

Không nghe có vẻ quá khắc nghiệt, nhưng bất kỳ nhà phát triển nửa vời nào cũng có thể chọn một ngôn ngữ hoặc khung mới trong một khoảng thời gian tương đối ngắn.

Các cấu trúc dữ liệu là phổ quát, chúng là một khối xây dựng cơ bản của khoa học máy tính - một cây đỏ đen về cơ bản là giống nhau, cho dù nó được triển khai trong Java, Python, PHP hay bất cứ thứ gì. Vì vậy, thay vì kiểm tra các ngôn ngữ cụ thể hoặc các khung cụ thể, một nhà tuyển dụng (ít nhất là một nhà tuyển dụng đang tìm kiếm các nhà phát triển nổi bật) sẽ kiểm tra xem bạn có biết các nguyên tắc cơ bản của khoa học máy tính hay không, thay vì chỉ là bất cứ thứ gì trong tháng. hiện đang sử dụng.

(ít nhất, họ nên kiểm tra các nguyên tắc cơ bản bên cạnh bất cứ thứ gì họ đang sử dụng ... không cần phải thuê một phù thủy khoa học máy tính nếu anh ta không bao giờ viết một dòng mã trong cuộc đời mình)


1
Khoa học máy tính là một trong những từ khóa ở đây. Cấu trúc dữ liệu thường được nhìn thấy sâu trong Master và rõ ràng là một chủ đề quan trọng.
James P.

1
Cấu trúc dữ liệu là phổ quát cho đến khi bạn bị cuốn hút vào lập trình chức năng thuần túy: P.
Tikhon Jelvis

30

Bạn có tin rằng các tay đua F1 chỉ lái những chiếc xe nhanh? Không, họ hiểu chiếc xe họ lái và họ làm việc với các thợ máy / kỹ sư để điều chỉnh nó. Tất nhiên, một trình điều khiển bình thường chỉ cần lái xe.

Bạn có thể là một lập trình viên bình thường / trung bình chỉ viết mã. Bạn không hiểu những gì đằng sau. Bạn hoàn thành công việc Đó là tất cả, hẹn gặp lại vào ngày hôm sau.

Nhưng nhiều công ty tìm kiếm các nhà phát triển F1. Những người sẽ phát triển biết những gì đằng sau mã của họ. Những người cũng sẽ giúp công ty xây dựng một cái gì đó tốt hơn.

Thật tuyệt khi biết cấu trúc dữ liệu không chỉ bởi vì bạn sẽ sử dụng chúng ở dạng "nấu sẵn" rất nhiều. Điều đó cũng tốt vì bạn sẽ tạo ra thứ gì đó xuất phát từ ý tưởng của họ.



Vì vậy, chờ đã, bạn đang nói rằng có một mối tương quan giữa việc tôi là một lập trình viên và thói quen kỳ quặc của tôi là làm quen với một chiếc xe hơi trước khi tôi lái nó?
Robbie

@Robbie: +1 LOL Bạn có thích tháo gỡ mọi thứ không?
liệu

2
Vâng Bố tôi dạy tôi cách tách rời mọi thứ . Anh bỏ bê việc dạy tôi làm thế nào để đặt mọi thứ lại với nhau, đã tìm ra điều đó trong suốt cuộc đời tôi.
Robbie

17

Trong lớp học về cấu trúc dữ liệu của tôi, điều đầu tiên mà giáo sư nói là: Lớp học này không phải là về khả năng tìm kiếm thực sự nhanh chóng. Sau đó chúng tôi đã dành nửa năm để tìm ra các cấu trúc dữ liệu và thuật toán tốt nhất có thể để tìm kiếm thực sự nhanh chóng.

Tuy nhiên, anh vẫn đúng. Để có thể phân tích cấu trúc dữ liệu, áp dụng cấu trúc dữ liệu phù hợp cho một vấn đề nhất định hoặc thậm chí đưa ra cấu trúc dữ liệu mới đòi hỏi nhiều phẩm chất của một kỹ sư:

  • Tìm kiếm sự trừu tượng để mô hình hóa một vấn đề cụ thể
  • Có thể phân hủy các vấn đề
  • Có thể suy luận logic / chính thức
  • Sáng tạo
  • Vân vân.

Khi Amazon và Microsoft thuê người, họ không đặt câu hỏi về cấu trúc dữ liệu vì họ hy vọng sẽ phát minh ra quicksort tiếp theo . Họ muốn đảm bảo rằng họ thuê một người có phẩm chất nêu trên.

Tất nhiên, có thể có một tập hợp lớn các phẩm chất này và vẫn hút các cấu trúc dữ liệu. Nhưng sau đó, nếu đó là trường hợp, bạn sẽ không mất nhiều thời gian để trở thành một chuyên gia về cấu trúc dữ liệu.


Điều đó đang được nói, vẫn còn vấn đề ArrayListchỉ là không hoàn toàn quy mô. Khi hệ thống trở nên lớn, cần có các giải pháp thích nghi tốt hơn để thực hiện công việc. Và nếu không nắm bắt tốt các cấu trúc dữ liệu, bạn sẽ không thể tìm và soạn các cấu trúc và thuật toán có tỷ lệ lớn trong kịch bản cụ thể của bạn.


3
Và liên quan ArrayList, nếu không nắm bắt tốt các cấu trúc dữ liệu, bạn thậm chí có thể không nhận ra rằng ArrayListnó không hoàn toàn theo tỷ lệ và bạn cần tìm và soạn các cấu trúc và thuật toán theo tỷ lệ.
phoog

12

Nói chung, các thuật toán và cấu trúc dữ liệu được coi là hai trong số các chủ đề "cốt lõi nhất" trong lập trình. Điều này là do có một khối lượng lớn công việc và nghiên cứu liên quan đến họ trong khoa học máy tính. Họ cũng thu hút các "lập trình viên" thùy trái "điển hình thích những thứ như toán học và khoa học (vốn là rất nhiều lập trình viên)

Điều đó đang được nói, kiến ​​thức về những điều này có thể ảnh hưởng đến sự nghiệp của bạn về mặt phỏng vấn, đặc biệt nếu bạn phỏng vấn tại nơi làm việc định hướng kỹ thuật như google. Tuy nhiên, các công ty khác bây giờ có thể quan tâm đến khía cạnh đó.

Theo kinh nghiệm của tôi, nhu cầu về thuật toán / cấu trúc dữ liệu đôi khi có thể xuất hiện dưới dạng "tinh hoa lập trình viên" nơi các chuyên viên máy tính alpha đang chạy đua để thể hiện ai là người thông minh nhất. Thật tốt khi biết những gì ngoài kia, nhưng có rất nhiều công việc lập trình khác nhau mà bạn sẽ không bao giờ cần phải biết cách sử dụng cây đỏ / đen hoặc mã hóa tìm kiếm boyer-moore.

Tôi khuyên bạn nên tìm hiểu thêm về các chủ đề nếu bạn thấy chúng thú vị và có một số dự án cá nhân nơi bạn có thể sửa đổi chúng, nếu không bạn có thể có được mà không cần đến chúng ngay bây giờ

Tái bút Sự thành thạo với các cấu trúc dữ liệu thô sơ (danh sách được liên kết, từ điển, hashtables, v.v.) nên là kiến ​​thức bắt buộc đối với bất kỳ lập trình viên DS nào.


7

Vì vậy, thực sự tại sao tất cả nhấn mạnh vào cấu trúc dữ liệu?

Hai lý do.

Đối với một điều, nó cho thấy bạn có thể suy nghĩ về vấn đề theo thuật ngữ trừu tượng, hơn là về ngôn ngữ lập trình cụ thể. Bạn có biết tại sao bảng băm có thể là lựa chọn tốt hơn hoặc tồi tệ hơn cây đỏ đen trong một tình huống nhất định, bất kể việc triển khai cơ bản không?

Đối với một người khác, có một số người đáng sợ ngoài kia đang phỏng vấn cho các công việc chỉ đơn giản là nói dối về kinh nghiệm của họ và có rất ít nếu có khả năng lập trình; câu hỏi cấu trúc dữ liệu là một cách nhanh chóng để loại bỏ những người này.


Tôi sẽ trình bày một ý kiến ​​ở đây có khả năng gây tranh cãi. Câu hỏi tại sao một cấu trúc dữ liệu này hay cấu trúc dữ liệu khác có xu hướng giảm hiệu quả và hiệu suất. Chúng ta bảo các nhà phát triển không làm gì? Không tối ưu hóa sớm! Trừ khi bạn biết bằng cách định hình rằng sự lựa chọn cấu trúc dữ liệu đang gây ra vấn đề về hiệu suất, thì 'quyền' được chọn là thứ bạn quen thuộc nhất. Bất kỳ quyết định nào khác là tối ưu hóa sớm, và do đó xấu xa!
Tom W

2
Chọn các cấu trúc dữ liệu phải lên phía trước dựa trên khả năng ứng dụng và dự kiến đặc tính hiệu suất một cách độc lập việc thực hiện cơ bảnkhông một ví dụ về tối ưu hóa quá sớm.
John Bode

Chọn đống heap trên đống nhị phân có thể được. Sử dụng heap vs list (khi heap phù hợp) thì không.
dùng470365

5

Chúng là cơ bản, nhưng cũng có thể, bạn sẽ đố sinh viên tốt nghiệp về cái gì? Họ có thể có hoặc không có kinh nghiệm ngoài công việc khóa học của họ. Khóa học của họ có thể đã bao trùm các công nghệ của Microsoft hơn là nói Java hoặc ngược lại. Cấu trúc dữ liệu là mặt bằng chung.


+1 cho những gì khác bạn sẽ đố sinh viên tốt nghiệp trên, vì không có gì khác mà tất cả sinh viên tốt nghiệp comp sci nên biết rằng bạn cũng biết.
Ian

4

Thông thường, mã tốt nhất sẽ tránh phát minh lại cấu trúc dữ liệu cấp thấp. Điều này đặc biệt đúng trong các ngôn ngữ cấp cao. Tôi đã nhận thấy một xu hướng đối với các câu hỏi về cấu trúc dữ liệu cấp thấp ngay cả trong các công việc CRUD. YMMV, nhưng dường như sự nhấn mạnh vào chuyên môn của nhà khoa học hacker đã làm lu mờ các kỹ năng khác làm nên một nhà phát triển vĩ đại:

  • quản lý dự án / thời gian: có thể theo kịp thế giới thực do doanh nghiệp điều hành, không phải là một danh sách liên kết mới hoạt động nhanh hơn 1%.
  • một lượng kỹ năng xã hội tối thiểu: một nhà phát triển kiêu ngạo và không thể hòa đồng không gì khác ngoài một mỏ neo.
  • khả năng học hỏi những điều mới một cách nhanh chóng và liên tục: cấu trúc dữ liệu hầu như không thay đổi qua nhiều năm ... nhưng mọi thứ khác thì có. Cấu trúc dữ liệu là những nguyên tắc cơ bản tuyệt vời và mọi nhà phát triển nên biết chúng khá rõ, nhưng một kế toán viên không được kiểm tra các kỹ năng phân chia dài của họ khi họ đi phỏng vấn. Những nhà phát triển tuyệt vời là kiểu người có thể tìm ra những điều mới và thích nó.

Cấu trúc dữ liệu là tuyệt vời. Cấu trúc dữ liệu rất quan trọng. Mỗi lập trình viên nên có một sự hiểu biết về họ. Tuy nhiên, chúng tôi đã bị ám ảnh với việc đẩy những nguyên tắc cơ bản này ra khỏi vị trí của chúng. Nó không phải là TẤT CẢ về cấu trúc dữ liệu và trong 99% trường hợp không cần phải đặt câu hỏi ngoài những điều cơ bản của cấu trúc dữ liệu. Nếu bạn đang phỏng vấn một kế toán viên, chắc chắn hãy hỏi họ 81 số chia cho 9 là bao nhiêu, nhưng nếu bạn cứ hỏi "căn bậc hai của 98425454242412 * 4512324 là gì? ... mà không cần máy tính!" sau đó bạn sẽ sợ một tỷ lệ tốt của những người hợp lý, thông minh, tài năng và dễ chịu mà bạn có thể có. Hỏi xem họ có thể xây dựng mô hình dữ liệu quan hệ cơ bản không, hỏi xem họ có thể sử dụng các cấu trúc mảng nâng cao được cung cấp bởi khung có liên quan không, và hỏi xem họ có thể giải thích khi tìm kiếm nhị phân nhanh hơn tìm kiếm phẳng không, nhưng không có nhiều điểm vượt quá điều đó. Nếu họ có thể làm những việc đó, thì hãy bắt đầu tìm kiếm một trong những người đẹp nhất, chuyên nghiệp nhất, sáng tạo nhất trong số đó.

Tôi yêu văn bản của Joel, nhưng tôi nghĩ điều "Trường học Java" của anh ấy đã sai. Có rất nhiều điều có thể chứng minh ai đó thông minh ngoài việc thành thạo C ++. Hãy suy nghĩ về điều này, bạn có thể nói chuyện với ai đó trong 10 phút mà không cần hỏi họ về vấn đề con trỏ và có một ý tưởng khá hay về việc họ có phải là người có thể hoàn thành công việc hay không. Chúng ta không cần phải như thế này:

Người phỏng vấn: "Hãy cho tôi biết về thành tích của bạn."

Coder: "Ở vị trí cuối cùng của tôi, tôi là nhà phát triển duy nhất cho một hệ thống ERP tùy chỉnh cho một công ty tài chính tỷ đô. Chúng tôi đã giao hàng trước thời hạn và hệ thống đã được sản xuất trong 3 năm qua."

Người phỏng vấn: "Hãy để tôi làm rõ. Hãy cho tôi biết về thành tích lập trình của bạn "

Bộ giải mã: "Ưm ..."

Người phỏng vấn: "Ví dụ, bạn đã bao giờ lập danh sách liên kết của riêng mình chưa?"

Coder: "... [đi ra ngoài]"


Thú vị - danh sách tốt. Làm thế nào về một cái nhìn hơi khác nhau về nó? 1. quản lý dự án / thời gian: có thể chuẩn bị mọi thứ theo cách mà cấu trúc dữ liệu chỉ lãng phí một phần nhỏ thời gian phỏng vấn. 2. một lượng kỹ năng xã hội tối thiểu: một nhà phát triển có khả năng hiểu rằng người phỏng vấn thường muốn nhanh chóng kiểm tra các cấu trúc dữ liệu cơ bản trước khi tiến tới các khu vực thú vị hơn. 3. khả năng học hỏi những điều mới một cách nhanh chóng và liên tục mà không bị phân tâm có thể do thiếu kiến ​​thức cơ bản về cấu trúc dữ liệu.
gnat

@gnat - Điều đó cũng tốt. Tôi đoán những gì tôi đang nhận được là sự hiểu biết sâu sắc nhất về các nguyên tắc cơ bản không nói lên khả năng tổng thể qua một điểm nhất định, nhưng có một xu hướng giả định ngược lại. Cấu trúc dữ liệu là thứ mà hầu hết mọi người được dạy bởi người khác (thường là giáo viên). Tôi muốn biết những gì họ có thể tự học, bởi vì đó là cách thế giới thực hoạt động. Các lập trình viên giỏi có thể thiết kế các hệ thống hợp lý dựa trên các thực tiễn tốt nhất. Các lập trình viên tuyệt vời có thể học các hệ thống điên rồ được viết bởi các lập trình viên khủng khiếp bằng cách sử dụng các thực tiễn tồi tệ nhất và làm cho chúng hoạt động.
Morgan Herlocker

1
Tôi có thể tưởng tượng rằng anh chàng làm việc trong hệ thống ERP không phù hợp với nhóm.
Christopher Mahan

4

Trở thành một lập trình viên giỏi không phải là có thể học ngôn ngữ và khung. Đó là về việc có thể xây dựng các giải pháp cho các vấn đề phức tạp. Để các giải pháp này có hiệu quả và đáng tin cậy, hầu như sẽ luôn dựa vào các thuật toán tốt và sử dụng cấu trúc dữ liệu phù hợp. Biết các cấu trúc dữ liệu tồn tại là không đủ. Bạn cần hiểu cấu trúc dữ liệu sẽ đủ để sử dụng đúng cấu trúc cho vấn đề. Danh sách và bản đồ cung cấp một số tính năng có giá trị, nhưng chúng đi kèm với chi phí và sử dụng sai có thể làm giảm đáng kể hiệu suất của phần mềm của bạn.

Một người phỏng vấn giỏi biết điều này và đang cố gắng xác định xem bạn có thể có giá trị với nhóm hoặc công ty của anh ấy không. (Các) ngôn ngữ bạn sẽ sử dụng 2 năm kể từ bây giờ có thể rất khác nhau, nhưng nhu cầu về các thuật toán và cấu trúc dữ liệu hiệu quả sẽ không thay đổi.


2

Cấu trúc dữ liệu, độ phức tạp thời gian, thao tác bộ nhớ và con trỏ đều là những nguyên tắc cơ bản mà ai đó tự gọi mình là Nhà khoa học máy tính nên vô tình biết. Bất kỳ con khỉ mã nào cũng có thể học một ngôn ngữ và học cách sử dụng nó, nhưng nơi các chuyên gia và sinh viên CS nên tự đặt ra là biết không chỉ cách sử dụng danh sách được liên kết hoặc bản đồ băm, mà TẠI SAO.

TẠI SAO là những gì thực sự làm cho tất cả chúng ta khác biệt với kịch bản cơ bản kiddie, khỉ mã và người cằn nhằn của thế giới điện toán. TẠI SAO sử dụng bảng băm thay vì danh sách được liên kết, TẠI SAO bảng băm của tôi phải ở mật độ cụm khoảng .6-.8, TẠI SAO tôi nên sử dụng danh sách liên kết tròn ở đây thay vì danh sách được liên kết đôi. TẠI SAO mã của tôi phải chạy ở hiệu quả 'x' trong trường hợp xấu nhất và 'y' trong trường hợp trung bình.

Những cấu trúc dữ liệu cơ bản và kiến ​​thức về không chỉ CÁCH sử dụng chúng (dù sao thì mọi người nên lập trình lại như thế nào) mà là bất khả tri ngôn ngữ TẠI SAO chúng được sử dụng, có xu hướng giống với những gì chúng đang tìm kiếm trong những trường hợp này.

Nhiều nơi sẽ khiến bạn viết mã bằng ngôn ngữ mà bạn quen thuộc, nhưng đó là tính tổng quát hơn, vì C thực sự không phải là ngôn ngữ của thế giới lập trình nữa và cấu trúc mã giả có thể là một sự nhầm lẫn và tất cả tại chỗ và, trong hầu hết các trường hợp với mã giả / mã p & p không thực sự được dạy, không thể xử lý được.


0

Cấu trúc dữ liệu là nền tảng cơ bản của tất cả các chương trình. Bạn không nhất thiết phải có hiểu biết sâu sắc về họ, nhưng bạn nhất định phải biết cách họ làm việc.

Tại sao? Bởi vì tất cả các mã của bạn tương tác với và thao tác dữ liệu. Nếu tập dữ liệu không thể được lưu trữ trong một cấu trúc, thì nó không thể được sử dụng. Dữ liệu giống như vật liệu xây dựng của một ngôi nhà. Cho đến khi bạn đặt nó lại với nhau thành một cấu trúc, bạn chỉ có một đống ván vô dụng.

Khi bạn đã quyết định cách suy nghĩ và xác định tập dữ liệu của mình, thì bạn có thể bắt đầu sử dụng nó để thực hiện mọi việc, phần thuật toán cổ điển của bộ đôi này. Mỗi chương trình bạn viết đều sử dụng cấu trúc dữ liệu, mặc dù trong nhiều trường hợp, cấu trúc này rất đơn giản đến mức gần như không tồn tại. Một vài biến cho dữ liệu trạng thái và chúng ta đã hoàn thành!

Một khi bạn vượt ra ngoài các chương trình tầm thường, hầu hết mọi thứ đều yêu cầu cấu trúc dữ liệu. Bạn thích cái nào hơn, một kiến ​​trúc sư chuyên nghiệp, người thiết kế tòa nhà chọc trời của bạn với những thực tiễn và toán học tốt nhất, hay chú joe bob, người ngay lập tức bắt đầu xây dựng?


-2

Để xây dựng dựa trên những gì @Pelshoff nói , đó là thể hiện rằng bạn biết bạn đang làm gì. Nếu bạn sử dụng LinkedList cho mọi thứ, điều đó có thể cho thấy bạn không biết bạn đang làm gì hoặc bạn không quan tâm đến việc dừng lại và suy nghĩ về vấn đề. Trên hết, ít nhất là khóa học về cấu trúc dữ liệu mà tôi đã đề cập, lý thuyết cơ bản, phức tạp về các cấu trúc dữ liệu đó, khi xử lý các tập dữ liệu lớn là rất quan trọng. Đó sẽ là lý do tại sao các công ty như Amazon hay Microsoft sẽ làm một việc như vậy.

Tôi phải nói rằng, trước khi tôi tham gia một lớp cấu trúc dữ liệu, tôi đã nghĩ rằng chúng không quan trọng nhưng ít nhất có thể thu lại khi danh sách được liên kết (hoặc ArrayList) không thực tế hoặc những gì mặt sau của chúng là quan trọng.


"Nếu bạn sử dụng LinkedList cho mọi thứ, điều đó có thể cho thấy bạn không biết bạn đang làm gì" hoặc bạn là lập trình viên Lisp :-)
Peter Alexander

@Peter - sau đó sẽ chứng minh quan điểm của tôi bạn không biết bạn đang làm gì! ;)
Jetti

điều này dường như được dựa trên một liên kết chết để trả lời bị xóa - khá khó hiểu cho độc giả. Bạn có phiền chỉnh sửa ing để chăm sóc điều này?
gnat

-2

Cho dù bạn viết mã tốt hay không là một tuyên bố chủ quan. Điều quan trọng cần biết là mã chức năng không phải lúc nào cũng tạo ra mã tốt.

Điều đó nói rằng, cấu trúc dữ liệu rất quan trọng bởi vì chúng giống như những nhân viên hậu trường mà bạn, với tư cách là lập trình viên, đang chỉ đạo. Đúng là bạn có thể gọi các phương thức trên một cấu trúc mà không thực sự hiểu nó đang làm gì và bạn có thể sử dụng một cấu trúc mà không thực sự hiểu cách lưu trữ dữ liệu, nhưng biết những chi tiết này sẽ giúp bạn hiểu rõ hơn khi sử dụng một cấu trúc phù hợp hơn khác.

Chẳng hạn, biết rằng bạn có thể đi qua cả hai hướng thông qua danh sách liên kết đôi và chỉ chuyển tiếp qua danh sách liên kết đơn có thể giúp bạn xác định cấu trúc nào là quan trọng khi lưu trữ dữ liệu. Bạn có thể đưa ra quyết định giáo dục nhiều hơn bằng cách biết rằng danh sách liên kết đơn có khả năng có mức chi phí bộ nhớ thấp hơn (vì nó không chứa con trỏ đến các yếu tố trước đó), vì vậy, nếu bạn chỉ cần lặp lại qua danh sách, bạn có thể tiết kiệm một số bộ nhớ bằng cách sử dụng một cấu trúc phù hợp.

Đây chỉ là những ví dụ nhỏ và cuối cùng, nếu bạn cảm thấy mình đang làm tốt trong sự nghiệp mà không có kiến ​​thức sâu sắc về cấu trúc dữ liệu thì có lẽ bạn không cần phải tìm hiểu thêm. Hiểu những gì đang diễn ra dưới mui xe, tuy nhiên, thực sự có thể giúp biến mã chức năng thành mã tốt.


-3

Cấu trúc dữ liệu là các khối xây dựng của nhiều thứ bạn muốn làm. Nếu bạn biết sử dụng cho từng cấu trúc dữ liệu, điểm yếu và điểm mạnh của nó thì bạn có thể dễ dàng giải quyết vấn đề.

Ví dụ, chúng tôi có một yêu cầu để quản lý hàng ngàn đối tượng. Thỉnh thoảng chúng ta cần cập nhật dấu thời gian của đối tượng theo ID của nó. Thỉnh thoảng chúng tôi cần xóa các đối tượng không được cập nhật trong hơn X phút.

Nếu bạn biết cấu trúc dữ liệu của mình, bạn có thể dễ dàng xác định vấn đề và cũng rất dễ dàng đưa ra giải pháp. Khi một lập trình viên không biết đủ cấu trúc dữ liệu đã cố gắng đưa ra giải pháp, giải pháp của anh ta rất khó xử. Anh ấy giống như bạn - thông minh, lập trình viên mã, có thể học các khung nhanh chóng. Nhưng không có kiến ​​thức về cấu trúc dữ liệu, anh phải tự mình phát minh ra bánh xe. Hơn thế nữa - anh ta đã khó hiểu được các giải pháp đơn giản hơn vì chúng dựa trên các cấu trúc dữ liệu mà anh ta không hiểu như cây đỏ đen (TreeMap cũ của bạn trong Java).

Vì vậy, tôi muốn nói rằng điều quan trọng là phải biết cách và thời điểm sử dụng từng cấu trúc dữ liệu mà không phải suy nghĩ về nó. Nhưng tôi không nghĩ có bất kỳ cách nào để đạt được điều đó mà không thực sự hiểu cách họ làm việc.

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.