งานทั่วไปของนักพัฒนา Java บนโปรเจ็กต์

ความรับผิดชอบทั่วไปของนักพัฒนา Java คืออะไร? ท้ายที่สุดคุณต้องเข้าใจว่าคุณกำลังทำอะไรอยู่และสุดท้ายคุณจะทำใช่ไหม? วันนี้ฉันอยากจะพูดถึงงานหลักสิบประการที่นักพัฒนา Java ดำเนินการ แต่ก่อนอื่น มาทำความรู้จักกับเครื่องมืออย่างจิรากันก่อน หรือมารีเฟรชความทรงจำของเราถ้าคุณคุ้นเคยแล้ว Jiraเป็นเครื่องมือโต้ตอบกับผู้ใช้ แม้ว่าในบางกรณีจะใช้สำหรับการจัดการโครงการด้วย กล่าวอีกนัยหนึ่ง การพัฒนาโครงการแบ่งออกเป็นงานเล็กๆ ตามที่อธิบายไว้ในเครื่องมือนี้ งานเหล่านี้ได้รับมอบหมาย (มอบหมาย) ให้กับนักพัฒนาซึ่งจะรับผิดชอบในการใช้งาน ตามงาน เราหมายถึง เช่น การเพิ่มฟังก์ชันการทำงานบางอย่าง เมื่อความคืบหน้าดำเนินไป นักพัฒนาและผู้เชี่ยวชาญอื่นๆ จะเพิ่มความคิดเห็นว่าใครทำอะไรและใช้เวลาไปเท่าไร เพื่อติดตามเวลา ทำเช่นนี้เพื่อติดตามเวลาที่ใช้: ใช้จ่ายไปเท่าไรและทำอะไร ตามหลักการแล้ว ให้ทำวันละครั้ง: ในตอนเย็นก่อนออกเดินทาง คุณจะติดตามงานที่คุณใช้เวลาไป 8 ชั่วโมง ฟังก์ชั่นของ Jira นั้นกว้างกว่าที่อธิบายไว้ข้างต้นมาก แต่จะเพียงพอสำหรับความเข้าใจเบื้องต้น ดังนั้นความรับผิดชอบของ Java Developer คืออะไร?

1. การพัฒนาโซลูชั่นใหม่ๆ

