🥇Loại bỏ nỗi sợ hãi trước khi đi làm lần đầu

Cảnh trong phim “Harry Potter và Tù nhân Ngục Azkaban”

Vấn đề của thế giới này là những người có học thì đầy nghi ngờ, còn những kẻ ngốc lại đầy tự tin.
charles Bukowski

Gần đây tôi đã dạy một bài học lập trình riêng lẻ khác. Không giống như các lớp học thông thường, chủ đề không phải là xây dựng ngôn ngữ hay giải quyết vấn đề. Chàng sinh viên chia sẻ những trăn trở của mình về việc làm trong tương lai. Bản thân cậu sinh viên này khá thông minh. Một trong những người tham gia khóa học hoàn thành toàn bộ chương trình nhanh hơn bất kỳ ai khác và với các giải pháp ban đầu, nhưng anh ta luôn đánh giá thấp bản thân một cách chân thành. Theo tôi, những nghi ngờ như vậy chỉ nảy sinh do thiếu thông tin. Tôi đã cố gắng lấp đầy khoảng trống này một cách ngẫu hứng trong suốt bài học.

Các câu hỏi giống như thế này:

Hàng năm có rất nhiều sinh viên tốt nghiệp đại học và tất cả họ đều đi tìm việc làm. Đó là rất nhiều người. Họ có thể sẽ thuê người giỏi nhất, nhưng tôi sẽ không kiếm được chỗ.
Điều gì sẽ xảy ra nếu tôi làm sai và bị sa thải ngay lập tức?
Lỡ trong quá trình làm việc họ nhận ra tôi ngu ngốc và đuổi tôi ra ngoài thì sao?

Học sinh này không phải là người đầu tiên tôi trả lời những câu hỏi như vậy. Nhiều người mắc phải chúng và thường phải nói ra mà không chuẩn bị trước. Lần này tôi quyết định viết đoạn độc thoại của mình vào một cuốn sổ. Tôi tưởng chỉ có vài đoạn nhưng cuối cùng cũng đủ cho cả một bài viết.

Bài viết mô tả quan điểm từ quan điểm của tôi và dựa trên kinh nghiệm của tôi. Tuy nhiên, thế giới của chúng ta rất đa dạng và có nhiều điều kỳ diệu xảy ra trong đó. Nếu bạn không đồng ý với điều gì đó hoặc trải nghiệm của bạn có gì đó khác biệt, vui lòng viết bình luận.

Bài viết được viết bởi một nhà phát triển dành cho các nhà phát triển. Tuy nhiên, nếu bạn định làm công việc kiểm tra, quản trị hoặc bất kỳ công việc gì khác trong lĩnh vực CNTT thì một số lời khuyên cũng sẽ hữu ích cho bạn.

Họ sẽ không thuê bạn chút nào

Khi bạn tưởng tượng rằng nhiều trường đại học cho hàng trăm sinh viên tốt nghiệp mỗi năm, bạn sẽ thấy khó chịu. Làm thế nào để cạnh tranh với một đám đông lớn như vậy?

Thật không may, không phải tất cả sinh viên tốt nghiệp đều được đào tạo kỹ thuật đầy đủ. Hãy thử hỏi một sinh viên đại học nào đó mà bạn biết: làm thế nào để những người trong nhóm của anh ấy được phép tham gia các kỳ thi ở các ngành như “cơ sở dữ liệu” hoặc “nguyên tắc cơ bản về thuật toán và lập trình”? Trong một nhóm 30 người, nhiều nhất sẽ có 3-5 người “cao cấp” thực sự tự mình làm mọi việc. Phần còn lại chỉ cần sao chép từ chúng, nhồi nhét câu trả lời cho các câu hỏi và gửi đi.

