Đối với một người tự học lập trình, khó khăn lớn nhất chính là không biết bắt đầu từ đâu và bắt đầu như thế nào. Dạo một vòng các diễn đàn IT, bạn dễ dàng gặp các câu hỏi như: chọn ngôn ngữ gì, cách tiếp cận ra sao, nguồn tài nguyên nào đáng tin cậy nhất…
Mọi người thường search Google về vấn đề này. Và Google dẫn họ đến với một kho tài nguyên khổng lồ, muôn hình vạn trạng: sách, video, tutorial, blog post,… Theo tâm lý chung, mọi người sẽ thử một vài phương pháp và chọn ra cái phù hợp nhất với bản thân: một số người thích screenshot, có người lại muốn xem video, số khác thì tôn sùng các article thần thánh. Quá trình này có vẻ rất hợp logic phải không?
Không! Hoàn toàn không! Và hôm nay tôi sẽ cho bạn thấy, trong các dạng học liệu kia… sẽ chỉ có một, duy nhất một thứ giúp bạn đạt được kết quả nhanh nhất. Đó chính là...
Xây dựng Project
Đầu tiên, tôi muốn nhấn mạnh rằng, tập trung vào một nguồn học liệu cũng như một phương pháp học nào đó không có nghĩa là bỏ đi tất cả những thứ còn lại.
Screenshots, videos, tutorials đã, đang và sẽ tồn tại, ta vẫn cần đến chúng, chẳng hạn, khi xuất hiện một công nghệ mới hoặc một framework chào đời, cách hiệu quả nhất để nắm bắt nó, theo tôi, chính là đọc các bài báo hoặc hoàn thành một vài tutorials.
Vấn đề nằm mỗi cá nhân chúng ta. Mọi người luôn có thói quen bấu víu vào những thứ (cụ thể ở đây là các phương pháp và các nguồn học liệu) làm họ cảm thấy thoải mái (comfort zone). Nguy hiểm hơn nữa, thói quen này gây ra ảo giác, rằng nguồn tài nguyên và phương pháp học đó (cái mà đang làm chúng ta cảm thấy thoải mái) là sự lựa chọn hợp lý…. Con người chúng ta luôn khát khao cảm giác thoải mái và sung sướng – đó là một khiếm khuyết cần khắc phục.
Hãy tỉnh táo!
Làm project? Ý tưởng này có gì mới mẻ? Không, chả có gì mới…
Làm một sản phẩm nho nhỏ vừa tận dụng thời gian và kiến thức của chúng ta một cách hiệu quả vừa ta hoàn thành mục tiêu dài hạn. Nhưng tại sao bạn chưa bắt đầu? Vì SỨC Ì của bạn quá lớn!
Tôi đã nhắc đến khuyết điểm này trong bài viết trước. Bạn có thể xem ở đây.
Nếu như Neo trong The Matrix được chọn giữa viên thuốc đỏ và viên thuốc xanh thì ảo giác của chúng ta cũng mang đến hai sự lựa chọn tương ứng: ta có thể “nằm gọn” trong vùng an toàn như một con cừu hoặc thoát khỏi nó để ngộ ra rằng, nếu muốn phát triển ta cần thoát khỏi comfort zone càng sớm càng tốt!
Bạn hãy quyết định trước khi quá muộn. Và trong thời gian bạn suy nghĩ, tôi xin phép đưa ra một số gợi ý về cách tiếp cận các project.
Các Project sẽ mất khoảng 1 năm để hoàn thành
Quan điểm này được tôi đúc kết nhờ các buổi giao lưu với nhóm Free Code Camp Toronto cũng như việc dõi theo hành trình của các thành viên Free Code Camp trên khắp thế giới.
Tôi thấy có rất nhiều người đã kiếm được việc trước khi hoàn thành chứng chỉ Front End developer của Free Code Camp. Họ làm theo 2 bước:
- Hoàn thành một project
- Đi apply
Nghe có vẻ rất đơn giản, nhưng một thời gian ngắn sau đó, họ được gọi đi làm. Nếu bạn hay đọc phần subreddit tren Free Code Camp bạn sẽ thấy những câu chuyện như thế không phải là hiếm. Bạn cũng nên biết rằng thị trường việc làm ở các vùng miền khác nhau rất đa dạng, chẳng hạn, ở Toronto, hàng ngàn suất Front End Developer luôn sẵn sàng cho các ứng viên có năng lực.
Theo khuyến nghị của Free Code Camp, để trở thành một ứng viên khá, bạn nên hoàn thành đầy đủ chương trình 2080 giờ học.
2080 giờ học? Con số này hơi hoành tráng. Bây giờ, hãy tính riêng chương trình Front End Web Development – nó cần 478 giờ để hoàn thành. Mặc dù việc hoàn thành sớm hay muộn phụ thuộc vào kiến thức nền tảng và tư duy của mỗi người, thế nhưng, hãy coi 478 giờ làm mốc. Đó là thời gian của khóa học. Còn thời gian của chúng ta thì sao? Giả sử tôi muốn nhận được chứng chỉ Front End Web Developer sau 9 tháng (tức 270 ngày), như vậy, tôi cần dành ra 1,8 giờ mỗi ngày! 1,8 giờ mỗi ngày, và sau 9 tháng, tôi đã sẵn sàng đi làm!!
Đa phần mọi người đều có thể dành ra 1,8 giờ mỗi ngày. Nếu ai kém may mắn hơn, không thể thu xếp được ngần ấy thời gian thì tất nhiên, quá trình này có thể kéo dài hơn một chút. Dù vậy, tôi tin rằng hai ngày cuối tuần sẽ “bù” được khoảng thời gian đó.
Bạn không thể sắp xếp thời gian hợp lý cho việc coding? Hãy gặp tôi trên twitter – rất sẵn lòng chia sẻ và trợ giúp các bạn.
Quay trở lại trường hợp của chính bản thân mình, tôi mất 1 năm 2 tháng để hoàn thành chứng chỉ trên. Bạn se hơi bất ngờ vì tôi đã tìm được việc làm trước khi hoàn thành chứng chỉ nhưng tôi không bỏ dở nó, bởi tôi biết hoàn thành khóa học ấy là một trong những yếu tố giúp tôi trở thành developer thực thụ.
Bài viết này cũng là một bài phân tích về nguyên nhân tôi mất khá nhiều thời gian để hoàn thành. Tôi đã mắc tất cả những lỗi mà tôi nhắc đến ở đây. Vì thế, đưa ta lời khuyên cho các bạn cũng chính là một cách tự nhắc nhở và kiểm điểm bản thân của tôi. Chúng ta cùng hội cùng thuyền mà!
Nếu bạn muốn làm một project nghiêm túc, hoặc quan trọng hơn là kiếm được việc làm, hãy chú ý đến những điều tôi sắp đề cập sau đây.
Không được bỏ qua kiến thức cơ bản
Khi mới bắt đầu, hãy sử dụng tutorials, videos, cũng như các khóa học online để nằm vững và thuần thục cú pháp căn bản của HTML, CSS, JS, cũng như làm quen với tư duy lập trình. Nếu không có kiến thức căn bản, mọi nỗ lực build một project sẽ đi vào ngõ cụt. Tuy nhiên, đừng tốn quá nhiều thời gian ở giai đoạn này (bởi nó rất dễ).
Khi tôi học HTML/CSS/JS, tôi học các topic giống nhau ở nhiều nguồn khác nhau và nghĩ kiến thức của mình sẽ được củng cố chắc chắn hơn. Phương pháp này cũng giúp ích cho tôi một chút, nhưng dần dần tôi nhận ra nó đang ngăn cản tôi tiếp cận với các kiến thức mới, những kiến thức này thú vị hơn nhưng cũng khó hơn rất rất nhiều. Vậy, bạn hãy nhớ, đừng rơi vào vòng luẩn quẩn của việc liên tục ôn tập những kiến thức ta đã biết. Vừa tốn thời gian, vừa không nâng cao được trình độ.
Không trì hoãn
Khi bắt đầu project của mình, bạn chắc chắn sẽ gặp nhiều trở ngại. Nếu bạn kiên trì, ok, sẽ vượt qua. Nhưng sau đó, bạn sẽ gặp những khó khăn khác – tránh vỏ dưa gặp vỏ dừa mà! Ta không có quyền chọn lựa thử thách!
Và rồi chúng ta sẽ… nản. Tất nhiên! Nản thì… tạm dừng.
Điều đáng lo ngại ở đây là thời gian tạm dừng ngày một dài ra, chúng ta code ít dần, ít dần, cuối cùng là bỏ cuộc. Không ai thúc ép bạn, không ai quản lý tiến độ project của bạn ngoại trừ chính bản thân bạn. Vì vậy, bạn dễ dàng trì hoãn bản thân khỏi công việc, cụ thể ở đây là việc tự học và làm project. Loài người là một sinh vật tồn tại nhiều khiếm khuyết. Một trong số những khiếm khuyết đầu tiên mà bạn phải vượt qua đó là sự trì hoãn.
Đây là một giải pháp nho nhỏ của tôi, áp dụng cho trường hợp bạn đang gặp phải một vấn đề khó xơi trong project chính của mình: để tiện cả đôi đường, vừa “tạm nghỉ” project, vừa không bị xao nhãng, ta hãy làm một vài tutorials hoặc tham gia một khóa học online.
Bạn sẵn sàng tuyên chiến với sự trì hoãn? Hãy tham khảo chiến lược của James Clear ở đây.
Đừng bắt đầu với những thứ quá vĩ đại
Thật tuyệt vời nếu bạn đang ấp ủ một ý tưởng lớn. Thế nhưng tôi đã nghe quá nhiều những tuyên bố hùng hồn như: “Tớ muốn xây dựng một application cho phép người dùng tạo tài khoản cho thú cưng của họ, upload ảnh, theo dõi vị trí của chúng (và một cơ số những thứ hầm bà lằng nữa). Tuy tớ mới code thôi, nhưng tớ đã sẵn sàng!”. Tôi chỉ biết há hốc mồm khi nghe những tuyên bố ấy.
Bạn biết đấy, với những trường hợp này, lúc đầu họ rất hăng hái, từ từ xây dựng và hiện thực hóa ý tưởng của bản thân. Tuy nhiên, càng về sau, kiến thức của họ càng không thể đáp ứng được yêu cầu của project do chính họ đặt ra. Và mọi thứ bắt đầu trì trệ. Thậm chí tình huống xấu nhất hoàn toàn có thể xảy ra: họ bỏ project, và bỏ luôn code.
Hãy tưởng tượng bạn là một nhà văn, bạn có một ý tưởng cho tác phẩm để đời của mình, và ngay lập tức bạn bắt tay vào viết… Chắc chắn bạn sẽ chỉnh sửa bản thảo của mình một cách chật vật(ít nhất cũng phải 3-4 lần) trước khi đạt được chất lượng mong muốn. Trong khi đó, bạn có thể viết những mẩu chuyện ngắn, xuất bản chúng và lắng nghe phản hồi của độc giả, từ đó liên tục cải thiện kỹ năng viết của mình, và sẽ đến một lúc nào đó, bạn hoàn toàn tự tin để viết những dòng đầu tiên cho tác phẩm được ấp ủ bấy lâu nay mà không cần đắn đo quá nhiều trong việc chỉnh sửa sau này.
Các bạn nên bắt đầu với các project đơn giản, mỗi khi hoàn thành một trong số chúng, bạn sẽ cảm thấy được khích lệ và có nhiều động lực hơn. Không chỉ vậy, việc hoàn thành các project nhỏ ít nhiều sẽ giúp bạn nắm được cấu trúc của những project lớn.
Lấy cảm hứng cho project ở đâu?
Free Code Camp là câu trả lời của tôi.
Tôi luôn dùng đến Free Code Camp mỗi khi “mắc kẹt”. Khi bắt đầu sự nghiệp developer của mình, tôi hỏi tất cả các dev mà tôi biết về ý tưởng cho project đầu tiên. Và bạn có đoán được câu trả lời của họ là như thế nào không? TẤT CẢ bọn họ đều khuyên tôi làm một app To-Do List! (Chính tôi cũng bất ngờ vì điều này). Nếu tay nhập môn nào cũng làm theo lời khuyên này, internet sẽ tràn ngập các app To-Do List!
Trong khi đó, Free Code Camp có một danh sách Project rất rất thú vị, với độ khó tăng dần. Một điều tuyệt vời nữa: mỗi project sẽ dạy bạn một topic cụ thể. Ví dụ nhé: một Tribute page sẽ củng cố kỹ năng code HTML/CSS, một trang thông tin thời tiết sẽ giúp bạn biết cách làm việc cùng API, một bảng tính bằng JavaScript, tất nhiên rồi, sẽ cải thiện kĩ năng JS của chúng ta.
Tìm kiếm một ý tưởng phù hợp là điều tôi muốn nhấn mạnh với các bạn. Và với tất cả project đã hoàn thành, bạn có thể nhận phản hồi từ cộng đồng cũng như tham khảo cách tiếp cận project đó của nhiều thành viên khác.
Xây dựng cấu trúc cho project
Tôi cá rằng hồi phổ thông, mọi người rất ghét môn văn nhưng không có ai quên cấu trúc của một bài văn: mở bài, thân bài, kết luận… Với một project cũng vậy, bạn nên xác định cấu trúc của nó một cách rõ ràng. Việc đầu tiên bạn có thể làm là ghi ra toàn bộ các tính năng của project, càng cụ thể càng tốt, ví dụ: “Người dùng có thể nghe nhạc bằng cách nhấn vào nút play”, “Người dùng có thể login bằng email hoặc đồng bộ với tài khoản facebook”...
Bên cạnh đó, code của bạn cũng phải tuân theo một trật tự nhất định. Bạn nên viết chúng dưới dạng giả mã (pseudo code) trước. Ví dụ về pseudocode của một ứng dụng thông báo thời tiết theo vị trí người dùng:
/ Khi người dùng mở một trang mới, ghi lại vị trí của họ
/ Gửi vị trí kèm theo request tới weather API site
/ Nhận dữ liệu
/ Hiển thị nhiệt độ trên trang vừa được mở
/ Thay đổi màn hình nền phù hợp với nhiệt độ nhận được.Việc xác định rõ ràng cấu trúc của project giúp chúng ta dự đoán và xử lý tốt các vấn đề sắp phát sinh cũng như cải thiện chất lượng code. Chú ý, với pseudo code, đừng quá để ý đến tiểu tiết, hãy ghi ra những gì tổng quát nhất có thể.
Mắc kẹt ư? Đó là điều tất yếu
Như tôi đã đề cập ở đầu bài viết, trong quá trình làm project việc gặp rắc rối không đáng sợ như các bạn nghĩ. Dù rắc rối xảy ra mọi lúc mọi nơi nhưng việc chúng ta “mắc kẹt” với nó không có nghĩa chúng ta là những thằng ngốc. Chỉ đơn giản là chúng ta chưa hiểu hết về vấn đề đang gặp phải.
Khả năng thích nghi nhanh chóng với các vấn đề gặp phải sẽ cải thiện đáng kể tiến độ project của bạn. Lập trình chính là tập hợp những ý tưởng sáng tạo để giải quyết vấn đề. Vì vậy, nếu bạn không gặp những vấn đề hóc búa trong quá trình hoàn thành project, chứng tỏ bạn vẫn đang luẩn quẩn trong vùng an toàn của mình. Tôi khuyên bạn hãy nhảy ra ngoài khi còn có thể!
Hầu hết mọi trường hợp tôi đều nhấn mạnh rằng, nếu bạn gặp khó khăn, đừng nghĩ là mình kém cỏi. Tôi từng gặp những anh chàng chạy khóa HTML/CSS/JS của Free Code Camp với tốc độ khủng khiếp: 30-40 bài một ngày, và khi họ chuyển qua khóa giải thuật căn bản, họ nghĩ mình thật ngu ngốc khi chỉ có thể chạy 5 bài một ngày… Bản thân tôi cũng rơi vào tình cảnh tương tự, từng có suy nghĩ tương tự như họ, nhưng giờ thì đỡ hơn rồi. Qua câu chuyện này, các bạn cần học cách cân bằng giữa tiềm năng bản thân và thử thách.
Cân bằng giữa thử thách và tiềm năng của bản thân
Bạn cần sáng suốt lựa chọn một project có độ khó trung bình – không quá dễ, không quá phức tạp.
Ở phần 2, tôi đã nhắc đến vòng luẩn quẩn của việc học đi học lại những kiến thức dễ dàng, còn bây giờ, chúng ta hãy đề cập đến mặt còn lại: những kiến thức khó xơi.
Nguyên tắc chung khi tiếp cận với các kiến thức khó – những vấn đề mà bạn nghĩ là bạn không thể làm được – đó là ưu tiên giải quyết chúng trước. Hãy bắt đầu từ các cấu trúc căn bản, cố gắng code theo nó. Nếu bạn không thể giải quyết một vấn đề sau 2-3 ngày tập trung, hãy tạm gác nó lại, tìm một vấn đề tương tự - nhưng dễ hơn và hoàn thành nó. Sau khi tôi áp dụng nguyên tắc trên, tôi nhận thấy tiềm thức của mình vẫn tập trung vào giải quyết vấn đề mà tôi đang mắc phải. Tôi nảy sinh thêm một vài ý tưởng mới cho nó trong khi làm các việc đơn giản hơn – thực sự tôi rất bất ngờ vì điều này.
Có những lúc mọi việc sẽ không đơn giản như tôi nói nhưng lời khuyên của tôi vẫn không thay đổi – hãy cố gắng bám theo và vượt qua những thứ hơi khó khăn một chút cho với khả năng hiện tại của bạn.
Kiên cường
Đây là phẩm chất đáng quý của một developer nói riêng và những người thành công nói chung.
Với phần này, các bạn hãy tham khảo 3 cuốn sách sau:
- Letters from a Stoic - Seneca
- The Obstacle is the Way - Ryan Holiday
- Turning Pro - Steven Pressfield
Đặt các mục tiêu ngắn hạn
Một sự thật hiển nhiên: nếu bạn muốn đẩy nhanh tiến độ project của mình, bạn phải làm việc với nó hàng ngày. Và để tối ưu hóa tốc độ cũng như hiệu quả, bên cạnh tần suất làm việc, có những thứ bạn phải thuộc nằm lòng.
Đầu tiên, thay vì đặt một mục tiêu để hoàn thành, bạn hãy thử vạch ra một khoảng thời gian cố định hàng ngày dành cho công việc coding nói chung cũng như project của bạn nói riêng. (Theo ý kiến của tôi, nếu bạn mới bắt đầu, hãy giới hạn từ 30 phút đến 1 tiếng đồng hồ).
Tôi biết có bạn muốn try hard ngay từ đầu với 2-3h một ngày. Cũng tốt thôi, nhưng có lẽ nó sẽ phù hợp khi coding dần gắn bó với cuộc sống của bạn. Với một khoảng thời gian không quá dài: 30 phút – 1 tiếng, chắc chắn bản thân bạn biết sẽ duy trì được nó mỗi ngày. Bạn giữ thói quen ấy ngày qua ngày, và rồi bạn nhận thấy mình ngày càng code nhiều hơn cũng như cảm thấy thỏa mãn với những mục tiêu nho nhỏ đã vạch ra.
Sử dụng một khoảng thời gian ngắn mỗi ngày dành cho coding có thể xem như một mẹo nhỏ nhưng cực kỳ hữu ích bởi nó tận dụng được đặc điểm làm việc của não bộ. Bạn hãy quay về quá khứ, khi bạn có một project lớn và luôn luôn trì hoãn nó cho đến sát deadline. Tất nhiên bạn hoàn thành đúng thời hạn, nhưng trong khoảng thời gian ngắn ngủi trước deadline, bạn bị stress khủng khiếp!!. Vì thế, hãy nhớ lấy điều này: không ai đặt một cái deadline để bạn trở thành developer. Đúng vậy, không có ai, ngoại trừ chính bạn.
Nếu bạn chỉ đơn thuần đặt ra mục tiêu thì bạn khó lòng ước tính được thời gian hoàn thành nó, rồi bạn cũng không thể hoàn thành những gì đã vạch ra. Tất nhiên nó sẽ làm bạn cảm thấy tồi tệ và chán nản. Với các mục tiêu ngắn hạn hàng ngày, công việc của bạn luôn được hoàn thành ở một mức nào đó. Có thể với project của mình, 30 phút một ngày không thể giúp bạn hoàn thiện một tính năng nhưng dù sao thì tiến độ cũng liên tục được duy trì qua nhiều ngày. Cứ như vậy, sản phẩm đầu tay của bạn sẽ sớm được ra mắt.
Và một điều kì diệu nữa, khi bạn bắt đầu ngồi xuống và làm việc nghiêm túc, các ý tưởng sẽ dần nảy sinh trong đầu bạn cứ như chúng từ trên trời rơi xuống vậy. Cảm giác ấy thật tuyệt vời phải không nào?
Copy code rất lãng phí thời gian
Trong quá trình xây dựng project của mình, đừng copy code từ một project khác rồi tùy biến nó cho project của mình. Đừng “mượn” một phần code nào cả. Trong thời gian này, khi tham khảo một project, thay vì xem source code của nó, hãy chạy thử và phân tích. Đối với các topic trên Stack Overflow, hãy đọc nó, phân tích, và hiểu, sau đó tự mình code lại từ đầu. Bạn sẽ thấy việc này cực kì vất vả mặc dù bạn đã đọc và phân tích mọi thứ rất kỹ. Đó là sự khác biệt giữa “thực hành hướng thong thả” – deliberate practice và “thực hành hướng số lượng” –regular practice.
Copy code giúp bạn thể hiện tốc độ hoàn thành project với mọi người. Bên cạnh đó, nó còn giải quyết êm thấm các vấn đề hóc búa mà không phải suy nghĩ nhiều, và copy code đang đưa bạn quay về “vùng an toàn” mà bạn đang cố vùng vẫy để thoát ra. Nghiêm trọng hơn, copy code sẽ dần dần cắt đứt tư duy của chính bạn! Trong khi đó, tự mình giải quyết các vấn đề tuy hơi khó khăn và đôi khi không thoải mái cho lắm nhưng điều đó sẽ giúp tư duy của bạn linh hoạt và sắc bén hơn.
Theo tôi, chỉ nên tham khảo code của mọi người khi bạn đã hoàn thành project của mình. Vào thời điểm ấy, việc đọc code của người khác sẽ giúp bạn học được khá nhiều điều.
Không phân tán năng lực của bạn
Câu chuyện của chúng ta vẫn xoay quanh quá trình xây dựng project.
Một vài người bạn của tôi, khi project thứ nhất của họ đụng chạm đến những vẫn đề khó nhằn, họ có xu hướng tạm dừng nó lại rồi bắt đầu project thứ hai. Với project mới ấy, họ làm rất hăng hái cho đến khi vướng phải nhiều vấn đề (phức tạp hơn cả project đầu), lúc này họ có 2 project chưa hoàn thiện. Và việc này sẽ lặp đi lặp lại. Đó chính là cách mà năng lực của chúng ta đang bị phân tán.
Giải pháp của tôi là giới hạn 2 project tại cùng một thời điểm. Khi bạn mắc kẹt ở một cái, hãy dành thời gian xử lý nó, nếu không khả thi, chuyển sang cái thứ hai. Yếu tố quyết định ở đây là bạn không được tạo project thứ ba, nó sẽ phân tán khả năng của bạn và bạn sẽ sớm đi vào vết xe đổ như hai project trước.
Bạn nên tìm mọi giải pháp để duy trì project cũng như việc học của chính bạn! Nếu bạn thấy nản hoặc đơn giản chỉ là buồn, chán, hãy thư giãn một chút, tự nhắc nhở bản thân một lần nữa rồi quay lại với con đường bạn đã vạch ra. Dù sao đi nữa, đừng bỏ code chỉ vì nản!
Với cá nhân tôi, khi project hiện tại đang lâm vào bế tắc, tôi thường bay bổng một chút, hoặc tự học thêm một vài thứ hay ho, và cuối cùng – như tôi vừa nhắc đến – hãy thử làm 2 project, thay vì 1.
Hãy chú ý đến portfolio
Bạn nghĩ nhà tuyển dụng chỉ quan tâm đến bằng cấp và những gì bạn viết trong CV ư? Không, họ không ngốc thế đâu! Họ sẽ nhìn vào các sản phẩm của bạn!
Tất cả project bạn đã hoàn thành và public nó sẽ là vũ khí chủ lực của bạn. Năng lực chuyên môn của bạn ra sao, yếu huyệt của bạn nằm ở đâu... tất cả sẽ thể hiện ở project của bạn. Tuy nhiên đừng quá lo lắng, các project không nhất thiết phải hoàn hảo một cách tuyệt đối. Nhà tuyển dụng chỉ thích dùng nó để đánh giá chuyên môn thay vì ngồi ngắm một tập chứng chỉ mà thôi!
Nói thêm một chút, việc public các project của bạn lên internet có rất nhiều cái lợi khi đi phỏng vấn:
- Nhà tuyển dụng biết bạn đang làm gì.
- Họ cũng biết bạn đang liên tục học hỏi và nâng cao kỹ năng
- Và cuối cũng, họ đánh giá cao sự tự tin của bạn (public các project lên internet chứng tỏ bạn rất tự tin với sản phẩm của mình)
Kinh nghiệm khi đi phỏng vấn xin việc của cá nhân tôi cũng như những đồng nghiệp ở Toronto Free Code Camp đã cho thấy yếu tố quan trọng nhất trong quá trình tìm việc chính là portfolio - tập hợp các project mà bạn đã hoàn thành!
Bạn sẽ thể hiện tốt hơn trong buổi phỏng vấn
Trong buổi phỏng vấn, bạn sẽ phải trực tiếp hoàn thành một web app hoặc xử lý một vấn đề nào đó trong thực tế.
Thường thi người tuyển dụng sẽ chú ý đến phương pháp giải quyết vấn đề của bạn. Họ không trông chờ một giải pháp tối ưu! Đôi khi họ đưa cho bạn những vấn đề không có lời giải, chỉ để "thử" xem bạn xử lý nó như thế nào. Và các tình huống ấy bạn sẽ gặp rất nhiều trong quá trình xây dựng project trước kia của mình!
Các vấn đề thực tế mà bạn phải xử lý rất đa dạng. Đây là một số trường hợp trong buổi phỏng vấn của tôi. Dù code của tôi không được tối ưu lắm nhưng ít nhất nó cũng đưa ra một ví dụ cụ thể cho các bạn. Lý do duy nhất tôi có thể hoàn thành nó vào buổi phỏng vấn của mình là tôi đã có kinh nghiệm từ khi tham gia Free Code Camp, cụ thể, kinh nghiệm đó gồm xây dựng một app thông báo thời tiết và một bảng tính
Xử lý những lổ hổng kiến thức
Tutorial và những nguồn học liệu tương tự sẽ gây cho bạn ảo giác rằng sau khi hoàn thành chúng, bạn đã nắm được tất cả những kiến thức của lĩnh vực tương ứng... Rồi đến lúc bạn bắt tay vào xây dựng một project, bạn sẽ bị mắc kẹt ở những vấn đề rất đơn giản.
Tại sao lại thế?
Thứ nhất, kiến thức trong các tutorials được hệ thống và sắp xếp bởi một vài người nào đó. Họ chọn lọc chúng theo quan điểm cá nhân và những gì mọi người hay tìm kiếm. Thứ hai, rất đơn giản, một tutorial quá ngắn để chứa hết các kiến thức cần thiết.
Cách đơn giản để phát hiện ra những lỗ hổng kiến thức của bạn là không ngừng làm việc và học hỏi. Phạm sai lầm và sửa chữa cũng là một giải pháp hiệu quả!
Các project mới làm tôi choáng váng
Tôi không chắc bạn có giống tôi không. Nhưng đối với tôi, điều này xảy ra thường xuyên.
Tôi hoàn thành một project và cảm thấy thật tuyệt vời. Và sau đó, khi đọc phần user story của project tiếp theo, mọi thứ thay đổi 180 độ, tôi gần như tê liệt vì sợ hãi!
Làm thế nào để bắt đầu? Ưu tiên cái nào trước? Làm thế nào mà mình hoàn thành được project trước nhỉ?... Tôi dần rơi vào trạng thái hỗn loạn.
Cái khó ló cái khôn, trong những hoàn cảnh trớ trêu ấy, tôi nảy ra một ý tưởng:
Đầu tiên, tôi xem lại project vừa hoàn thành. Đa phần tôi thấy nó thật kinh khủng - thế nhưng bằng cách nào đó, tôi vẫn giải quyết ngon lành! Thật kì diệu phải không? Điều đáng chú ý khi xem lại project cũ là bạn nên tập trung vào cách giải quyết các vấn đề nhỏ. Đúng vậy, các vấn đề nhỏ! Sai lầm của tôi lúc hoảng loạn là không xây dựng cấu trúc cho project của mình bằng cách chia vấn đề lớn thành nhiều vấn đề nhỏ hơn. Tôi hi vọng bạn sẽ không mắc phải sai lầm đó một lần nữa!
Ngoài ra, xét theo khía cạnh tâm lý học, việc nhìn lại thành công trong quá khứ khi bạn đang cảm thấy tồi tệ là một giải pháp hữu hiệu để xốc lại tinh thần và sẵn sàng cho thử thách mới.
Đừng quá cầu toàn
Mục tiêu của project đầu tay mà bạn xây dựng, đó là đáp ứng đúng yêu cầu mà bạn đã vạch ra (hoặc được đặt hàng). Sau khi nó đã vận hành được, hãy cố gắng tối ưu project của bạn theo nhiều phương diện: design, chức năng, chất lượng các đoạn code... Tuy nhiên, đến một mức nào đó, hãy dừng lại. Project của bạn không tham gia vào một cuộc thi quốc tế! Project của bạn phản ánh những kiến thức bạn đã học và vận dụng được. Tôi nhận thấy hầu hết những người cầu toàn đều không thể làm được một cái gì đó ra trò!
Bài viết này sẽ mãi mãi là bản nháp nếu tôi liên tục đắn đo xem nó đã tốt hay chưa! Tôi chỉ biết rằng, tìm việc làm là một vấn đề mà rất nhiều đồng môn đang quan tâm, vì vậy tôi cần chia sẻ với mọi người một số thứ tôi biết và hi vọng nó sẽ hữu ích cho họ.
Để trí tưởng tượng được bay bổng
Lập trình là một nghệ thuật!
Tập trung vào việc thỏa mãn các user story, và phần còn lại của project chính là mảnh đất của chúng ta. Hãy tận dụng tối đa não phải của bạn và tự tin thể hiện cá tính của mình! Đây là Zen Calculator của tôi, một ví dụ đơn giản (hãy ấn AC liên tục để cảm nhận sự khác biệt với Window Calculator).
Lập trình mang lại cho chúng ta sự tư do sáng tạo. Mọi sản phẩm của bạn sẽ có một bản sắc riêng nếu bạn thổi cá tính của mình vào đó. Luôn là chính mình, làm những điều mình thích không chỉ với coding mà hãy áp dụng nó vào cả cuộc sống nữa!
Đừng bỏ quên những trò tiêu khiển
Như tôi đã đề cập ở trên, bạn có thể nghỉ ngơi, nhưng hãy nghỉ ngơi trong khuôn khổ cho phép. Xét một cách lý tưởng, bạn không nên xả hơi quá một tuần, cố gắng biến thời gian đó thành một chuyến đi thú vị nhằm thu thập các ý tưởng cũng như lấy cảm hứng cho project của mình. Và khi quay về, bạn nên nhanh chóng bắt nhịp với công việc.
Nhận phản hồi cho project của mình
Bạn nên cẩn thận khi chia sẻ project của mình. Hãy liên hệ với một developer thực thụ hoặc những người xuất sắc hơn bạn, nhờ họ review code và phản hồi về project của bạn. Những con người tốt bụng này sẽ sẵn lòng giúp bạn tìm ra những điểm yếu và những lỗ hổng kiến thức mà bạn không thể nhận ra.
Cách học lập trình tốt nhất là xây dựng một project cá nhân.
Đến đây, tôi hy vọng bạn đã hiểu được phần nào quan điểm đó. Với cá nhân tôi, quá trình xây dựng project của riêng mình là thời gian mà tôi học được nhiều thứ quý báu. Và tôi hy vọng trải nghiệm của bạn sẽ tuyệt vời hơn.
Bài được dịch từ Free Code Camp.
Bình luận