האם התואר באמת לא משנה אחרי המשרה הראשונה?

htechstud

New member
האם התואר באמת לא משנה אחרי המשרה הראשונה?

שמעתי המון פעמים שאנשים אומרים שהתואר לא משנה אחרי המשרה הראשונה. זה נכון?

עוד שאלה טיפה דומה,
נניח יש 2 אנשים, אחד בוגר הטכניון במדמ"ח עם ציון 90, והשני עם ציון 70. ונניח שהם זהים ביכולות שלהם כמפתחי תוכנה. שניהם הולכים לעבוד באותו תפקיד, והעבודה היום-יומית זהה, כמפתחי c++. האם לאחר 3 שנים, כששניהם יחפשו עבודה חדשה, האיש עם ציון 90 יחשב אטרקטיבי יותר מהאיש עם ציון 70 או ששניהם יהיו בעצם על אותה מדרגה מכיוון שהמעסיקים לא מסתכלים על הציון בתואר אחרי כמות X של שנות ניסיון?
 

ipv6

Member
זה לחלוטין תלוי מעסיק

יש מעסיקים שגם עם 20 שנה של ניסיון יסתכלו על הממוצע שלך כי זה מדד ליכולות יש כאלה שכבר בעבודה השניה לא ישאלו, אם תחליט לציין לבד זה כן עלול להשפיע במידה מסוימת.

ההבדל בשווי בין בוגר טרי עם 70 ובוגר וטרי עם 90 הוא משמעותי וזה בד"כ ישפיע על העבודה הראשונה שתשפיע על הבאות אחריה, ככה שכשניהם יהיו עם 10 שנות ניסיון, סביר שהזה עם ה90 יהיה בעל רזומה טוב יותר (יעבוד בחברות טובות יותר בתפקידים טובים יותר) ויהיה אטרקטיבי בעיקר בגלל זה ולא בגלל הממוצע.

עיקר המשקל ניתן לראיונות עצמם בד"כ והממוצע ישפיע בעיקר על ההזמנה לראיון, אבל כאמור יש מקומות שישקללו הכל ביחד.
 

vinney

Well-known member
כן ולא

יש מעסיקים שתמיד מסתכלים על ציוני התואר, אבל גם בלי לקחת אותם בחשבון זה עדיין יכול להיות משמעותי בתור גורם שובר שוויון.
&nbsp
יחד עם זאת קח בחשבון שהמשרה הראשונה לבוגר מצטיין כנראה תהיה ברמה גבוהה יותר מהמשרה הראשונה של הבוגר עם 70, והפער הזה כן ישנה, וימשיך להשתמר במידה כזאת או אחרת לאורך כל הקריירה.
 
לא "הציון בתעודה" משנה, אלא מה שמאחוריו

בדרך כלל אחרי שלוש שנים לא מסתכלים על התעודה, אלא על מה עשית בשלוש שנים האלה.

אבל יש איזה מתאם בין הציון, לבין היכולת של הבן אדם. ולכן, אם סיימת עם 70 - ככל הנראה - אתה תתקדם בעבודה פחות מזה שסיים עם 90. כי כמו שהוא תלמיד יותר טוב, יש סיכוי שהוא יהיה עובד יותר טוב.
לא בטוח, ברור. בטח יש אלה שהיו תלמידים לא משהו, ואחרכך התגלו כעילויים.

אגב - העבודה היוםיומית היא לא זהה. גם אם לשניהם כתוב אותו דבר בהגדרת תפקיד. בכל צוות יש כמה אנשים, המנהל לומד להכיר את העובדים, ומחלק את המשימות בהתאם.
 

htechstud

New member
הבהרת השאלה

כן ברור לי שהתלמיד היותר טוב כנראה יהיה עובד יותר טוב ויתקדם יותר מהר, חוץ מבמקרים קיצוניים. אבל המקרה שנתתי הוא היפותטי לגמרי, כלומר נניח ששניהם התעסקו ועבדו במשך שלוש שנים ושניהם היו באותה רמת עבודה והכל אותו דבר. (אפשר לומר שאולי שהאיש עם הממוצע 70 היה לא טוב במתמטיקה אבל תותח בתכנות ובגלל מתמטיקות הציון שלו נמוך, והשני עם ה90 תותח גם במתמטיקה. כמובן שזה סתם, באופן היפותטי לגמרי.)
&nbsp
ותודה רבה על התשובות המהירות!
 