ก่อนที่คุณจะสร้างและใช้งานบางสิ่ง คุณต้องคิดก่อนใช่ไหม? อย่างที่ฉันบอกไปแล้ว สิ่งนี้อาจง่ายพอๆ กับ งาน Jiraที่จะมอบหมายให้คุณ และคุณจะทำงานเพื่อพัฒนาโซลูชันใหม่ โดยสังเกตว่า Jira ใช้เวลาเท่าไหร่และทำอะไร นี่อาจเป็นการอภิปรายการโทรเป็นทีมกลุ่ม โดยทุกคนจะสามารถแสดงความคิดเห็นและเสนอแนวทางที่พวกเขาเห็นว่าดีที่สุด และที่นี่ฉันอยากจะทราบบางประเด็น ประการแรก อาชีพนักพัฒนาเป็นสาขาที่สร้างสรรค์มาก เนื่องจากคุณจำเป็นต้องคิดหาวิธีที่ไม่เหมือนใครในการแก้ปัญหาโดยใช้เครื่องมือมาตรฐาน บ่อยครั้งที่ปัญหาหนึ่งอาจมีวิธีแก้ไขที่แตกต่างกันมากมาย ดังนั้น ทุกอย่างขึ้นอยู่กับ "จิตวิญญาณแห่งการสร้างสรรค์" ของนักพัฒนา ฐานความรู้และประสบการณ์ที่สั่งสมมา ที่นี่คุณสามารถแสดงความคิดสร้างสรรค์และอัจฉริยะทั้งหมดของคุณได้ แต่สิ่งสำคัญคืออย่าหักโหมจนเกินไป: ในกรณีนี้โค้ดจะซับซ้อนเกินไปและอ่านไม่ออก และด้วยเหตุนี้หลังจากที่คุณจากไป จะไม่มีใครเข้าใจอย่างถ่องแท้ว่ามันคืออะไรและ มันทำงานอย่างไร. และคุณจะต้องเขียนทุกอย่างใหม่ตั้งแต่ต้น และพวกเขาอาจจะจำคุณได้ และมากกว่าหนึ่งครั้ง และสิ่งเหล่านี้ไม่น่าจะเป็นคำพูดที่อบอุ่นและใจดี คุณต้องการมันไหม? ประการที่สอง นักพัฒนาซอฟต์แวร์จะต้องมีความยืดหยุ่นในแง่ที่ว่า คุณไม่ควรติดอยู่กับโซลูชันเดียวและปิดสนิทกับผู้อื่น เช่นคุณต้องทำวิธีนี้เท่านั้นและไม่มีอะไรอื่น สิ่งนี้สามารถเกิดขึ้นได้จากหลายสาเหตุ: ตัวอย่างเช่น คุณต้องการพิสูจน์มุมมองของคุณ หรือคุณได้พัฒนาและใช้งานโซลูชันของคุณแล้ว ซึ่งคุณค่อนข้างจะผูกพันและแน่นอน ไม่ต้องการที่จะยอมรับว่ามันไม่ใช่ ดีที่สุด. สิ่งนี้อาจทำให้คุณตาบอดได้ ในความเป็นจริง คุณต้องสามารถยอมรับข้อผิดพลาดของคุณและเปิดใจรับสิ่งใหม่ ๆ อยู่เสมอ (“ใจกว้าง”) แม้ว่าคุณจะต้องลบฟังก์ชันที่คุณเขียนมาหลายสัปดาห์และคุณภูมิใจมากก็ตาม ฉันจำได้ว่าครั้งหนึ่งอารมณ์ของทั้งวันเกิดขึ้นจากการติดตามเวลาของใครบางคนในจิราพร้อมความคิดเห็น: “ ฉันลบฟังก์ชั่นที่ยังไม่เกิดของฉันออกไป ฉันร้องไห้"

2. การเขียนฟังก์ชั่นใหม่

นี่เป็นขั้นตอนเชิงตรรกะตามขั้นตอนก่อนหน้า - การใช้งานฟังก์ชันใหม่ งานทั้งหมดในโครงการแบ่งออกเป็นงานในจิราซึ่งนักพัฒนาจะได้รับในขณะที่ทำงาน มีแนวทางที่แตกต่างกันสำหรับปัญหานี้ - "วิธีการ" ซึ่งคุณสามารถอ่านเพิ่มเติมได้ในบทความเกี่ยวกับ JavaRush ตามกฎแล้ว งานจะมี"การประมาณค่า"ซึ่งเป็นเวลาที่คาดการณ์ไว้ที่ใช้ในการทำให้เสร็จ มันถูกตั้งค่าโดยคุณเองเมื่อคุณทำงานหรือโดยหัวหน้าทีมหรือในระหว่างการวางแผนที่นักพัฒนาร่วมกันประเมิน คราวนี้เดาได้ยากนัก เนื่องจากมีหลายปัจจัยที่มีอิทธิพลต่อการพัฒนา ตัวอย่างเช่น โปรแกรมเมอร์คุ้นเคยหรือไม่คุ้นเคยกับเทคโนโลยีนี้ ประสบการณ์ทั่วไปของเขาคืออะไร ข้อผิดพลาดต่างๆ ที่อาจมองเห็นได้ในระหว่างการพัฒนา เป็นต้น ดังนั้นหากคุณไม่ปฏิบัติตามกำหนดเวลาในการพัฒนาฟังก์ชันการทำงาน ก็ไม่มีอะไรเลวร้ายเกิดขึ้น นี่เป็นเพียงการประมาณการทั่วไป แต่ขอย้ำอีกครั้ง ไม่ใช่ว่าทุกโครงการจะมีการประมาณการงาน และสำหรับฉัน มันง่ายกว่ามากที่จะใช้ชีวิตโดยปราศจากการประมาณการนี้ โดยเฉพาะอย่างยิ่งเมื่อนายกรัฐมนตรีไม่ถามคุณที่ด้านข้างสองสามครั้งต่อวันด้วยคำถาม “การประมาณการอยู่ที่ไหน? ” ดังนั้นคุณจึงรับงานพัฒนาฟังก์ชันที่จำเป็นอัปโหลดไปยังสาขาทั่วไปในGITและในจิราเปลี่ยนสถานะของงานเป็น“พร้อมสำหรับการตรวจสอบ”นั่นคือพร้อมสำหรับการดู (ตรวจสอบ) และอธิษฐานว่า จะไม่ส่งคืนให้คุณพร้อมความคิดเห็นเกี่ยวกับการแก้ไข