Đây là tình trạng của tôi khi tôi tự học. Tuy nhiên, kinh nghiệm của tôi có thể không mang tính đại diện. Vì vậy tôi đã hỏi câu hỏi này với một số học sinh khác nhau. Câu trả lời khá giống nhau. Những người được hỏi đến từ các trường đại học và cao đẳng khác nhau. Tôi sẽ để lại các cuộc thảo luận về những lý do nằm ngoài phạm vi của bài viết này. Tôi không có đủ thời gian cho một nghiên cứu chính thức nên tôi sẽ rút ra kết luận từ những thông tin có sẵn.

Trong số hàng trăm sinh viên tốt nghiệp, chỉ có vài chục sinh viên được nhà tuyển dụng quan tâm

Rất ít sinh viên tốt nghiệp có thể tạo ra sự cạnh tranh thực sự cho một sinh viên có năng lực với sự chuẩn bị tốt. Tuy nhiên, ngay cả khi bạn học tập tận tâm thì sau buổi phỏng vấn đầu tiên rất có thể bạn sẽ không được tuyển dụng. Sau lần thứ hai, có lẽ cũng vậy. Mọi thứ có thể diễn ra tốt đẹp, nhưng tốt hơn hết bạn nên chuẩn bị tinh thần không phải cho một cuộc tấn công mà là cho một cuộc bao vây. Nỗ lực xin việc không thành công chỉ là lý do để bạn sửa chữa sai lầm và thử lại. Tôi sẽ không nói về việc chuẩn bị cho cuộc phỏng vấn. Rất nhiều điều đã được viết về chủ đề này trên Internet. Tôi chỉ nói rằng có những sắc thái trong cuộc phỏng vấn mà chương trình đào tạo của bạn có thể sẽ không dành thời gian để giải thích. Hãy tự mình tìm kiếm thông tin này, nó có thể làm giảm số lần thử.

Sự điên rồ là sự lặp lại chính xác của cùng một hành động. Hết lần này đến lần khác, hy vọng sự thay đổi
Albert einstein

Để giữ cho các cuộc phỏng vấn không trở nên điên rồ, bạn cần phải cải thiện sau mỗi lần thử mới. Ghi nhớ hoặc viết ra những câu hỏi bạn được hỏi trong cuộc phỏng vấn. Khi bạn trở về nhà, hãy xem qua danh sách này và kiểm tra bản thân bằng cách sử dụng Internet. Bằng cách này, bạn sẽ hiểu bạn và người phỏng vấn đã mắc lỗi ở đâu. Điều này cũng xảy ra. Xem lại hoặc nghiên cứu các chủ đề bạn thực hiện kém và thử lại.

Ngoài ra, còn có tính thời vụ rõ rệt của thị trường lao động. Các công ty thông minh lên kế hoạch tuyển dụng dựa trên ngày tốt nghiệp. Có nhiều vị trí tuyển dụng cho người mới vào mùa xuân hơn những thời điểm khác. Tuy nhiên, sự cạnh tranh ở thời điểm này cao hơn.

Ngu ngốc - bị đuổi việc

Khi một người không có kinh nghiệm được tuyển dụng, người đó sẽ có những kỳ vọng tương ứng.

Một người mới vào nghề dự kiến sẽ:

Kiến thức chung về nền tảng kỹ thuật
Nghiên cứu các chi tiết cụ thể về lĩnh vực chủ đề của công ty
Nắm vững các công cụ và thực hành được sử dụng

Một số tổ chức cung cấp các khóa đào tạo cho người mới về công nghệ được sử dụng, công cụ và quy trình địa phương. Ví dụ: cách cư xử tốt khi sử dụng email công ty, quy trình thay đổi tài liệu trong wiki, các tính năng cục bộ khi làm việc với VCS và trình theo dõi lỗi.

Ngoài ra còn có các khóa học giới thiệu kỹ thuật, nhưng tính hữu dụng của chúng vẫn còn nhiều nghi vấn. Nếu nói đến việc làm, thì nhà tuyển dụng tin chắc rằng bạn có đủ trình độ kiến thức. Tốt nhất là bạn chỉ nên tham gia các khóa học như vậy một cách thiện chí, chỉ như một thủ tục nhỏ. Có lẽ thực sự sẽ có điều gì đó hữu ích trong đó.