choo

Active member
קח בחשבון שככל שהעולם גדל - למתמטיקה תפקיד הולך וגדל בתיכנות

&nbsp
יש בשוק שתי מגמות סותרות. מצד אחד, עקב ריבוי ספריות צד ג (בעיקר כאלו בקוד פתוח), בפיתוח תוכנה הרבה תפקידי פיתוח התחלפו בתפקידי "הדבקת דבק". בתפקידים הללו המפתחים בעיקר עוסקים בלימוד אינטנסיבי של ממשקי ספריות צד ג, ובשימוש בהן בתוך המוצרים שלהן. בתפקידים הללו, הצורך בהבנה מתמטית ירד לעומת העבר - כי מישהו אחר עשה את העבודה הזו.
&nbsp
מצד שני, בתחום פיתוח תשתיות (וזה כולל גם מערכות תשתית, וגם פיתוח של אותן ספריות צד ג המוזכרות למעלה), המערכות צריכות לטפל בנפחים הולכים וגדלים של נתונים, מה שדורש הגברה של התיחכום המתמטי של מפתחי תוכנה, כדי להתמודד עם עומס הנתונים. בתפקידים הללו, תותח מתמטי ישתמש בידע המתמטי שלו כדי לייעל את העבודה, או את המוצר, או את שניהם, ויזכה לייתרון מהותי על מי שהתעלם מהמתמטיקה.
&nbsp
המצב ההיפותטי שהעלת כמעט שלא יוכל להתקיים במשרות מהסוג השני. במשרות מהסוג הראשון - קיים סיכוי מסויים, אבל שים לב שבמשרות דבק לרוב לא מפתחים ב-++C, אלא בשפות גבוהות יותר (כמו פייתון, רובי, לפעמים גם ג'אווה במערכות ותיקות)
 

eveik

New member
יכלת גם לטעון את זה בעבר לגבי ניהול זכרון, לא?

שבעתיד האפליקציות יהיו גדולות יותר והמורכבות והחשיבות של ניהול הזכרון תלך ותגדל.
&nbsp
אני מניח שאפשר לחשוב על עוד כמה דוגמאות, הנקודה שלי היא שבפועל ההנחה נכונה (אפליקציות גדולות יותר / יותר דאטה לנהל) אבל התוצר הוא לא שאנשים יצטרכו להמציא את הגלגל בעצמם אלא שיהיו להם תשתיות שיספקו את מה שהם צריכים. היחס בין כמות האנשים שמפתחים את התשתיות האלו לבין האנשים שעובדים מעל התשתיות הוא לא 1:1.
 

choo

Active member
אני לא מדבר על העתיד - אלא על ההווה לעומת העבר

&nbsp
בתור אדם שנמצא בתחום התשתיות, אני רואה את הגידול המהותי במורכבות האלגוריתמית של תוכנות התשתית, שמגיע בגלל הגידול בכמות הנתונים המנוהלת.
&nbsp
לגבי הגידול בכמות הזכרון - מצד אחד זה מאפשר לחשוב הרבסה פחות על כיצד לנהל אותו. מצד שני, כשמבני הנתונים בזכרון גדלים, אתה צריך לנהל אותם בצורה יעילה כדי להגיע לזמני גישה סבירים לנתונים בודדים מבין המיליונים שאתה מתחזק. אז נכון שכיום אתה נוטה פשוט להשתמש במבני נתונים שמישהו אחר פיתח עבורך, אבל אתה עדיין צריך לחשוב איזה מבנה מתאים לאיזו מטרה - וזה אומר הבנה של מבני נתונים וסיבוכיות, ולא רק "לדעת לכתוב קוד".
&nbsp
כמו ש"אמרתי" - בתחום "תיכנות הדבק" המצב הוא הפוך במידה מסויימת. ולא טענתי שיחס המישרות הוא 1:1. שאלתי את הכותב המקורי איפה הוא רוצה להיות. כשהוא כותב על פיתוח ב-++C, נשמע שהוא מכוון יותר לכיוון של תשתיות (או מערכות משובצות), מאשר ל"תיכנות דבק" - או שהוא רשם את שם השפה בלי לחשוב על מה שעושים איתה בשוק בפועל.
 

ipv6

Member
לדעת סיבוכיות של מבני נתונים

זה לחלוטין נופל תחת הגדרה של "לדעת לכתוב קוד",כנ"ל לדעת איך המבנה ממומש (למשל רציף בזכרון מול לא רציף בזכרון). לפחות כשכותבים ב-C++ ומתעניינים בביצועים, חובה לדעת מה קורה 'מתחת לרגליים' גם מבחינת חתימה הזכרון של האובייקט. גם הרפרנס של הספריה הסטנדטית מציין סיבוכיות של כל מתודה, לפחות עבור האובייקטים הפופולאריים - מהסיבה שמבינים שזה בסיסי.

כתבת שלדעתך לתותח מתמטי יש יתרון מהותי מעצם הידע שלו, אני לא יודע איפה אתה מעביר הקו בין משימה שמבחינתך דורשת ידע באלגוריתמים\מבני נתונים לבין משימה שדורשת רק 'לדעת לכתוב קוד', אני חושב שגם בתחום התשתית כשהמוצר בשל מספיק, רב המשימות הופכות למשימות 'לדעת לכתוב קוד' ולאדם שנורא חזק באלגוריתמים מבני נתונים אין יתרון מובהק מעצם הידע העמוק, אלא רק מעצם היכולות שלו. על אחת כמה כמה כשזה מגיע לקורסים מתמטיים עוד פחות פרקטיים (אינפי כדומה).
מבחינתי גם לעשות מידול של בעיה לכשהיא לגרף ולפתור אותה בעזרת אלגוריתם בסיסי בתורת הגרפים (BFS, דייקסטרה) -זו לא איזו משימה תיאורטית ש'לתותח מתמטי' יהיה יתרון מובהק בה. יצא לי באופן אישי לעשות את זה.


בשלבים התחלתיים מאד כשמאפיינים מבנה נתונים מיוחד proprietary או כל דבר שהוא המצאה מחדש של הגלגל, הידע התיאורטי באמת נדרש.
https://www.youtube.com/watch?v=ncHmEUmJZf4
זאת למשל דוגמא למשימה לא סטנדנרטית, שידע \ יכולת במבני נתונים עשוי לתת בה edge.

(ממליץ לראות את הוידאו, מעניין)
 

choo

Active member
דמיין מערכת שצריכה לנהל פטה-בייטים של נתונים

&nbsp
ולאפשר גישה יעילה לכל נתון במילי שניות ומטה. וזה מתוך צביר מחשבים גדול (כדי לעמוד בדרישות ביצועים כלל-מערכתיות).
&nbsp
ולאפשר לשמור גרסאות ישנות של כל האובייקטים מבלי לדרוש עודפי שטח, ומבלי לפגוע בביצועים
&nbsp
וכיוצא בזה.
&nbsp
דוגמא לשאלה של לקוח: כמה מקום תפוס יש בתת-עץ מסויים של מבנה הנתונים? נא לתת תשובה עכשיו, לא בעוד כמה דקות. ונא לדאוג שזה לא ישפיע על הביצועים.
&nbsp
בתחום איחסון הנתונים, אלו הגדלים שבהן עוסקות המערכות לאחרונה, ולכן הגלגל הקודם (שהתאים למידות מערכת קטנות יותר) כבר לא מתאים, וצריך גלגל חדש.
&nbsp
אפילו תחום בסיסי כמו RAID, שהיה מאוד יציב ומקובע במשך הרבה שנים, מתחיל לעבור שינויים מתמטיים (וכל הטבלאות שבבסיסו מתוארות במושגים מתורת השדות, כך שמי שרוצה לעסוק בשיפור של זה, צריך להבין את המתמטיקה, כדי להתאים אותה לדרישות המערכת ולממש אותה).
&nbsp
אגב, השיטה המקובלת בעבר להציג את נפחי הנתונים היתה לעקוב אחריהם בצורה מדוייקת. בנפחי המערכות כיום זה לא מעשי, ועברו לשיטות סטטיסטיות. והבעיה בשיטות סטטיסטיות היא שקל לבצע טעויות בצורה שבה בוחרים דגימות, והיכולת לבצע חישובים סטטיסטיים נכונים עם מרחב מדגם נכון, היא ההבדל בין קוד שבאמת עובד, לקוד שלפעמים מציג תוצאות לגמרי לא הגיוניות.
&nbsp
לגבי אותם "שלבים התחלתיים" - אני נמצא בחברה בת שלוש+, ועדיין צריך כל הזמן להכניס מבני נתונים חדשים, כדי לתמוך בתכונות חדשות, ובגלל דרישות הגודל מצד אחד, הסקיילאביליות מצד שני, והביצועים מצד שלישי, והפונקציונאליות מצד רביעי, והשינויים הארכיטקטוניים המערכתיים מצד חמישי - אי אפשר להשתמש פשוט בגלגל שהתאים ב"דור הקודם" (5 שנים אחורה).
 

choo

Active member
אני? מה פתאום. אני בתחום של תמיכה נפשית בפורומים ;)

 