3. การเขียนแบบทดสอบการทำงาน

คนที่ตรวจสอบรหัสของคุณ - ผู้ตรวจสอบ - ชอบฟังก์ชั่นที่คุณพัฒนาขึ้น แต่เขามีคำถาม: การทดสอบมันอยู่ที่ไหน? และเขาจะคืนงานให้คุณเพื่อแก้ไข การทดสอบเป็นส่วนสำคัญของแอปพลิเคชัน Java เมื่อเรียกใช้งาน คุณจะสามารถทราบได้ทันทีว่าแอปพลิเคชันทำงานผิดพลาดตรงไหน ตัวอย่างเช่น นักพัฒนาได้ทำการเปลี่ยนแปลงบางอย่างในส่วนหนึ่งของระบบ ซึ่งนำไปสู่การเปลี่ยนแปลงพฤติกรรมในอีกส่วนหนึ่ง และไม่ได้สังเกตเห็นสิ่งนี้ในระหว่างการพัฒนา เมื่อทำการทดสอบ เขาจะสามารถเห็นการทดสอบที่ล้มเหลว (การทดสอบที่ทำงานไม่ถูกต้อง) สิ่งนี้จะบอกเขาว่ามีบางอย่างเสียหายในส่วนอื่นของระบบ ดังนั้นเขาจะไม่อัปโหลดการเปลี่ยนแปลงที่เสียหายไปยังเซิร์ฟเวอร์ แต่จะยังคงปรับปรุงโซลูชันของเขาต่อไป ใช่ แน่นอนว่ามีนักพัฒนาเพียงไม่กี่รายที่ชอบการทดสอบ แต่ก็ปฏิเสธไม่ได้ว่าพวกเขาจะได้รับประโยชน์อะไรบ้างจากแอปพลิเคชัน บ่อยครั้งที่ลูกค้าระบุระดับความครอบคลุมของการทดสอบที่จะปฏิบัติตาม (เช่น 80%) ดังนั้นคุณจำเป็นต้องรู้การทดสอบประเภทต่างๆและสามารถเขียนได้ นักพัฒนา Java ส่วนใหญ่เขียนการทดสอบหน่วยและการทดสอบการรวม ในขณะที่ AQA (ผู้ทดสอบระบบอัตโนมัติ) จัดการกับการทดสอบที่ครอบคลุมมากขึ้น (จากต้นทางถึงปลายทาง) คุณสามารถอ่านเพิ่มเติมเกี่ยวกับพวกเขาและตัวแทนด้านไอทีอื่น ๆ ได้ในบทวิจารณ์ของฉัน

4. ค้นหาและแก้ไขจุดบกพร่อง