Khi bạn bắt đầu công việc, hãy nhớ rằng người mới bắt đầu chắc chắn sẽ không được giao nhiệm vụ giải quyết một nhiệm vụ cấp bách, phức tạp và đồng thời quan trọng. Nhiều khả năng sẽ chỉ có một trong những thuộc tính này. Hoặc đơn giản nhưng cấp bách: sửa lại bố cục, gửi file cho ai đó, tái hiện vấn đề. Hoặc khó, nhưng không có hy vọng hoàn thành - để người mới bắt đầu thu thập được nhiều tiền cào hơn. Hoặc quan trọng, nhưng mang tính thử nghiệm. Ví dụ, một dự án mà mọi người đều mong muốn từ lâu nhưng không có thời gian để thực hiện.

Nhiệm vụ để thành thạo các công cụ sẽ rất khó khăn và giả tạo. Nhiều khả năng đây sẽ là phiên bản đơn giản hóa của hệ thống chính. Những nhiệm vụ như vậy sử dụng cùng một ngăn xếp công nghệ và các thuật ngữ miền giống như toàn bộ dự án. Trong trường hợp này, kết quả thực thi sẽ không được cung cấp cho người dùng cuối. Điều này có thể làm mất động lực, nhưng tốt hơn hết là bạn nên chống lại cảm xúc này. Một nhiệm vụ nhân tạo phải được thực hiện một cách tận tâm, như thể số phận của dự án phụ thuộc vào nó.

Kết quả giải quyết vấn đề đầu tiên của bạn sẽ hình thành ấn tượng đầu tiên về bạn trong số những đồng nghiệp không có mặt tại buổi phỏng vấn.

Một tùy chọn khác cho tác vụ làm chủ công cụ là “chạy dự án trên môi trường máy/kiểm tra cục bộ”. Đôi khi quá trình này được mô tả trong hướng dẫn. Nhưng chúng thường cũ và ở một số nơi đã lỗi thời. Bạn có thể mang lại lợi ích thực sự cho dự án nếu bạn viết hướng dẫn mới kèm theo lời giải thích rõ ràng về các vấn đề phát sinh. Chắc chắn ở trường đại học bạn phải viết RGR cho một báo cáo về một số ngành học. Ở đây gần như giống nhau. Tài liệu phải phản ánh các hành động cần thực hiện để khởi chạy.

Thông thường, các bước để chạy một sản phẩm trên môi trường thử nghiệm sẽ như sau:

sao chép một kho lưu trữ, chuyển sang một số nhánh hoặc thẻ
tạo một số tập tin cấu hình
chuẩn bị cấu trúc cơ sở dữ liệu
điền vào đó dữ liệu thử nghiệm
xây dựng hoặc biên dịch dự án,
chạy một tập lệnh console theo một trình tự nhất định

Trong quá trình vận hành hệ thống cục bộ chắc chắn sẽ phát sinh những sự cố không mong muốn.

Việc tìm giải pháp cho các vấn đề nên được thêm vào hướng dẫn triển khai. Khi đó, lần sau khi bạn làm theo hướng dẫn, những vấn đề này sẽ không phát sinh. Khi điền vào các tệp cấu hình và gọi các tập lệnh, hãy chú ý đến giá trị nào được sử dụng ở đâu và nó phải khớp với cái gì. Ví dụ, nếu một dự án được xây dựng bằng hệ thống CI và sau đó được chạy bởi một tập lệnh, điều quan trọng là phải hiểu nơi nhập tên nhánh hoặc số commit. Đôi khi, tập lệnh yêu cầu truyền vào... Các địa chỉ IP hoặc tên DNS của cơ sở dữ liệu, tên đăng nhập và mật khẩu của nó. Trong trường hợp này, bạn cần biết địa chỉ cụ thể để sử dụng cho môi trường thử nghiệm, các tên đăng nhập mà nó chứa và mật khẩu cần chỉ định cho chúng.

