Không có công thức nào về cách bạn nên trả lời các câu hỏi phỏng vấn về mã hóa khoa học dữ liệu. Không có một phương pháp nào luôn hoạt động. Tuy nhiên, có một số nguyên tắc hướng dẫn, trong hầu hết các trường hợp, sẽ giúp bạn trả lời các câu hỏi mã hóa tốt hơn.
Những hướng dẫn này được hình thành dựa trên kinh nghiệm đi phỏng vấn và trả lời các câu hỏi viết mã. Chúng tôi chia các nguyên tắc này thành bốn phần. Bạn có thể sử dụng các nguyên tắc này như một danh sách kiểm tra, đặc biệt nếu bạn không có kinh nghiệm với câu hỏi phỏng vấn khoa học dữ liệu mã hóa. Tất nhiên sau này, bạn sẽ có thể tìm ra cách tiếp cận của riêng mình, có thể bỏ qua một số điểm hoặc thậm chí bao gồm một số điểm phù hợp với bạn hơn.
Nhưng bất kể kinh nghiệm của bạn là gì, nếu bạn làm theo danh sách kiểm tra này, bạn đang tăng cơ hội đưa ra câu trả lời tuyệt vời cho một câu hỏi mã hóa.
Danh sách kiểm tra bốn phần
Bốn phần của danh sách kiểm tra này là:
- Phân tích câu hỏi
- Phương pháp tiếp cận giải pháp
- Viết mã
- Xem lại mã của bạn
Bây giờ bạn đã có phác thảo danh sách kiểm tra, chúng tôi sẽ xem xét từng phần và giải thích các điểm trong danh sách kiểm tra mà nó có.
1. Phân tích câu hỏi
Phần Phân tích Câu hỏi của danh sách kiểm tra đề cập đến việc dành vài phút và suy nghĩ thấu đáo về câu hỏi bạn vừa nhận được. Giống như bạn sẽ thấy khi giải quyết các vấn đề kinh doanh thực sự, tốt hơn hết là bạn nên nghĩ về vấn đề trước tiên và “dành” một chút thời gian để nhìn nhận nó từ mọi khía cạnh. Hãy nhớ rằng, suy nghĩ không bao giờ là lãng phí thời gian!
Vài phút này sẽ được đền đáp sau đó. Nếu bạn ngay lập tức chuyển sang viết giải pháp, khả năng cao là bạn sẽ phải bắt đầu lại từ đầu sau khi nhận ra cách tiếp cận của mình không dẫn đến giải pháp mong muốn. Hoặc bạn liên tục phải thay đổi và viết lại mã của mình.
Những điểm sẽ giúp bạn rèn luyện tư duy về vấn đề là:
- Hiểu câu hỏi
- Phân tích các bảng và dữ liệu bạn đang làm việc
- Suy nghĩ về kết quả mã
tôi. Hiểu câu hỏi
Để đảm bảo bạn hiểu câu hỏi, bạn sẽ phải đọc câu hỏi rất cẩn thận. Đọc nó từ từ. Và hãy đọc nó 2-3 lần để đảm bảo rằng bạn không bỏ sót điều gì. Điều này áp dụng cho tất cả câu hỏi phỏng vấn khoa học dữ liệu, không cần biết chúng dễ dàng hay khó khăn. Vấn đề là, bạn sẽ không biết câu hỏi bạn nhận được là khó hay dễ. Một số câu hỏi có thể trông đơn giản một cách dễ hiểu, nhưng chúng có một số điểm chính xác để loại bỏ những ứng viên không đủ kỹ lưỡng và có xu hướng hời hợt.
Nếu câu hỏi không được viết, bạn cũng có thể yêu cầu người phỏng vấn nhắc lại nếu bạn không nắm bắt được điều gì đó. Trong trường hợp này, một khi bạn hiểu câu hỏi, bạn nên lặp lại câu hỏi với người phỏng vấn. Bằng cách đó, bạn sẽ đảm bảo rằng mình đã làm đúng mọi việc và cho phép người phỏng vấn tự sửa trong trường hợp họ không cung cấp cho bạn tất cả thông tin cần thiết.
ii. Phân tích các bảng và dữ liệu bạn đang làm việc
Khi bạn hiểu câu hỏi, bước hợp lý tiếp theo là phân tích các bảng bạn đã đưa ra. Điều này có nghĩa là bạn cần phân tích xem có bao nhiêu bảng và chúng được kết nối với nhau như thế nào (khóa ngoại và khóa chính).
Bạn cũng sẽ muốn xem dữ liệu nào trong các bảng này. Có nghĩa là có những cột nào trong mỗi bảng. Loại dữ liệu nào trong mỗi cột. Điều này rất quan trọng vì mã của bạn sẽ phụ thuộc vào việc bạn đang xử lý dữ liệu chuỗi, số nguyên, tiền hay bất kỳ loại dữ liệu nào khác. Có thể bạn thậm chí sẽ cần chuyển đổi kiểu dữ liệu này sang kiểu dữ liệu khác để có được kết quả mong muốn.
Bên cạnh kiểu dữ liệu, điều quan trọng là phải hiểu cách dữ liệu được tổ chức, sắp xếp và chi tiết hóa. Có nghĩa là, có các giá trị trùng lặp trong bảng không? Dữ liệu có được trình bày về cấp độ khách hàng, cấp độ giao dịch, v.v. không?
iii. Nghĩ về kết quả mã
Trước khi bắt đầu viết mã, bạn nên biết bạn muốn kết quả của mình trông như thế nào. Điều này, tất nhiên, cũng phụ thuộc vào câu hỏi bạn muốn trả lời.
Nhưng suy nghĩ về kết quả có nghĩa là văn học, nó sẽ chỉ là một giá trị trong một dòng hoặc một bảng có nhiều cột. Nếu đó là một bảng, bạn phải nghĩ lại cách dữ liệu của mình sẽ được tổng hợp và sắp xếp, bạn phải hiển thị bao nhiêu cột, v.v.
Phân tích câu hỏi - Ví dụ
Để chỉ cho bạn cách áp dụng phần đầu tiên này của danh sách kiểm tra, chúng tôi sẽ sử dụng câu hỏi mã hóa Dropbox. Câu hỏi như sau:
“Viết một truy vấn tính toán sự khác biệt giữa mức lương cao nhất được tìm thấy trong bộ phận tiếp thị và kỹ thuật. Đầu ra chỉ là sự khác biệt về tiền lương. ”
Liên kết đến câu hỏi: https://platform.stratascratch.com/coding/10308-salaries-differences
Nếu bạn đọc kỹ câu hỏi, bạn sẽ nhận ra rằng bạn phải tìm được mức lương cao nhất. Được, nhưng không phải là mức lương cao nhất trong mọi bộ phận mà chỉ ở hai bộ phận: tiếp thị và kỹ thuật. Một khi bạn tìm thấy mức lương cao nhất trong hai bộ phận này, bạn cần phải tính toán sự khác biệt giữa chúng.
Bây giờ bạn đã hiểu câu hỏi, bạn có thể phân tích các bảng và dữ liệu trong đó. Các bảng bạn sẽ làm việc với là db_employee và db_dept. Bảng db_employee chứa dữ liệu về nhân viên của công ty. Nó có năm cột:
| id | int |
| họ | vecni |
| last_name | vecni |
| tiền lương | int |
| Department_id | int |
Bạn thấy đấy, các cột tên là kiểu dữ liệu varchar, trong khi tiền lương là một số nguyên. Điều quan trọng cần biết là không có số thập phân trong các giá trị tiền lương. Nếu bạn sử dụng tùy chọn xem trước có sẵn ở đây, bạn sẽ thấy dữ liệu này là duy nhất: mỗi nhân viên chỉ có một giá trị tiền lương được phân bổ cho họ. Ngoài ra, một điều quan trọng cần biết; nó cũng có thể là dữ liệu lịch sử nơi bạn sẽ có tất cả các mức lương trước đó trong nhiều năm cho mọi nhân viên. Có một cột Department_id, là một khóa ngoại liên kết bảng này với bảng db_dept:
| id | int |
| bộ | vecni |
Chỉ có hai cột trong bảng này. Đó chỉ là danh sách các phòng ban, không có bản sao, với sáu phòng ban được hiển thị trong bảng.
Tốt, bạn đã phân tích dữ liệu. Bây giờ, quay lại câu hỏi và đọc câu thứ hai. Có, đây là hướng dẫn về những gì giải pháp của bạn cần. Bạn không cần phải hiển thị mức lương cao nhất từ một bộ phận trong một cột, sau đó là mức lương cao nhất từ bộ phận khác trong cột thứ hai và sau đó là sự khác biệt giữa chúng trong cột thứ ba. Không, đầu ra sẽ chỉ là sự khác biệt:
Không có hướng dẫn về cột đầu ra này nên được đặt tên là gì. Vì vậy, sẽ không có gì nhầm lẫn nếu bạn đặt tên cho nó hoặc nếu bạn không đặt tên cho nó. Điều quan trọng là bạn nhận được kết quả này chứ không gì khác.
Với điều đó, bạn có cơ sở để viết một mã chất lượng. Bây giờ là lúc về chiến lược: bạn sẽ viết mã như thế nào?
2. Phương pháp tiếp cận giải pháp
Trước khi bạn bắt đầu viết mã, điều quan trọng là bạn phải có ý tưởng rõ ràng về mã của bạn sẽ trông như thế nào. Việc viết mã chỉ nên dịch ý tưởng (rõ ràng!) Của bạn về giải pháp sang ngôn ngữ lập trình.
Khi bạn nghĩ về cách bạn nên tiếp cận giải pháp của mình (hoặc viết mã), hãy xem xét những điều sau:
- Có mấy cách viết mã?
- Nêu các giả định của bạn
- Chia nhỏ giải pháp của bạn thành các bước
- Bắt đầu viết mã
tôi. Có một số cách để viết mã?
Khi nghĩ về giải pháp, điều đầu tiên nghĩ đến đôi khi lại là giải pháp tốt nhất. Và đôi khi nó không phải là. Làm thế nào bạn có thể biết? Khi bạn có ý tưởng đầu tiên, mẹo là hãy nghĩ xem có cách nào khác để giải quyết vấn đề hay không. Trong ngôn ngữ lập trình, nhiều hơn không, có một số giải pháp khả thi.
Hãy ghi nhớ điều này. Có một số lý do khiến điều này quan trọng. Đầu tiên, có thể có một số thủ thuật hoặc chức năng đơn giản có thể dễ dàng giải quyết điều gì đó mà bạn nghĩ đến việc giải quyết bằng một đoạn mã dài — ví dụ: sử dụng chức năng cửa sổ hoặc CTE thay vì viết mã với vô số truy vấn con.
Luôn chọn những gì dễ viết hơn, với càng ít dòng mã càng tốt. Khi đến phỏng vấn, bạn cũng phải quản lý thời gian theo ý mình. Đây là một trong những cách.
Tất nhiên, nếu có một số giải pháp phức tạp hơn hoặc ít hơn như nhau, hãy nghĩ về cách mã sẽ hoạt động. Trên một lượng lớn dữ liệu, các mã khác nhau có thể chiếm nhiều thời gian và bộ nhớ để thực hiện hơn các mã khác.
Tóm lại, bạn nên nghĩ về hiệu quả của mã theo hai cách. Một là hiệu quả cá nhân, hoặc tốc độ bạn có thể viết mã. Điều thứ hai là hiệu quả của mã hoặc tốc độ mã sẽ thực hiện những gì bạn muốn.
ii. Nêu các giả định của bạn
Nêu ra các giả định của bạn là quan trọng vì một số lý do. Đầu tiên là nói to và viết chúng ra, điều này sẽ giúp bạn thấy được những vấn đề tiềm ẩn trong cách tiếp cận của mình.
Lý do quan trọng thứ hai là nó mời người phỏng vấn của bạn giao tiếp với bạn và thậm chí đưa ra một số trợ giúp, điều mà họ thường làm. Nếu họ không biết bạn muốn làm gì và tại sao, họ không thể giúp bạn. Như chúng tôi đã đề cập, thường có một số giải pháp trả về cùng một kết quả. Truyền đạt các giả định của bạn cho phép người phỏng vấn hướng bạn đi đúng hướng dựa trên cách tiếp cận bạn đã chọn. Hoặc thậm chí hướng bạn khỏi những giả định hoàn toàn sai lầm sẽ làm rối tung giải pháp của bạn.
Lý do thứ ba là, đôi khi câu hỏi có thể được cố ý thiết lập để trở nên mơ hồ. Những câu hỏi này không liên quan đến giải pháp phù hợp mà là cách bạn suy nghĩ. Vì vậy, nếu bạn nêu các giả định của mình, nó sẽ cho người phỏng vấn thấy bạn nghĩ như thế nào, điều mà họ thường rất quan tâm.
Lý do thứ tư và cũng là lý do cuối cùng để nêu các giả định của bạn là ngay cả khi bạn nhận được câu trả lời sai hoàn toàn nhưng đúng với các giả định bạn đã nêu, rất có thể bạn sẽ vẫn nhận được một số điểm cho điều đó. Suy nghĩ, trong trường hợp này, xoay quanh những dòng này: OK, có thể ứng viên hoàn toàn hiểu sai những gì được hỏi, nhưng giải pháp thực sự đúng trong bối cảnh những gì họ đã hiểu.
Tất cả điều này dẫn đến đảm bảo đưa ra câu trả lời đúng cho một câu hỏi phỏng vấn.
iii. Chia nhỏ giải pháp của bạn thành các bước
Đây cũng là một điểm hữu ích giúp bạn dễ dàng có ý tưởng giải pháp rõ ràng và sau này viết mã sạch.
Chia nhỏ, trong trường hợp này, có nghĩa là viết ra. Có, hãy viết ra tất cả các bước và chức năng chính của giải pháp của bạn. Hãy nghĩ xem bạn có nên tham gia các bảng hay không, có bao nhiêu bảng và kết hợp nào bạn sẽ sử dụng. Bạn nên viết một truy vấn con hay một CTE? Viết ra sự lựa chọn của bạn. Hãy nghĩ về những hàm tổng hợp nào bạn sẽ phải sử dụng, liệu bạn sẽ phải chuyển đổi các kiểu dữ liệu, dữ liệu có được sắp xếp theo một cách cụ thể hay không, dữ liệu có được lọc và nhóm lại hay không, v.v.
Tất cả đều là các bước riêng biệt, vì vậy hãy viết chúng ra, cũng như các từ khóa chính bạn sẽ sử dụng trong mỗi bước.
iv. Bắt đầu mã hóa
Đây là một điểm khẩn cấp, theo một cách nào đó. Nếu bạn đã nghĩ về cách tiếp cận giải pháp của mình, nhưng bạn chỉ đơn giản là không thể nhìn thấy giải pháp hoàn chỉnh trước mắt mình, thì bạn chỉ cần bắt đầu viết mã.
Suy nghĩ đằng sau điều này là ngay cả khi bạn đưa ra một giải pháp không hoàn chỉnh, nó chắc chắn có giá trị hơn là không viết một dòng mã nào. Ngoài ra, một số câu hỏi có thể thực sự khó và ngay cả đối với những người có kinh nghiệm nhất cũng khó có thể nhìn ra toàn bộ giải pháp ngay lập tức. Bắt đầu viết mã và có khả năng bạn sẽ nảy ra ý tưởng trong quá trình thực hiện. Và nếu không, một lần nữa, ít nhất bạn cũng có thứ gì đó để thể hiện.
Một lý do bổ sung mà bạn nên ghi nhớ: một số câu hỏi thậm chí không có ý định trả lời. Một số trong số chúng chỉ đơn giản là (và cố ý!) Quá khó để giải quyết trong thời gian bạn được đưa ra tại cuộc phỏng vấn. Không ai giải quyết chúng hoàn toàn. Giải pháp từng phần là giải pháp tốt nhất mà bất kỳ ai cũng sẽ nhận được. Vì vậy, bạn sẽ được đánh dấu về mức độ bạn đã đạt được so với các giải pháp chưa hoàn thiện khác.
Phương pháp tiếp cận Giải pháp - Ví dụ
Bây giờ bạn đã biết bạn nên suy nghĩ như thế nào về cách tiếp cận giải pháp của mình, hãy sử dụng một câu hỏi phỏng vấn để chứng minh cách nó hoạt động trong thực tế. Chúng tôi sẽ sử dụng câu hỏi phỏng vấn mã hóa Amazon:
“Tìm tổng chi phí đơn đặt hàng của mỗi khách hàng. Nhập id của khách hàng, tên và tổng chi phí đặt hàng. Sắp xếp hồ sơ theo tên của khách hàng theo thứ tự bảng chữ cái. ”
Liên kết đến câu hỏi: https://platform.stratascratch.com/coding/10183-total-cost-of-orders
Chúng tôi sẽ phải sử dụng dữ liệu từ hai bảng, khách hàng trên bàn và đơn đặt hàng trên bàn với câu hỏi này. Chúng ta có thể viết mã với các truy vấn con để khắc phục vấn đề này. Tuy nhiên, bạn có thể biết rằng nếu truy vấn và truy vấn con đang sử dụng dữ liệu từ nhiều bảng, thì giải pháp cũng có thể được viết bằng cách sử dụng JOIN. Hãy ghi nhớ lời khuyên là viết càng ít dòng mã càng tốt, tốt hơn là sử dụng JOIN.
Các giả định cho giải pháp này là gì? Một giả định có thể là có thể có những khách hàng không có đơn đặt hàng nào. Điều này có nghĩa là có thể có khách hàng trong bảng mà khách hàng sẽ không hiển thị trong đơn đặt hàng trong bảng. Giả định thứ hai là chúng tôi sẽ không hiển thị cho khách hàng không có đơn đặt hàng nào vì câu hỏi không nói rõ điều đó.
Bây giờ, điều này đã dẫn chúng ta đến một sự cố giải pháp. Chúng tôi phải xuất ra hai cột đã có, vì vậy chắc chắn chúng tôi sẽ sử dụng SELECT. Chúng tôi cần tìm tổng số đơn đặt hàng của mỗi khách hàng. Chúng ta sẽ phải tính tổng nó bằng cách sử dụng hàm tổng hợp SUM (). OK, các bảng phải được tham gia. Chúng tôi sẽ làm điều đó bằng cách sử dụng từ khóa JOIN. Tại sao không tham gia một số khác? Bởi vì giả định của chúng tôi nói rằng, chúng tôi chỉ muốn những khách hàng có ít nhất một đơn đặt hàng. Sử dụng JOIN sẽ cung cấp cho chúng ta chính xác điều đó: nó sẽ nối hai bảng và chỉ tìm các giá trị (khách hàng) có trong cả hai bảng. Tiếp theo là gì? Tôi đã sử dụng hàm tổng hợp, vì vậy tôi sẽ phải sử dụng GROUP BY. Và kết quả phải được sắp xếp theo thứ tự bảng chữ cái, vì vậy tôi sẽ sử dụng ORDER BY và ASC.
Sự cố giải pháp kết quả sau đó có thể trông như thế này:
- CHỌN
- TỔNG (tổng_đơn_hàng_chi phí)
- THAM GIA
- NHÓM THEO
- ĐẶT HÀNG BẰNG ASC
Trong trường hợp của bạn, đây không phải là trường hợp khẩn cấp vì bạn đã hiểu mọi thứ, vì vậy bạn có thể chuyển sang phần danh sách kiểm tra tiếp theo. Hoặc bạn cũng có thể tìm thấy điểm chung nhất Câu hỏi phỏng vấn SQL JOIN tại đây.
3. Viết mã
Sau khi đánh giá câu hỏi và đưa ra chiến lược cho mã của bạn, đã đến lúc bạn bắt đầu viết nó.
- Bám sát vào một phương ngữ đã chọn
- Đi từng dòng khi viết mã
- Nói chuyện khi bạn viết mã
- Làm cho nó có thể đọc được
- Hãy nhất quán với các quy ước đã chọn
tôi. Bám sát vào một phương ngữ đã chọn
Điều này đặc biệt quan trọng nếu bạn đang trong cuộc phỏng vấn viết mã SQL. Như bạn đã biết, có một tiêu chuẩn ANSI / ISO SQL và có nhiều phương ngữ SQL. Hầu như mọi RDBMS đều sử dụng phương ngữ SQL của riêng nó. Tất nhiên, bạn không thể biết tất cả chúng. Và công ty bạn đang phỏng vấn có thể đang sử dụng một trong những phương ngữ đó.
Nếu người phỏng vấn không quan tâm bạn sử dụng phương ngữ nào, hãy chọn phương ngữ mà bạn cảm thấy thoải mái nhất. Đừng cố thu hút người phỏng vấn bằng cách chọn phương ngữ SQL mà họ sử dụng nếu bạn không giỏi viết phương ngữ đó. Tốt hơn là chọn phương ngữ bạn biết rõ nhất và giải quyết vấn đề hơn là sử dụng một số phương ngữ khác mà bạn không cảm thấy chắc chắn. Nếu bạn chọn cái sau, rất có thể bạn sẽ lo lắng hơn mức cần thiết. Ngoài ra, việc không quen thuộc với phương ngữ SQL cụ thể có thể khiến bạn gặp khó khăn trong giải pháp.
Sau khi bạn chọn phương ngữ SQL, hãy tuân theo nó. Ví dụ: nếu bạn chọn viết bằng PostgreSQL, đừng trộn nó với T-SQL.
ii. Đi từng dòng
Có một bản phân tích giải pháp rõ ràng sẽ giúp bạn kiểm tra điểm gần như không được chú ý này. Khi bạn đã phác thảo các chức năng và phần mã của mình, bạn chỉ cần giữ bình tĩnh và viết mã một cách có hệ thống theo đề cương giải pháp. Code không khác gì một phiên bản ngôn ngữ lập trình của suy nghĩ của bạn. Nếu suy nghĩ của bạn và phác thảo giải pháp của bạn rõ ràng, mã của bạn cũng sẽ như vậy.
Nếu bạn bắt đầu nhảy từ dòng này sang dòng khác, bạn sẽ khiến chính mình và người phỏng vấn bối rối. Điều này có thể dẫn đến việc không viết đúng mã.
iii. Nói như bạn viết mã
Khi bạn viết từng dòng mã của mình, bạn cũng nên nói về những gì bạn đang làm. Điều này rất quan trọng vì khi nói to những gì bạn đang làm, bạn sẽ dễ dàng nhận ra mình có đang làm sai điều gì không. Mọi thứ có thể nghe tuyệt vời trong đầu bạn. Nhưng khi bạn nói ra, những ý tưởng không mấy hay ho sẽ thực sự xuất hiện! Điều này mang lại cho bạn cơ hội để sửa mã khi bạn tiếp tục. Nếu không, bạn có thể hoàn thành mã của mình, thậm chí không nhận ra mình đã làm sai điều gì đó.
Một trong những lý do tại sao điều quan trọng là phải giải thích từng dòng khi bạn viết nó là nó một lần nữa mời người phỏng vấn tham gia vào giải pháp của bạn. Nó giúp họ có thể hiểu những gì bạn đang làm và cung cấp cho bạn một số gợi ý. Nếu bạn chỉ viết mã và giữ cho mình những gì bạn đang làm, người phỏng vấn có thể sẽ đóng cửa và chỉ cần đợi bạn hoàn thành mã để cho bạn biết bạn đã làm như thế nào.
iv. Làm cho nó có thể đọc được
Có một mã có cấu trúc tốt là một niềm vui khi nhìn đơn giản từ quan điểm thẩm mỹ. Không chỉ vậy, nó còn giúp bạn và người phỏng vấn đọc mã của bạn dễ dàng hơn.
Điều chính làm cho mã của bạn có thể đọc được được đề cập ở một trong những điểm ở trên: viết nó càng đơn giản càng tốt. Tuy nhiên, một số giải pháp không thể đơn giản. Và thậm chí một vài dòng mã có thể là một cơn ác mộng để đọc nếu bạn không cố gắng làm cho nó có thể đọc được.
Một trong những mẹo cần ghi nhớ là sử dụng dấu cách, tab và enter. Và sử dụng nó rất nhiều! Các khóa này ở đó để tách mã của bạn thành các phần, giúp bạn dễ hiểu hơn về chức năng của mã. Hãy nghĩ về nó giống như bất cứ điều gì bạn nói hoặc viết. Dấu cách, tab và enter sẽ làm cho mã của bạn có dấu phẩy, câu và đoạn văn.
Nếu có thể, hãy sử dụng bí danh cho các bảng. Nhưng hãy cố gắng làm cho chúng tự giải thích. Tránh sử dụng các bí danh gồm một chữ cái, nhưng cũng đừng đặt bí danh quá dài dòng và mang tính mô tả. Tương tự đối với các tên biến.
Mặc dù SQL không phân biệt chữ hoa chữ thường, nhưng tốt hơn hết bạn nên viết các từ khóa SQL ở dạng chữ hoa. Điều này cũng sẽ làm cho chúng dính trong mã, đặc biệt nếu tất cả các tên cột và bảng đều được viết chữ thường.
Kiểm tra bài đăng của chúng tôi “Các phương pháp hay nhất để viết truy vấn SQL: Cách cấu trúc mã của bạn”Tập trung vào cách các truy vấn SQL của bạn có thể được cải thiện, đặc biệt là khi nói đến hiệu suất và khả năng đọc.
v. Hãy nhất quán với các quy ước đã chọn
Không có quy tắc nào bắt bạn phải viết hoa hoặc viết thường; không có quy ước đặt tên theo quy định, vì vậy nó tùy thuộc vào bạn và cách bạn thích nó. Nhưng dù bạn làm gì, hãy kiên định với nó.
Nếu bạn muốn viết tất cả các tên cột mới bằng chữ thường và phân tách các từ bằng dấu gạch dưới, vui lòng làm như vậy và giữ nguyên như vậy. Đặt tên cho một cột Luong_per_employee trông khá ổn. Nhưng hãy cố gắng tránh đặt tên cho một cột là Luong_per_employee, cột còn lại là SalaryPerDepartment, cột thứ ba là 'Total Salary' và cột thứ tư MAX_sALAryPerdeparment. Bạn sẽ tự làm tổn thương mình khi cố gắng đọc mã, đặc biệt là với mã cuối cùng.
Điều tương tự cũng xảy ra khi viết tên bảng, sử dụng bí danh, v.v. Giữ tính nhất quán cũng sẽ tăng thêm khả năng đọc mã của bạn.
Nói về tính nhất quán, chúng tôi sẽ chỉ cho bạn cách hoạt động của phần danh sách kiểm tra này trong thực tế.
Viết mã - Ví dụ
Đây là một câu hỏi mã hóa của Facebook:
“Facebook gửi tin nhắn SMS khi người dùng cố gắng 2FA (xác thực 2 yếu tố) vào nền tảng để đăng nhập. Để đăng nhập thành công 2FA, họ phải xác nhận rằng họ đã nhận được tin nhắn văn bản SMS. Văn bản xác nhận chỉ có giá trị vào ngày chúng được gửi đi. Rất tiếc, đã xảy ra sự cố ETL với cơ sở dữ liệu nơi các yêu cầu kết bạn và bản ghi xác nhận không hợp lệ được chèn vào nhật ký, được lưu trữ trong bảng 'fb_sms_sends'. Các loại thông báo này không nên có trong bảng. May mắn thay, bảng 'fb_confirmers' chứa các bản ghi xác nhận hợp lệ nên bạn có thể sử dụng bảng này để xác định các tin nhắn văn bản SMS đã được người dùng xác nhận.
Tính phần trăm tin nhắn SMS được xác nhận cho ngày 4 tháng 2020 năm XNUMX ”
Liên kết đến câu hỏi: https://platform.stratascratch.com/coding/10291-sms-confirmations-from-users
Nếu bạn viết mã như thế này, nó sẽ bao gồm mọi thứ mà chúng tôi đã đề cập trong phần danh sách kiểm tra này:
SELECT cust_id, SUM(total_order_cost) AS revenue
FROM orders
WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id
ORDER BY revenue DESCHãy tưởng tượng Facebook sử dụng SQL Server, nhưng nó để lại cho bạn phương ngữ SQL nào bạn sẽ viết mã của mình. Bạn không quen thuộc với T-SQL, vì vậy bạn quyết định viết bằng PostgreSQL.
Ví dụ, EXTRACT () và dấu hai chấm (: :) là các hàm tiêu biểu cho PostgreSQL. Cái đầu tiên trích xuất một phần của ngày từ kiểu dữ liệu datetime. Nó không tồn tại trong T-SQL! Vì vậy, nếu bạn nói với người phỏng vấn rằng bạn đang viết bằng T-SQL và sau đó sử dụng chức năng này, bạn đã mắc sai lầm. Trong T-SQL, bạn nên sử dụng hàm DATEPART (). Và bạn nên biết rằng hàm này trong PostgreSQL được gọi là DATE_PART (). Một dấu gạch dưới có thể có nghĩa là sự khác biệt giữa mã của bạn hoạt động và không hoạt động.
Tương tự, dấu hai chấm (: :) trong PostgreSQL được sử dụng để chuyển đổi kiểu dữ liệu. Trong T-SQL, nó không hoạt động; bạn sẽ phải sử dụng CAST () hoặc CONVERT ().
Có một bản phân tích giải pháp cho đoạn mã này sẽ giúp bạn dễ dàng viết nó từng dòng một. Nó thực sự dễ dàng. Đầu tiên, bạn phải chọn một số dữ liệu từ một bảng, lọc nó, nhóm nó và cuối cùng là sắp xếp nó. Trước tiên, đừng viết mệnh đề WHERE, sau đó chuyển đến câu lệnh SELECT, sau đó chuyển đổi kiểu dữ liệu hoặc bất kỳ cách kỳ lạ nào khác để tiếp cận mã của bạn.
Khi viết mã, bạn có thể nói chuyện với người phỏng vấn như sau: Tôi đang chọn cột cust_id bằng cách sử dụng hàm SUM () để tính toán doanh thu từ các đơn đặt hàng trên bàn. Sau đó, tôi đang sử dụng mệnh đề WHERE để lọc dữ liệu dựa trên tháng và năm từ cột order_date. Sau đó, tôi đang nhóm dữ liệu ở cấp độ khách hàng và sắp xếp kết quả theo thứ tự giảm dần.
Bạn thấy rằng mã này có thụt lề, có một dòng mới cho mọi phần chính của mã và các quy ước đặt tên là nhất quán. Bạn có muốn xem mã có thể trông như thế nào nếu chúng tôi không làm theo điều này? Nó đây:
CHỌN cust_id, SUM (total_order_cost) NHƯ DOANH THU TỪ ĐƠN HÀNG TRONG ĐÓ CHIẾT XUẤT ('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT ('YEAR' FROM order_date :: TIMESTAMP) = 2019 NHÓM THEO đơn hàng cust_id THEO Doanh thu DESC
Chúc may mắn khi đọc nó!
4. Xem lại mã của bạn
Sau khi bạn đã viết mã, đã đến lúc bạn xem lại nó trước khi nó trở thành câu trả lời cuối cùng của bạn. Nếu bạn đã theo dõi tất cả các mục trong danh sách kiểm tra cho đến nay, bạn sẽ dễ dàng xem lại nó.
Theo một cách nào đó, việc xem lại mã của bạn là kiểm tra nó so với một số điểm trong danh sách kiểm tra của bạn:
- Kiểm tra xem bạn còn lại bao nhiêu thời gian
- Kiểm tra nó với đầu ra được yêu cầu
- Kiểm tra nó với các giả định đã nêu
- Kiểm tra khả năng đọc của nó
- Dẫn dắt người phỏng vấn thông qua giải pháp
- Tối ưu hóa mã của bạn
tôi. Kiểm tra xem bạn còn lại bao nhiêu thời gian
Tất cả các điểm khác trong phần này của danh sách kiểm tra phụ thuộc vào điểm này. Nếu bạn không còn thời gian, thì bạn không thể làm gì cả. Bạn đã làm những gì bạn đã làm và mã của bạn là câu trả lời bạn có, dù muốn hay không.
Quản lý thời gian rất quan trọng, vì vậy bạn nên cố ý dành một chút thời gian để xem lại mã. Tốt nhất, bạn sẽ có thời gian để thực hiện ba bước kiểm tra sau.
ii. Kiểm tra mã so với đầu ra được yêu cầu
Bạn nên quay lại câu hỏi của mình và xem liệu mã của bạn có thực sự trả về những gì được yêu cầu hay không. Bạn đã quên bao gồm một số cột bắt buộc? Bạn đã thực sự đặt hàng kết quả như nó được yêu cầu? Bạn nên tự hỏi những câu hỏi đó và những câu hỏi tương tự khác.
Nếu bạn có thời gian, hãy sửa chữa những sai lầm bạn đã mắc phải. Nếu không có thời gian, hãy để nguyên mã, nhưng hãy ghi lại những gì bạn đã làm sai.
iii. Kiểm tra mã so với các giả định đã nêu
Bạn đã viết mã của mình dựa trên một số giả định. Quay lại danh sách các giả định của bạn và kiểm tra xem bạn có theo dõi chúng hay không.
Nó sẽ là hoàn hảo nếu bạn đã làm. Nhưng khi viết mã phức tạp hơn, có thể bạn đã loại bỏ một số giả định hoặc đưa ra những giả định mới. Viết nó ra, quá. Nếu bạn không tuân theo tất cả các giả định, nhưng bạn nghĩ rằng bạn nên có và bạn có thời gian để thay đổi mã, hãy làm điều đó. Nếu không, hãy để nguyên như vậy.
iv. Kiểm tra khả năng đọc mã
Ở đây bạn nên kiểm tra xem bạn có hiểu những gì bạn vừa viết hay không. Quay lại mã của bạn, kiểm tra một lần nữa mọi dòng để biết cú pháp và logic của nó. Khi bạn đi từng dòng, hãy đánh giá xem liệu khả năng đọc mã có thể được cải thiện hay không. Bạn có nhất quán trong các quy ước đặt tên không? Bí danh của bạn có rõ ràng để hiểu không? Có bất kỳ sự mơ hồ nào không? Mã có được cấu trúc theo cách hợp lý và thành các phần hợp lý không?
Một lần nữa, nếu bạn có thời gian, hãy cải thiện khả năng đọc mã. Nếu không có thời gian, hãy thử viết ra hoặc đơn giản là ghi nhớ những gì bạn có thể đã làm tốt hơn.
v. Dẫn dắt Người phỏng vấn thông qua Giải pháp
Nếu bạn đã làm tất cả các bước trên, bước này sẽ đến với bạn một cách tự nhiên. Điều quan trọng nhất là bạn trung thực khi giải thích mã của mình.
Bất kỳ lỗi nào bạn phát hiện thấy trong mã của mình khi xem lại, hãy nêu chúng một cách rõ ràng. Đừng tin tưởng vào việc người phỏng vấn của bạn không chú ý đến họ. Đừng cố che giấu chúng. Hãy sở hữu những sai lầm của bạn và thể hiện rằng bạn biết mình đã làm gì sai. Mọi người đều mắc sai lầm, nhưng không phải ai cũng có thể nhận ra mình đã mắc sai lầm và thừa nhận chúng. Nó cho thấy bạn biết mình đang làm gì mặc dù bạn đã mắc sai lầm. Nói về những sai lầm, đây là những điều phổ biến nhất mà mọi người thực hiện trong các cuộc phỏng vấn khoa học dữ liệu.
Nếu bạn đã đưa một cột không cần thiết vào đầu ra của mình, hãy nói như vậy và tiếp tục giải thích đầu ra bạn có. Bạn đã đi lạc khỏi những giả định ban đầu của mình hay bao gồm những giả định mới? Nói như vậy và giải thích tại sao. Nếu bạn làm điều đó do nhầm lẫn, hãy nói rằng đó không phải là cố ý, nhưng bạn thấy rằng giải pháp của bạn nên bao gồm một số giả định bổ sung. Nêu chúng phải là gì để mã của bạn hoạt động. Điều tương tự cũng xảy ra với khả năng đọc: nếu bạn thấy bạn có thể làm cho mã của mình tốt hơn, hãy giải thích cách làm.
Bằng cách làm tất cả những điều này, bạn sẽ không chỉ thể hiện khả năng viết mã của mình mà còn thể hiện khả năng suy nghĩ nhanh như thế nào, rằng bạn có trách nhiệm và trung thực. Đây đều là những đặc điểm được tất cả các công ty rất coi trọng.
vi. Tối ưu hóa mã của bạn
Câu hỏi cuối cùng trong cuộc phỏng vấn viết mã thường là câu hỏi yêu cầu bạn tối ưu hóa mã của mình. Bằng cách đó, người phỏng vấn sẽ kiểm tra kiến thức lý thuyết SQL của bạn. Ví dụ, nếu bạn biết rằng JOIN có thể tốn nhiều thời gian về mặt tính toán? Bạn sẽ được yêu cầu tìm hiểu xem có cách nào để loại bỏ JOIN hoặc một truy vấn con hay không. Ví dụ: bạn thường có thể xóa truy vấn con trong mệnh đề WHERE bằng một số hàm, chẳng hạn như hàm xếp hạng, nếu cố gắng tìm giá trị lớn nhất.
Hoặc nếu bạn biết các thao tác được thực hiện nhanh như thế nào trên một số kiểu dữ liệu nhất định. Ví dụ: so sánh chuỗi chậm hơn so với so sánh số nguyên, vì vậy có thể có một cách để làm điều đó trên dữ liệu chuỗi?
Kết luận
Tất cả những điều này tóm lại là: viết mã gần như phải là một kỹ thuật nếu bạn cấu trúc tốt cách tiếp cận của mình. Trọng tâm tập trung nhiều hơn vào suy nghĩ và ít tập trung vào mã hóa. Và việc viết mã nên được thực hiện một cách rất có tổ chức.
Bạn nên suy nghĩ kỹ câu hỏi, dữ liệu bạn có trước mắt, (các) giải pháp khả thi, giả định của bạn và các chức năng bạn sẽ cần. Chỉ sau đó, bạn nên bắt đầu viết mã. Khi bạn bắt đầu viết mã, bạn sẽ có thể bao gồm người phỏng vấn về những gì bạn đang làm và cho họ biết từng bước bạn thực hiện. Giống như trong cuộc sống thực, bạn sẽ phải kiểm tra và tối ưu hóa mã của mình trước khi bắt đầu sử dụng trong sản xuất. Cuộc phỏng vấn này là sản xuất của bạn; quản lý thời gian của bạn để bạn có thể xem xét giải pháp của mình.
Đây là những điều bạn nên làm. Ngoài ra còn có các mẹo chuẩn bị khác trong bài đăng của chúng tôi: 5 Mẹo để Chuẩn bị cho Cuộc phỏng vấn Khoa học Dữ liệu.
Tất cả điều này là không dễ dàng. Nó đòi hỏi kinh nghiệm và thực hành; không ai có thể giả mạo điều này. Nhưng làm theo danh sách kiểm tra này chắc chắn sẽ bổ sung một cấu trúc vững chắc cho tư duy và hiệu suất phỏng vấn của bạn, bất kể kinh nghiệm của bạn. Nó chỉ có thể làm cho bạn hoạt động tốt hơn.
Nate Rosidi là một nhà khoa học dữ liệu và trong chiến lược sản phẩm. Anh ấy cũng là một giáo sư trợ giảng dạy phân tích và là người sáng lập StrataScratch, một nền tảng giúp các nhà khoa học dữ liệu chuẩn bị cho cuộc phỏng vấn của họ với các câu hỏi phỏng vấn thực tế từ các công ty hàng đầu. Kết nối với anh ấy trên Twitter: StrataScratch or LinkedIn.
Nguyên. Đăng lại với sự cho phép.
Nguồn: https://www.kdnuggets.com/2022/01/answer-data-science-coding-interview-questions.html