นี่เป็นงานที่พบบ่อยและบ่อยครั้งสำหรับนักพัฒนา Java หน้าที่หลักของ QA และ AQA คือการตรวจจับข้อบกพร่อง นั่นคือพวกเขามองหาสถานที่ที่โปรแกรมทำงานไม่ถูกต้องสร้างปัญหาในจิราและตำหนิใครบางคน ตัวอย่างเช่น หัวหน้าทีมซึ่งจะเป็นผู้ตัดสินใจว่านักพัฒนารายใดจะมอบหมายสิ่งนี้ให้ ขึ้นอยู่กับภาระงานและความคุ้นเคยกับส่วนนี้ของระบบ หลังจากนี้ นักพัฒนาค้นหาจุดบกพร่อง โดยใช้เวลาหลายชั่วโมงในดีบักเกอร์โดยใช้คำอธิบายปัญหาโดยผู้เชี่ยวชาญ QA เพื่อทำซ้ำสถานการณ์ที่เกิดจุดบกพร่อง จากนั้น นักพัฒนาซอฟต์แวร์จะค้นหาจุดบกพร่อง แก้ไข และส่งไปตรวจสอบ เป็นไปได้ว่านักพัฒนาไม่สามารถสร้างข้อผิดพลาดซ้ำได้ และเขาจะส่งคืนงานให้กับผู้เชี่ยวชาญ QA กลับมาพร้อมความคิดเห็นเกี่ยวกับเรื่องนี้ ดูเหมือนว่าจะใช้เวลาไม่นานในการค้นหาและแก้ไขจุดบกพร่อง แต่มีความแตกต่างบางประการ ทุกอย่างขึ้นอยู่กับความคุ้นเคยของนักพัฒนากับโค้ดส่วนนี้ ประสบการณ์ และความรู้เกี่ยวกับประเด็นทางทฤษฎีเป็นหลัก บางครั้งสามารถพบข้อบกพร่องและแก้ไขได้ภายใน 20 นาที และบางครั้งอาจใช้เวลาสามวัน ดังนั้นงานประเภทนี้จึงประเมินล่วงหน้าได้ยากเป็นพิเศษ เว้นแต่นักพัฒนาจะเข้าใจทันทีว่าอะไร ที่ไหน และเกิดอะไรขึ้นหลังจากอ่านคำอธิบายแล้ว ในกรณีนี้เขาจะสามารถเดาเวลาได้แม่นยำไม่มากก็น้อย

5. การตรวจสอบโค้ด

ตามที่กล่าวไว้ข้างต้นทันทีที่คุณทำงานเสร็จจะต้องส่งไปตรวจสอบและหากผ่านก็จะเข้าสู่กระทู้ทั่วไปหากไม่ผ่านก็จะถูกส่งกลับไปยังนักพัฒนาพร้อมความคิดเห็นเกี่ยวกับสิ่งที่จำเป็น แก้ไขแล้ว เป็นที่ชัดเจนว่าทั้งหมดนี้ไม่ได้ตรวจสอบโดยผู้มีอำนาจที่สูงกว่า แต่โดยนักพัฒนารายอื่น แต่ไม่ใช่นักพัฒนาทุกคนจะได้รับอนุญาตให้เป็นผู้ตรวจสอบ แต่เฉพาะผู้ที่มีประสบการณ์มากที่สุดเท่านั้นที่ฝึกฝนอยู่เบื้องหลังและสามารถแยกแยะโค้ดที่ไม่ดีออกจากโค้ดที่ดีได้ โดยปกติแล้วการตรวจ สอบโค้ดจะดำเนินการโดยใช้เครื่องมือเสริม เช่นCrucible ผู้ตรวจสอบจะตรวจสอบโค้ดและแสดงความคิดเห็นไว้ใต้บรรทัดบางบรรทัดหากจำเป็น ความคิดเห็นอาจมีหลายประเภท ตัวอย่างเช่น ประเด็นสำคัญที่ไม่มีการแก้ไข ซึ่งผู้ตรวจสอบจะไม่ส่งรหัส และคนอื่นๆ มักจะเป็นเพียงความคิดเห็นเกี่ยวกับแนวทางที่เลือก ซึ่งนักพัฒนาสามารถรับฟัง จดบันทึก หรือเพิกเฉยได้ ทีมงานสามารถสร้างขั้นตอนและกฎเกณฑ์ของตนเองในการดำเนินการตรวจสอบ ตกลงว่าสิ่งใดที่ควรค่าแก่การใส่ใจและสิ่งที่ไม่ควรทำ ภายในกรอบเวลาที่ควรดำเนินการตรวจสอบโค้ด เป็นต้น หากต้องการดำเนินการตรวจสอบ ประสบการณ์เพียงอย่างเดียวไม่เพียงพอ คุณยังต้องพัฒนาด้านเทคนิคอีกมาก อ่านหนังสือหลายเล่ม (เช่น“Clean Code” ) หากคุณสนใจในความแตกต่างของการดำเนินการตรวจสอบโค้ดตาม Google ฉันแนะนำให้คุณอ่านบทความนี้