Một số nhiệm vụ có vẻ đơn giản đối với các nhà phát triển có kinh nghiệm nhưng lại đầy thách thức đối với thực tập sinh. Điều này là bình thường.

Các nhà phát triển phải giải quyết các vấn đề kỹ thuật hàng ngày. Những nhân viên có kinh nghiệm trước đây đã giải quyết được nhiều vấn đề, trong khi những người mới đến vẫn chưa giải quyết được. Chiến thuật tốt nhất là ghi lại tất cả các lỗi gặp phải trong tài liệu “giải quyết vấn đề với ${task name}”. Đối với mỗi vấn đề, bạn cần đưa ra giả thuyết về nguyên nhân, tìm giải pháp trên Internet và thử từng giải pháp một. Kết quả của mỗi lần thử cũng phải được ghi lại.

Đăng ký nghiên cứu của bạn dưới dạng tài liệu sẽ cho phép bạn:

dỡ bỏ những chi tiết nhỏ ra khỏi đầu bạn. Ví dụ: tham số cấu hình, địa chỉ DNS/IP, lệnh console và truy vấn SQL.
nhớ “hôm qua tôi đã làm gì” khi nhiệm vụ kéo dài vài ngày
đừng đi lang thang trong vòng tròn. Bạn luôn có thể đọc những gì bạn đã làm trước đó và hiểu rằng bạn đã quay lại vấn đề ban đầu
Trả lời rõ ràng câu hỏi: “Hôm nay bạn đã làm gì?” ngay cả khi chưa có giải pháp làm sẵn.

Bạn cần có khả năng truyền đạt trạng thái nhiệm vụ của mình cho đồng nghiệp

Thỉnh thoảng, đồng nghiệp sẽ quan tâm đến thành công của bạn và chia sẻ thành công của họ. Dành một chút thời gian cho việc này hàng ngày hoặc hàng tuần.

Nếu bạn không theo dõi các vấn đề gặp phải và giải quyết, thì việc mô tả những thành công của bạn sẽ như sau: “Tôi đã cố gắng thực hiện nhiệm vụ nhưng tôi không thể làm được. Tôi vẫn đang tìm giải pháp.” Từ câu chuyện này, không rõ người thực tập sinh đang làm gì hay chỉ ngồi đọc sách. Anh ấy có cần giúp đỡ không? Tình hình có thay đổi kể từ hôm qua không?

Nếu bạn giữ một tài liệu để tìm giải pháp, bạn có thể nói “Tôi đang cố gắng thực hiện nhiệm vụ này. Tôi đã có những lỗi như thế này. Đây là cách tôi quyết định. Tôi chưa giải quyết vấn đề này. Có những giả thuyết và giải pháp này. Bây giờ tôi đang kiểm tra chúng."

Nếu nhiệm vụ có thể được đo lường theo bất kỳ cách nào thì trạng thái phải chứa số. Ví dụ: đối với nhiệm vụ “viết bài kiểm tra đơn vị cho một mô-đun”, bạn có thể nói “Tôi dự định thực hiện 20 bài kiểm tra, hiện tại tôi đã viết được 10 bài kiểm tra”.

Bạn cung cấp càng nhiều chi tiết thì đồng nghiệp của bạn sẽ càng hiểu rõ hơn những gì bạn đã làm. Điều này sẽ tạo ra thái độ tích cực đối với bạn trong số các đồng nghiệp của bạn và sẽ cho phép họ hiểu liệu bạn có cần giúp đỡ hay không.

Vui lòng yêu cầu giúp đỡ