jellymean

New member


 

bismark1

New member
ופעם זה לא היה ככה?

ככלל, מי שעובד על מערכת מורכבת/לא טריוויאלית צריך ידע מעמיק. זה נכון היום וזה היה נכון גם לפני שנים. גם פעם היו מתכנתים שמעתיקים קטעי HTML, קריאות COM (אפרופו "העתק-הדבק" ב-++C) או עושים דאבל קליק על כפתור בדיזיינר אוטומטי של VB בלי להבין מה הם עושים. לא חושב שבאופן מהותי יש שינוי אדיר באופי התעסוקה.
 

choo

Active member
פעם, היה פחות צורך ביעילות מתמטית, כי היו הרבה פחות נתונים

&nbsp
שוב, אני מסתכל מפרספקטיבה של כ-15 שנה (ועוד קצת ידע הסטורי מהספרות ולא מנסיון אישי) בתחום של מערכות איחסון נתונים - רמת המתמטיקה שמשמשת לפיתוח המערכות הללו עולה עם השנים, כדי להתמודד עם הגידול בכמות הנתונים.
&nbsp
אם בחברה הקודמת היה שימוש חזק במתמטיקה קיימת והדגש היה על אירגון הנתונים, בחברה הנוכחית חלק מהקוד נכתב על בסיס מאמרים אקדמיים, ללא קוד מוכן להשתמש בו. ובחברה שלפני הקודמת? אירגון הנתונים היה הרבה פחות יעיל, כי ממילא סבלת מהאיטיות של דיסקים קשיחים בכל פעולה. המדיה שנעשתה מהירה משמעותית לכל פעולה, חייבה אותך לשפר את יעילות הקוד ומבני הנתונים שאתה שומר בזכרון, כדי לא להפוך לצוואר בקבוק.
 