6. การวิเคราะห์รหัส

เนื่องจากโครงการนี้เขียนขึ้นพร้อมกันโดยคนหลายคนที่มีความคิดแตกต่าง โค้ดและแนวทางของพวกเขาจึงแตกต่างกัน และเมื่อเวลาผ่านไปทุกอย่างจะค่อยๆกลายเป็นข้าวต้ม เพื่อปรับปรุงโค้ด บางครั้งคุณสร้างงานเพื่อวิเคราะห์ อาจเป็นโมดูลเฉพาะหรือทั้งแอปพลิเคชัน เพื่อค้นหาข้อบกพร่องและทำเครื่องหมายข้อบกพร่อง จากนั้นจึงสร้างงานการปรับโครงสร้างใหม่ตามความคิดเห็นเหล่านี้ การวิเคราะห์ยังช่วยในสถานการณ์ที่ทางลัดที่เรียบง่ายกว่าไม่สามารถมองเห็นได้ตั้งแต่เริ่มต้นการพัฒนา แต่ตอนนี้สามารถเห็นได้แล้ว ตัวอย่างเช่น ตรรกะเดียวกันมักจะถูกทำซ้ำในบางวิธี ดังนั้น จึงสามารถย้ายไปยังวิธีอื่นและนำกลับมาใช้ใหม่ได้หลายครั้ง บางคลาสอาจมีการบวมอย่างเจ็บปวด หรือโค้ดบางอันกลายเป็นเรื่องยากที่จะรักษาหรือล้าสมัย หรือ... งานการวิเคราะห์ช่วยปรับปรุงคุณภาพของโค้ดและแอปพลิเคชัน แม้ว่าในความคิดของฉัน การวิเคราะห์โค้ดจำนวนมากอาจเป็นงานที่น่าเบื่อ

7. การปรับโครงสร้างโค้ดใหม่

ส่วนต่อไปของการวิเคราะห์คือการปรับโครงสร้างโค้ดใหม่ มันอาจจะล้าสมัย ไม่จำเป็นอีกต่อไป เขียนไม่ดี อ่านยาก และอื่นๆ คุณควรมุ่งมั่นเพื่อความสมบูรณ์แบบเสมอ (แม้ว่าจะไม่มีอยู่จริง) และสำหรับโค้ดที่ทันสมัย ​​ให้ลบทุกสิ่งที่ไม่จำเป็นออก เพราะสิ่งนี้ทำให้เกิดความสับสนและป้องกันไม่ให้คุณมองเห็นสาระสำคัญของฟังก์ชันการทำงาน ดำเนินไปโดยไม่ได้บอกว่าคุณไม่น่าจะเห็นงานเหล่านี้ในช่วงเริ่มต้นของโครงการ: งานเหล่านี้เกิดขึ้นเฉพาะในขั้นตอนหลังของการพัฒนาเท่านั้น เมื่อแอปพลิเคชันได้รับการขัดเกลาและนำไปสู่ความสมบูรณ์แบบ ในที่นี้ อาจเป็นการเหมาะสมที่จะปรึกษากับเพื่อนร่วมงานว่าพวกเขาจะทำอย่างไรและพบข้อผิดพลาดอะไรบ้าง สาระสำคัญของงานดังกล่าวคล้ายกับการพัฒนาฟังก์ชันใหม่ ตัวอย่างเช่น คุณได้รับงานให้แก้ไขฟังก์ชันบางอย่างโดยไม่ต้องเปลี่ยนลักษณะการทำงาน ในการดำเนินการนี้ คุณจะต้องลบอันเก่า เขียนของคุณเอง และตรวจสอบการทดสอบ หากคุณทำทุกอย่างถูกต้องโดยไม่ทำการเปลี่ยนแปลงการทดสอบ การทดสอบควรจะทำงานได้เหมือนเดิม หลังจากจัดการโค้ดทุกอย่างเรียบร้อยแล้วเราก็ส่งไปตรวจสอบและไปดื่มกาแฟ))