Tôi đã viết ở trên rằng khi một vấn đề nảy sinh, bạn cần đưa ra giả thuyết về nguyên nhân của nó và các giải pháp khả thi. Tuy nhiên, điều xảy ra là các giả thuyết không được chứng minh và các giải pháp được tìm ra độc lập cho vấn đề không hiệu quả. Trong trường hợp này, tốt hơn là yêu cầu giúp đỡ. Để không lạm dụng sự chú ý của đồng nghiệp, bạn cần phải tự mình giải quyết từng vấn đề. Nếu bạn vẫn chưa tìm ra được giải pháp trong vài giờ thì đã đến lúc tìm kiếm lời khuyên từ những đồng chí có kinh nghiệm hơn.

Một nơi tốt để bắt đầu là hỏi, "có ai gặp phải vấn đề này trước đây chưa?" với một mô tả ngắn gọn về vấn đề. Nên đính kèm một phần thông báo lỗi hoặc ảnh chụp màn hình. Tốt hơn hết bạn nên gửi tin nhắn này lần đầu tiên đến một số cuộc trò chuyện chung về công việc. Bằng cách này, bạn sẽ không làm xao lãng những người thực sự bận rộn trong công việc. Các đồng nghiệp miễn phí sẽ nhìn thấy tin nhắn của bạn và có thể trợ giúp.

Nếu sau một tin nhắn trong cuộc trò chuyện chung mà không có ai giúp đỡ, hãy cố gắng gặp một đồng nghiệp có kinh nghiệm trong giờ giải lao: ăn trưa, đi uống trà/cà phê, chơi tennis hoặc hút thuốc. Nếu điều này không thành công, hãy báo cáo những khó khăn của bạn trong cuộc họp hoặc cuộc họp.

Nếu các vấn đề đã biết được giải quyết, mọi chuyện có thể kết thúc ở đó. Nếu vấn đề là mới, thì một cuộc điều tra sẽ bắt đầu, nơi cần phải hành động tùy theo tình huống.

Những nhiệm vụ mới bắt đầu “quan trọng” mà người dùng cuối cần sẽ nhàm chán và nhỏ nhặt. Ví dụ: “thêm một cột bổ sung vào báo cáo” hoặc “sửa lỗi đánh máy ở dạng in” hoặc “triển khai phương thức mô hình để tải các thuộc tính máy khách từ DBMS”. Mục đích của những nhiệm vụ như vậy là để người mới bắt đầu làm quen với lĩnh vực chủ đề và hòa nhập vào công việc hàng ngày.

Điều quan trọng không chỉ là giải quyết vấn đề về mặt kỹ thuật mà còn phải mở rộng kiến thức về lĩnh vực chủ đề.

Các điều khoản sẽ xuất hiện trong phần mô tả nhiệm vụ, trong các cuộc trò chuyện và hội thoại. Chúng có thể trông giống như những danh từ quen thuộc. Tuy nhiên, trong khuôn khổ hệ thống thông tin, chúng có ý nghĩa đặc biệt, chính xác hơn. Ý nghĩa của các thuật ngữ được phát hiện được ghi lại tốt nhất trong một tài liệu đặc biệt - từ điển thuật ngữ. Khi thêm vào từ điển, chỉ cần viết hiểu biết của bạn về từ này là đủ, nhưng để giải mã thực sự, tốt hơn hết bạn nên liên hệ với nhà phân tích. Nếu thiếu thì đi đến phần cũ của dự án. Duy trì từ điển thuật ngữ là một trong những cách đơn giản nhất để làm quen với lĩnh vực chủ đề của một dự án.

Khi bạn tìm thấy ngôn ngữ chung với đồng nghiệp của mình, họ sẽ bắt đầu coi bạn không phải là một thực tập sinh mới mà là một chuyên gia bình đẳng.