bismark1

New member
יש משפט שאומר שככל שהחומרה משתכללת ונהיית זולה

כך התוכנה מתרחבת בהתאם בשביל לחנוק את המשאבים הקיימים - אז נכון שאולי בתת תחום שלך התעשיה נמצאת בנקודה בסייקל שמצריכה יותר תחכום מתמטי/הבנה מעמיקה בשביל להתמודד עם דרישות לנוכח המגבלות של החומרה/תשתית אבל באותה מידה אפשר לחשוב על דוגמאות הפוכות - תסתכל מה קרה לדוגמא לכל התחום של ראייה ממוחשבת כשכוח החישוב הפך זול.
 

choo

Active member
התוצאה היתה עליה בתיחכום המתמטי

&nbsp
יש לך כיום משרות בפיתוח תוכנה בתחום של בינה מלאכותית (ראייה ממוחשבת היא תת-תחום של זה) שבעבר לא ניתן היה לממש בצורה אפקטיבית, ולכן אתה נתקל ביותר דרישה לבוגרי תארים מתקדמים בתחומים הללו מאשר בעבר.
&nbsp
זה בדיוק מצב שבו יכולות המיחשוב הגבוהות יותר פותחות את הדרך לתוכנה מתוחכמת יותר, בהקשר המתמטי שלה. מי שמפתחים את התשתיות בעולם הזה, נדרשים להבנה מתמטית ואלגוריתמית טובה למדי. אם אתה עוסק בתחום ה"דבק" מעל זה - מצבך אחר.
 