8. การเขียนเอกสาร

ลองนึกภาพว่าคุณเป็นนักพัฒนาหน้าใหม่ในโครงการบางโครงการที่ได้รับการพัฒนามาเป็นเวลานาน คุณต้องทำความคุ้นเคยกับมันหรือทำงานเฉพาะบางอย่าง เช่น การจับจุดบกพร่อง คุณจะนำทางโครงการอย่างไร? ดึงสมาชิกในทีมของคุณทุกๆ ห้านาที? แล้วถ้าพวกเขายุ่งหรือช่วงสุดสัปดาห์ล่ะ? นี่คือเหตุผลที่มีเอกสารประกอบ เพื่อให้บุคคลที่ไม่คุ้นเคยกับฟังก์ชันการทำงานสามารถเข้าไป ค้นหาหน้าที่ถูกต้อง และค้นหาได้อย่างรวดเร็วว่าส่วนใดของแอปพลิเคชันที่เขาสนใจทำอยู่ แต่ต้องมีบางคนกรอกเอกสารด้วย ^^ หากโครงการมีเอกสารที่นักพัฒนาต้องสนับสนุน เมื่อใช้ฟังก์ชันใหม่ พวกเขาจะอธิบายเกี่ยวกับโครงการ และด้วยการเปลี่ยนแปลงและการปรับโครงสร้างใหม่ พวกเขาอัปเดตเอกสารประกอบ สถานการณ์ยังเกิดขึ้นได้เมื่อมีการจ้างผู้เชี่ยวชาญแยกต่างหาก ซึ่งเป็นนักเขียนด้านเทคนิค ให้เขียน สนับสนุน และควบคุมเอกสาร หากมีผู้เชี่ยวชาญดังกล่าวอยู่ ชีวิตของนักพัฒนาทั่วไปก็จะง่ายขึ้นเล็กน้อย

9. การเข้าร่วมการชุมนุมต่างๆ

นักพัฒนาใช้เวลาส่วนใหญ่ในการประชุม การเจรจา และการวางแผนต่างๆ ตัวอย่างที่ง่ายที่สุดคือ “การประชุมรายวัน” (การประชุมรายวัน) ซึ่งคุณต้องบอกว่าคุณทำอะไรเมื่อวานและคุณกำลังทำอะไรในวันนี้ นอกจากนี้ คุณต้องมีการโทรแบบตัวต่อตัว เช่น กับผู้เชี่ยวชาญ QA เพื่อให้เขาสามารถแสดง/อธิบายความแตกต่างของการสร้างข้อบกพร่องซ้ำ หรือหารือเกี่ยวกับความแตกต่างและข้อกำหนดกับนักวิเคราะห์ธุรกิจ หรือองค์กร ปัญหาเกี่ยวกับ PM ดังนั้นแม้ว่านักพัฒนาซอฟต์แวร์อาจเป็นคนเก็บตัวที่ชอบสันโดษ แต่เขาก็ยังต้องสามารถค้นหาภาษากลางกับคนอื่นได้ (อย่างน้อยก็นิดหน่อย) ยิ่งตำแหน่งนักพัฒนาซอฟต์แวร์สูงเท่าไร เขาก็ยิ่งต้องใช้เวลาในการสื่อสารมากขึ้นและใช้เวลาในการเขียนโค้ดน้อยลง หัวหน้าทีมนักพัฒนาอาจใช้เวลาทำงานเพียงครึ่งเดียวหรือมากกว่านั้นในการสนทนา การประชุม และเขียนโค้ดให้น้อยลง (ซึ่งอาจนำไปสู่การสูญเสียการควบคุมเล็กน้อย) แต่ถ้าคุณเป็นคนที่ชอบพูดคุยด้วย ก็สามารถพัฒนาจากตำแหน่งหัวหน้าทีมไปสู่ฝ่ายบริหารได้อย่างง่ายดาย และลืมเรื่องโค้ดไปเลย สื่อสารกับทีม ลูกค้า และผู้จัดการอื่นๆ ตลอดทั้งวัน