Có những nhiệm vụ đặc biệt, chẳng hạn như “viết bài kiểm tra đơn vị cho một mô-đun”. Bạn khó có thể bị mắc kẹt trong đó một thời gian dài để tìm kiếm giải pháp. Đồng thời, nó khá nghiêm túc và không chỉ được đưa ra để đào tạo học viên. Kiểm thử viết làm tăng tính ổn định của dự án bằng cách giảm lỗi trong ứng dụng và giảm thời gian kiểm thử con người. Trong một thế giới lý tưởng, các bài kiểm thử đơn vị được viết ngay lập tức trong quá trình phát triển, nhưng thực tế luôn khác. Điều xảy ra là nhà phát triển một mô-đun giữ nó hoàn toàn trong đầu và không thấy cần phải viết chúng. “Mọi thứ đều rõ ràng, còn gì để kiểm tra?” Đôi khi các mô-đun được viết ở chế độ gấp rút và không còn thời gian để kiểm tra đơn vị. Vì vậy, trong thế giới thực có thể không có bài kiểm tra đơn vị. Vì vậy, nhiệm vụ viết bài kiểm tra đơn vị được giao cho người mới bắt đầu. Bằng cách này, thực tập sinh sẽ có thể làm quen với dự án nhanh hơn và dự án sẽ có thể tiết kiệm thời gian của các chuyên gia được trả lương cao hơn.

Điều đó xảy ra là các thực tập sinh và những người mới đến được giao vai trò của những người thử nghiệm chính thức. Thông thường, trước khi thực hiện việc này, bạn cần triển khai sản phẩm cục bộ và đọc các yêu cầu. Do đó, nhân viên mới dự kiến sẽ:

những câu hỏi như “nếu bạn làm như thế này thì nó sẽ thành ra như thế này. Điều này không có trong yêu cầu. Có nên thế không?”
nhiệm vụ trong trình theo dõi lỗi “các yêu cầu nói như vậy, nhưng trên thực tế nó được viết khác”.

Thử nghiệm là một lĩnh vực quá rộng cho bài viết này. Nếu bạn được giao một nhiệm vụ tương tự, hãy tìm kiếm trên Internet cách tốt nhất để hoàn thành nó.

Nếu bạn làm sai, bạn sẽ bị sa thải

Trong một tổ chức bình thường, nếu đột nhiên xảy ra trường hợp một nhân viên thiếu kinh nghiệm có được quyền truy cập vào thứ gì đó quan trọng và làm hỏng thứ gì đó, thì người đã cho phép điều này xảy ra sẽ phải chịu trách nhiệm. Bởi vì theo mặc định, người mới bắt đầu không có quyền truy cập vào cơ sở hạ tầng quan trọng. Với sự hướng dẫn đầy đủ, họ sẽ không để tất cả những con chó bị lãng phí bởi một học viên thiếu kinh nghiệm.

Nếu có chuyện gì xảy ra, họ sẽ không sa thải bạn chỉ vì một sự cố. Mọi người học hỏi từ những sai lầm. Thực tập sinh mắc lỗi đã học được một bài học quý giá và rất khác biệt với những thực tập sinh khác. Nếu bạn sa thải một người gây rối, một người khác sẽ thay thế anh ta và gây rối theo cách tương tự.

Điều quan trọng là học hỏi từ những sai lầm và không lặp lại chúng nữa.

Nếu một người không rút ra kết luận từ những sai lầm của mình, thì họ sẽ cố gắng nói lời chia tay với anh ta. Tuy nhiên, thế giới rất đa dạng. Trong một tổ chức xã hội đen nào đó, họ có thể ngay lập tức ném bạn ra ngoài cửa sổ vì sai lầm đầu tiên. Nhưng tốt hơn hết bạn nên tránh những công ty như vậy bằng cách đặt câu hỏi trước hoặc tìm hiểu thêm trong cuộc phỏng vấn.

Tốt hơn là tránh sự cố

Ngay cả khi cá nhân bạn không bị sa thải vì sai sót, sự cố như vậy sẽ gây ra những vấn đề không mong muốn cho nhóm của bạn và toàn bộ dự án. Do đó, hãy đặc biệt cẩn thận với các thao tác xóa hoặc tạo bảng trong cơ sở dữ liệu, tệp, phiên bản dịch vụ và tài liệu trong cơ sở tri thức dự án. Nếu bạn tìm thấy địa chỉ của một kết nối mới, hãy kiểm tra với ít nhất hai người khác nhau xem có thể làm gì ở đó. Kiểm tra quyền của bạn trong môi trường không phải bằng cách thử và sai mà bằng cách sử dụng các lệnh thích hợp. Ví dụ: quyền xóa tệp bằng lệnh `ls`, quyền làm việc với các bảng trong mysql bằng lệnh `SHOW GRANTS FOR 'user'@'host';`, v.v. Trong hầu hết mọi công cụ, bạn sẽ có cơ hội tương tự.