bismark1

New member
לגמרי הפוך

רצה המקרה וזה גם התחום שבו אני עוסק ב-15 שנה האחרונות. הדרישה המוגברת היא פועל יוצא של ההתרחבות של השוק שהקטליזטור העיקרי שלו היה הוזלה של כוח החישוב - מבחינת מי שעוסק בתחום האפליקטיבי זה אומר שאת התחכום המתמטי אפשר לשמור לפעולות ברמה יותר גבוהה (נגמרו הימים שהיית צריך לממש הפיכת מטריצות בעצמך עם קירובים בשביל לחסוך כמה מילי-שניות או לחשוב אם הקונבולוציה ספרבילית או לא). גם ברמת התשתית הרבה פעולות שהיו קשות בעבר יותר קלות היום בגלל ההבשלה של הכלים ואת התחכום המתמטי שומרים לפעולות ברמה גבוהה יותר. הדבר היחיד שהשתנה זה שיכולות שפעם נחשבו קשות/ לא טריוויאלית היום אפשר לקבל בקריאה פשוטה ל-API, כלומר ההגדרה למה נחשב "מורכב" ומצריך הבנה מעמיקה פשוט משתנה עם הזמן.
 

choo

Active member
התייחסתי לחלק של הבינה המלאכותית (מה שמכנים "למידה עמוקה")

המתמטיקה של רשתות נוירוניות קיימת כבר משנות ה-80 לפחות - אלא שלא היתה טכנולוגיה הנדסית שאיפשרה לממש רשתות עם הרבה נוירונים, שלא לדבר על הרבה שכבות ברשת.

בגלל שהיום כוח העיבוד מאפשר את זה - נפתח תחום שלם שמעסיק אנשים בפיתוח אפליקציות של "בינה מלאכותית" מעל לספריות תשתית חדשות, שמממשות את אותן רשתות נוירונים. פיתוח התוכנה בהקשר הזה נוטה להראות שונה מפיתוח תוכנה מסורתי - ודורש הבנה של המודל המתמטי שבבסיס הרשתות הנוירוניות, כדי לדעת כיצד לכוונן אותן בצורה יעילה, ולא על ידי ניחוש וטעיה בלבד. לזה התכוונתי.

לגבי העובדה שלא צריך לפתח כל פעם מחדש את הפעולות המתמטיות מהסוג שהזכרת - עם זה אני בהחלט מסכים (כמובן שעדיין מישהו צריך לפתח את אותן ספריות - אבל הוא תוכניתן תשתית, ולא תוכניתן דבק).
 

bismark1

New member
אנחנו מתייחסים לדברים שונים

ברמת המתמטיקה נטו - רשתות נוירונים לא יותר מורכבות מטכניקות אחרות אלא פשוט יותר מוצלחות כרגע במשימות ספציפיות - אם תסתכל על מאמר זיהוי פנים מאתמול ותשווה אותו למאמר באותו נושא מלפני עשר שנים לא תמצא עלייה במורכבות המתמטית לאורך הזמן (במובנים מסויימים אפילו להפך). ברמה הפרקטית - גם לפני עשר שנים, אם היית מפתח שרוצה להשתמש באלגוריתם לומד "פשוט" כמו SVM לטובת האפליקציה שלך היית צריך להבין מה הולך שם בשביל להשיג תוצאות טובות. דווקא היום בגלל שיש פתרונות "כלליים" מספיק טובים לחלק מהמשימות יותר אנשים יכולים להשתמש ברשתות בתור מוצר מדף.
 
למעלה