10. ดำเนินการ/ผ่านการสัมภาษณ์

หากคุณทำงานให้กับบริษัทเอาท์ซอร์สหรือจ้างพนักงานภายนอก คุณจะต้องผ่านการสัมภาษณ์ภายนอกบ่อยครั้ง เมื่อคุณต้องการ "ขาย" ให้กับลูกค้า (จากนั้นคุณสามารถถูกสัมภาษณ์โดยบุคคลจากฝั่งลูกค้า) และการสัมภาษณ์ภายในเพื่อ เพิ่มอันดับของคุณภายในบริษัท ฉันจะเรียกสิ่งนี้ว่าเป็นปัจจัยที่ดีสำหรับการพัฒนา เนื่องจากเนื่องจากมีการสัมภาษณ์บ่อยครั้ง ความรู้ของคุณควรเป็นรูปเป็นร่างอยู่เสมอ: คุณจะไม่รู้สึกอึดอัดและผ่อนคลาย เพราะถ้าคุณผ่อนคลายในด้านไอที คุณก็จะสามารถบินออกจากสนามได้อย่างสมบูรณ์ เมื่อคุณเป็น Developer ที่มีประสบการณ์มากขึ้น คุณจะสามารถเยี่ยมชมอีกด้านได้ ไม่ผ่าน แต่สัมภาษณ์งาน เชื่อฉันเถอะว่าถ้ามองจากมุมนี้คุณจะต้องแปลกใจมากเพราะการสัมภาษณ์น่ากลัวกว่าการผ่าน คุณต้องมีกลยุทธ์การสัมภาษณ์ รายการคำถาม และมีเวลาถามคำถามในหัวข้อที่จำเป็นทั้งหมดภายในหนึ่งชั่วโมง และหลังจากนั้น คุณจะต้องรับผิดชอบต่อผลตอบรับ เนื่องจากบุคคลนั้นอาจหรืออาจจะไม่ได้รับข้อเสนอหรือการส่งเสริมการขายที่รอคอยมานานก็ตาม โดยอาศัยผลตอบรับดังกล่าว และในทางกลับกัน: คุณสามารถพลาดผู้สมัครที่อ่อนแอตรงไปตรงมาในตำแหน่งที่เขาไม่สอดคล้องกัน แล้วคุณอาจถูกถาม: คุณคิดถึงเขาด้วยความรู้ระดับนี้ได้อย่างไร? ดังนั้น เมื่อต้องผ่านการสัมภาษณ์ โปรดจำไว้ว่าคนที่อยู่ตรงข้ามคุณก็กำลังมีช่วงเวลาที่ยากลำบากเช่นกัน และเขาอาจจะกำลังประสบกับความเครียดด้วย การสัมภาษณ์ใดๆ ก็ตามสร้างความตึงเครียดให้กับทั้งผู้สมัครและผู้สัมภาษณ์ บางทีเราจะจบลงที่นี่ ขอบคุณทุกคนที่อ่านจบ : กดไลค์และเรียนรู้ Java ครับ ^^