את הפוסט הפעם החלטתי לכתוב, אחרי שבמספר פגישות הכוונה שערכתי לאחרונה, חזר על עצמו המצב הבא:

מועמדים, שרוצים להפוך לדאטה אנליסט – ניגשים לראיונות עבודה אחד אחרי השני – אבל פשוט לא מצליחים לעבור אותם.

 

רובם אפילו עברו קורס דאטה אנליסט, שלכאורה היה אמור ללמד אותם את הכלים הרלוונטיים (בעיקר SQL); 

ועדיין – משהו עדיין לא עובד.

 

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

 

אז איפה בדיוק הבעיה?

 

כמעט בכל מקרה כזה שבו אני נתקל הדבר הראשון שאני עושה הוא להעריך את רמת ה-SQL שלהם, כי מנסיוני כמעט תמיד שם הבעיה.

אבל בעוד שהרבה מכם חושבים עכשיו שצריך ללמוד עוד SQL, אז רגע, חכו.

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

 

כן – יש כאן מימד אחר לחלוטין מסתם ללמוד את הפקודות הטכניות של SQL:

חשיבה אנליטית – איך לגשת לבעיות עסקיות ולפתור אותן באמצעות SQL.

 

בעוד שרוב המועמדים לומדים SQL מאנשי BI (מגיע מעולם פיתוח התוכנה), מעסיקים ברוב המקרים מחפשים דווקא צורת חשיבה אחרת – יותר עסקית, יותר לוגית.

במילים אחרות:

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

 

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

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

 

אז נחשו מה? שאלות פחות מוגדרות זה בדיוק סוג השאלות שאוהבים לשאול ברוב הראיונות לתפקידי דאטה אנליסט…

 

 

איך זה בדיוק בא לידי ביטוי? יש דוגמאות?

 

אז הנה בדיוק דוגמה להבדל בין "חשיבת BI" לחשיבה של דאטה אנליסט.

 

נניח שיש לנו 2 טבלאות מקור:

א.     Users – משתמשים באפליקציה מסוימת (ברמת מזהה משתמש, מועד רישום לאפליקציה ועוד).

ב.     Purchases – רכישות (ברמת רכישה, הכוללת בין השאר את מזהה המשתמש, תאריך רכישה וכיו"ב).

 

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

 

איך איש BI יפתור את הבעיה הזו?

 

קודם כל, הוא יבין שיש כאן יחס, כלומר – צריך לחשב מונה ומכנה.

אבל מאחר והוא רגיל לפתור בעיות יחסית מוגדרות ופשוטות, הוא יריץ 2 שאילתות נפרדות – אחת למונה והשניה למכנה, ופשוט יחלק את התוצאות.

SELECT
(SELECT COUNT(DISTINCT userId) FROM Purchases) / (SELECT COUNT(DISTINCT userId) FROM Users)

  

הפתרון הזה כמובן נכון ולגיטימי, 

הבעיה היא שהוא קצת פשטני מדי.

הוא לא נותן לנו את היכולת לצלול פנימה לנתונים, ולהבין האם ישנן טעויות או פערי מידע;

הוא אפילו האם החישוב הוא נכון, אלא פשוט מניח שהנוסחה נכונה וגם המרכיבים שלה נכונים. 

 

וזה לא תמיד המצב…

 

 

ומה דאטה אנליסט יעשה?

 

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

 

תחילה, הוא יבין שיש כאן 2 טבלאות עם שדה משותף, מה שאומר שנרצה לבדוק ברמת המיקרו שכל משתמש שביצע רכישה – גם מופיע בטבלת המשתמשים.

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

 

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

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

 

 

אז לסיכום:

 

צורת חשיבה אנליטית היא לראייתי אחד הנכסים הכי חשובים שיש לדאטה אנליסט.

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

ולצערי, בצורת החשיבה הזו לא ממש מתמקדים בהרבה קורסים בשוק.

 

אז אני מקווה שהפוסט הצליח לתת טעימה ממה הכוונה בצורת החשיבה האנליטית.

ואם מעניין אתכם להיחשף קצת יותר לצורת החשיבה הזו (כולל המחשה ברמת קוד SQL), ואפילו להכיר 3 דרכים לפיתוח שלה – 

תוכלו לעשות זאת עם סדנת 'הנתיב המהיר' של 'מועדון הנתונים'.

 

בהצלחה בראיונות!

 

 

מוכנים לשלב הבא בדרך להיות אנליסטים? בדקו את סדנת 'הנתיב המהיר'!

 

 

 

Share
השארת תגובה