Khi chỉnh sửa tập tin, hãy giữ một bản sao của bản gốc để đề phòng.

Một số rào cản được xây dựng giữa học viên và người dùng cuối.

Nếu bạn có thể cung cấp ngay sản phẩm của mình cho người tiêu dùng, bạn sẽ không thể kiếm được việc làm mà có thể bắt đầu “bơi tự do”. Nhưng trong khi bạn không có cơ hội như vậy (đồng thời là trách nhiệm), bạn cần phải trải qua một số giai đoạn kiểm soát dự án.
Đầu tiên trong số này là sự xác minh của một người cố vấn. Anh ấy đánh giá quyết định của người mới từ góc độ kỹ thuật. Nếu người cố vấn chưa được chỉ định, thì bạn cần tìm một người. Để làm điều này, bạn cần chọn một trong những người cũ của dự án và trong giờ giải lao, hãy yêu cầu anh ta xem xét giải pháp: vấn đề đã được giải quyết đúng cách chưa? Nếu anh ta bắt đầu tìm kiếm và phản hồi thì tức là đã tìm được người cố vấn. Nếu anh ta phớt lờ nó thì đáng để hỏi người khác.

Giai đoạn tiếp theo là Đảm bảo chất lượng. Trong tiếng Nga - người thử nghiệm. Theo phong cách Liên Xô - bộ phận kiểm soát tiêu chuẩn và kiểm soát chất lượng. Họ phải đảm bảo rằng hiệu suất của học viên phù hợp với nhiệm vụ được giao. Họ sẽ hiếm khi đọc mã. Thông thường, người thử nghiệm sẽ kiểm tra dự án đã xây dựng mà nhà phát triển lưu trữ trong hệ thống kiểm soát phiên bản.

Giai đoạn thứ ba là người quản lý phát hành. Có thể không có người riêng cho nhiệm vụ này nhưng vẫn có người đảm nhận vai trò này. Anh ta kiểm tra xem những người thử nghiệm đã xác nhận rằng dự án có thể được phát hành hay chưa. Sau đó, nó thực hiện các hoạt động để cung cấp sản phẩm cho người dùng cuối.
Trong các tổ chức nhỏ, những rào cản này có thể không tồn tại vì nhiều lý do. Tuy nhiên, họ sẽ không giao cho người mới nhiệm vụ thay đổi điều gì đó quan trọng. Bởi vì không ai cần rủi ro này.

Bạn cần phải tham gia vào trận chiến trước, sau đó chúng ta sẽ xem.
Napoléon Bonaparte

Tôi hy vọng bài viết này sẽ giúp bạn vượt qua sự không chắc chắn và gửi bản lý lịch đầu tiên của mình. Tất nhiên, bạn phải chuẩn bị trước. Nhưng không cần thiết phải mở rộng quá mức. Rất có thể bạn đã học tại một trường đại học hoặc cao đẳng trong vài năm. Đi đâu tiếp theo? Cuối cùng, thà nghe “không” một lần từ chuyên gia và khắc phục sai lầm còn hơn là nói “không” với chính mình mỗi ngày và ngừng phát triển về mặt chuyên môn.

Sau khi được tuyển dụng, bạn cần tập trung vào việc phát triển từ một thực tập sinh thành một thành viên chính thức của nhóm. Kiểu tăng trưởng này thường đi kèm với việc tăng lương của bạn.

Tôi chúc bạn kiên nhẫn và kiên trì.

Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. Đăng nhập, xin vui lòng.