Въпроси за интервю за SQL и Python в рекламните технологии: пълно ръководство

Информатек Дигитал » Ресурси » Въпроси за интервю за SQL и Python в рекламните технологии: пълно ръководство

Ако се подготвяте за интервю в областта на рекламните технологии , дигиталния анализ или анализа на данни , рано или късно ще се наложи да се изправите пред ужасния технически тест. Именно там компаниите проверяват дали наистина владеете това, което сте посочили в автобиографията си: SQL за извличане на данни, Python за обработката и анализа им и някои умения за аналитично мислене, за да не се изгубите сред всички таблици и скриптове.

Добрата новина е, че техническите интервюта не са магия: те обикновено се въртят около едни и същи блокове от SQL, Python и оценка на модели . Ако разбирате добре основите, практикувате с реални упражнения и се научите да обяснявате разсъжденията си, ще имате значително предимство пред другите кандидати.

Защо техническите интервюта са плашещи (и как да се справите с тях)

В ролите на анализатори на данни или продуктови специалисти в рекламните технологии, техническите интервюта обикновено комбинират концептуални въпроси с практически упражнения на живо . Може да бъдете помолени да обясните функцията на SQL клауза или да решите бизнес казус, включващ данни от програмни рекламни кампании.

Обикновено ще бъдете оценявани по три направления: SQL на средно ниво (JOIN, GROUP BY, подзаявки, прозоречни функции), Python, ориентиран към данни (pandas, почистване, агрегации, сливания) и способността ви да интерпретирате резултати и да съобщавате открития . Те не търсят старши специалист по данни, а по-скоро някой, който може да работи с данни по стабилен и надежден начин.

Типичната грешка, която много кандидати правят, е да се фокусират върху запомнянето на синтаксиса и да забравят да изпълняват пълни упражнения , подобни на тези, с които ще се сблъскате в платформи като HackerRank, StrataScratch или вътрешните тестове на самите компании. Вашата цел трябва да бъде да стигнете до интервюто, след като вече сте решили десетки много подобни заявки и скриптове.

Ниво на SQL, обикновено изисквано при интервюта за работа в рекламни технологии и анализатори на данни

За позиция на анализатор в рекламни технологии или дигитални маркетингови среди, компаниите очакват да владеете класическия релационен SQL : извличане на данни от множество таблици, комбиниране, групиране, филтриране и създаване на полезни показатели. Те няма да изискват умения за администриране на бази данни, но би трябвало да сте уверени в работата със средно сложни заявки.

Обикновено тестът ще включва заявки, които комбинират INNER JOIN, LEFT JOIN, филтри с клаузи WHERE, агрегации с GROUP BY и някои условия върху агрегати, използващи клаузи HAVING. Оттам нататък, в малко по-напреднали позиции, е много често срещано да се видят подзаявки и прозоречни функции за класиране, кумулативни суми и сравнения на редове.

В рекламните технологии вероятно ще отговаряте на бизнес въпроси като „Кои кампании имат по-добър CTR от средния за съответната индустрия?“ или „Кои издатели губят импресии в сравнение с миналия месец?“. Ефективното решаване на тези въпроси обикновено изисква основно разбиране на свързаните подзаявки и функциите за прозорци.

Основни SQL въпроси, които често се появяват (и как да им отговорите)

Почти всяко техническо интервю, ориентирано към данни, включва набор от основни въпроси по SQL теория . Те не се опитват да ви хванат накриво, а по-скоро да се уверят, че имате солидна основа.

Един от най-често задаваните въпроси е разликата между WHERE и HAVING . Най-ясният начин да се обясни е, че WHERE филтрира отделни редове преди групиране , докато HAVING филтрира групи, които вече са агрегирани . Можете също да споменете, че условията, включващи функции за агрегиране (COUNT, SUM, AVG и др.), трябва да се поставят в HAVING, а не в WHERE.

Друг класически въпрос е какви видове JOIN съществуват и кога да се използва всеки един от тях: INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN и в някои случаи CROSS JOIN или self-join. В анализа на данни LEFT JOIN се използва широко, когато искате да запазите целия първичен набор от данни (например всички потребители), дори ако няма свързани записи във вторичната таблица (например покупки).

Примери за основни SQL заявки и тяхната логика

За да добиете представа за „минимално разумното“ ниво, би трябвало да можете да пишете заявки от паметта, като например избиране на конкретни колони, филтриране на редове и сортиране на резултати . На много основно ниво, типичните въпроси включват: как да се извлекат всички колони от таблица, как да се изберат само някои колони или как да се прилагат четливи псевдоними с AS.

Често срещано е също така да ви питат за клаузата WHERE с множество условия, комбиниращи AND, OR и NOT, или как да използвате оператори за сравнение (<, <=, >, >=, =) както за числови стойности, така и за дати. Много компании наблягат на NULL филтрите , където простото използване на знака за равенство не е достатъчно; трябва да използвате IS NULL или IS NOT NULL.

Друг класически метод е текстово филтриране с LIKE и шаблони, използващи заместващите символи % и _. Например, можете да намерите кампании, чиито имена съдържат конкретна дума, или потребители, чиито имейл адреси завършват на определен домейн. Важно е да се обясни, че LIKE '%text%' търси шаблона навсякъде в низа.

Накрая, този основен раздел обикновено обхваща как да се актуализират записи с UPDATE и да се филтрират редовете, които са променени с WHERE, както и как да се изтриват редове с DELETE FROM, използвайки clear условия. Изключително важно е винаги да подчертавате важността на използването на специфична клауза WHERE, за да избегнете случайно изтриване на половината таблица.

Междинни заявки: GROUP BY, HAVING, подзаявки и UNION

След като преминете отвъд младшото ниво, почти всяка компания започва да цени вашето майсторство на комбинацията от GROUP BY, агрегиращи функции и филтри върху агрегати с HAVING . Това е, което ще използвате ежедневно, за да генерирате отчети за ефективността на кампании, аудитории и рекламни послания.

Работи по следния начин: GROUP BY групира редове по една или повече колони и можете да приложите SUM, COUNT, AVG, MIN и MAX към тези групи , за да изчислите показатели. HAVING идва след това, за да запази само групите, които отговарят на условие, например клиенти с продажби над определен праг.

Друга повтаряща се тема са подзаявките : заявка в друга заявка. Те често се използват за филтриране по стойности, изчислени в предишна стъпка, като например избиране на клиенти с продажби над средното за света или кампании с импресии над 90-ия персентил.

Често ви питат и за разликата между UNION и UNION ALL . UNION комбинира два резултатни набора с една и съща схема и премахва дубликати; UNION ALL прави същото, но запазва всички редове, дори и да се повтарят. При анализа на данни често ще предпочитате UNION ALL поради причини, свързани с производителността, и защото искате да запазите всички оригинални записи.

Функции за прозорци: следващият скок в SQL

Функциите на прозорците са се превърнали в стандарт в техническото тестване на определено ниво, особено за роли, свързани с рекламните технологии, където е необходимо да се анализират тенденциите във времето, класирането на кампаниите или общите инвестиции.

Ключовата идея е, че функцията тип „прозорец“ изчислява стойност върху набор от редове, свързани с текущия ред , но без да свива резултата, както прави GROUP BY. С други думи, все още виждате всеки отделен ред, но придружен от агрегат, изчислен върху „прозорец“ от данни.

Типичният синтаксис е да се използва функцията (SUM, AVG, RANK и т.н.), последвана от OVER, като в OVER се дефинира дялът (PARTITION BY) и редът (ORDER BY). Например, изчисляване на класирането на продажбите по продавач или кумулативния брой импресии на ден.

Ако искате да демонстрирате умения, трябва да се запознаете с функции като RANK, DENSE_RANK, ROW_NUMBER, LAG и LEAD . Те са много полезни за класиране на кампании въз основа на тяхната ефективност, сравняване на всеки период с предишния или идентифициране на годишни вариации в ключови показатели.

CTE, кумулативни суми и пълзящи средни

В съвременните интервюта за работа четимостта на вашия SQL код е високо ценена. Ето защо често ще ви питат за Common Table Expressions (CTE) . CTE е по същество вид именувана временна таблица, дефинирана с клаузи WITH, която съществува само по време на изпълнението на заявката.

CTE се използват за разделяне на сложни заявки на логически блокове и повторно използване на междинни резултати. Например, първо изчислявате дневни показатели за всяка кампания в CTE, а след това, в основната заявка, извършвате допълнителни агрегации или филтриране на този резултат.

Друго много често срещано упражнение е изчисляването на текуща сума, използвайки SUM като функция на прозореца. В рекламните технологии е нормално да бъдете помолени за кумулативни импресии, кликвания или разходи, за да видите как се представя дадена кампания във времето.

С това са свързани пълзящите средни , при които AVG се прилага като прозорецова функция върху изместен ред (например, двете предишни дати и текущата). Това е прост начин за изглаждане на времеви серии и откриване на тенденции, без да се разчита толкова много на дневни пикове.

Ниво на Python, обикновено необходимо за анализатор на данни

В повечето роли на анализатори на данни (включително в рекламните технологии), компаниите не очакват да сте гуру на машинното обучение, но очакват да владеете практически Python с pandas . Обикновено ще бъдете помолени да зареждате набори от данни, да ги почиствате, да ги трансформирате и да получавате прости показатели или визуализации.

Тестовете на Python обикновено се фокусират върху операции като четене на данни от CSV файлове , проверка на null и типове колони, филтриране на редове, създаване на нови колони, агрегации с помощта на groupby и съединения между DataFrames. В много случаи формулировката е почти идентична с SQL частта, но във формат pandas.

Не е обичайно да се изисква от анализатор да изгражда сложни модели от нулата, въпреки че те може да оценят способността ви да се свържете със scikit-learn за обучение на основен модел и най-вече познанията ви за основните показатели за измерване на неговата производителност.

Основни операции с панди, които трябва да усвоите

За да завършите успешно всяко упражнение с данни на Python, трябва да владеете основни операции с DataFrames. Първата стъпка обикновено е да заредите файл, използвайки `read_csv` , и да изследвате неговата структура с методи като `head()`, `info()` или `describe()`.

Обикновено се появява и частта за почистване на нулеви стойности : преброяване на броя нули на колона с isnull().sum(), вземане на решение дали да се изтрият цели редове или колони с dropna() или да се попълнят липсващите с fillna(), например, използвайки средната стойност или медианата на колоната.

Що се отнася до филтрите, ще бъдете помолени да създадете условия върху числови или категорични колони, нещо като избиране на продажби над определена сума или редове, които отговарят на няколко условия, комбинирани с & и |. Ключът е да знаете как да пишете df без колебание.

Обяснението на `groupby` в pandas е почти винаги включено, тъй като е директен еквивалент на SQL `GROUP BY`. Групирате по една или повече колони и след това прилагате агрегации като `sum`, `mean`, `count` и т.н. Синтаксисът `groupby('column').agg()` е от съществено значение.

Свързва се и слива между DataFrames

Точно както овладяването на JOIN-овете е от съществено значение в SQL, овладяването на pd.merge е задължително в pandas . Компаниите ще искат да видят дали знаете как да свързвате набори от данни, които споделят ключ, например таблица с потребители с друга таблица със събития или покупки.

Функцията за сливане (merge) приема двата DataFrames, които ще бъдат съединени, ключовата колона (on) и типа на съединяване (how), който може да бъде „left“, „right“, „inner“ или „outer“, точно както в SQL. В анализа на данни, лявото съединяване се използва предимно за запазване на основния набор от данни и добавяне на атрибути или показатели от вторични таблици.

В интервю е добра идея да споменете подробности, като например какво се случва, когато има дублиращи се ключове от двете страни или как да се справите с конфликти на имена на колони със суфикси на параметри. Това показва по-високо ниво на зрялост.

Типични, по-теоретични въпроси по Python

Освен пандите, много интервюта включват кратък блок от общи въпроси за Python , за да се провери разбирането ви за езика. Това обикновено са кратки въпроси относно функции, памет, типове данни или малки части от синтаксиса.

Сред темите, които се появяват многократно, е автоматичното управление на паметта в Python, базирано на частен heap, до който потребителят няма директен достъп, и garbage collector, който е отговорен за освобождаването на обекти, които вече нямат референции.

Често срещано е също така да ви молят да сравните Python с Java , не за да обявите победител, а за да покажете, че разбирате разликите: Python е по-динамичен, с по-сбит синтаксис, идеален за прототипиране и наука за данни, докато Java е склонна да доминира в по-корпоративни и високопроизводителни екосистеми.

Други типични въпроси се въртят около ламбда изрази (анонимни функции за прости операции), процеси на pickl/unpickl за сериализиране на обекти в байтове и извличането им или разликата между списъци и кортежи, където първите са променливи и се дефинират с квадратни скоби, а вторите са непроменливи и се дефинират със скоби.

Още ключови концепции на Python в интервютата

Често се случва да ви питат как да изтриете или копирате обект в Python. Обикновено е достатъчно да обясните, че можете да използвате командата `del`, за да премахнете препратка, и че плитките копия се извършват с `copy.copy()`, докато дълбоките копия изискват `copy.deepcopy()`.

Друга концепция, която може да се появи, особено в повече backend профили, е така нареченият ефект на dogpile , който описва сценария, при който много потребители или процеси атакуват ресурс (например уебсайт или кеш) едновременно, насищайки системата.

Във връзка с екосистемата, може да срещнете и въпроси относно бази данни, които могат да се използват с Python . Най-разумният подход е да споменете някои популярни като MySQL, PostgreSQL, SQLite, MongoDB и Oracle и да отбележите, че Python като цяло се интегрира добре с голямо разнообразие от релационни и NoSQL двигатели за бази данни.

Накрая, често възникват по-прости въпроси, като например как да се сортира речник, използвайки сортирани по елементи, какво е пространство от имена и за какво се използва (свързване на имена с обекти в различни области на видимост) или как да се стартира подпроцес, използвайки модула subprocess с функции като run() или Popen().

Метрики за оценка на модели в Python: минимумът, който трябва да знаете

Въпреки че много позиции на анализатори не изискват от вас да проектирате архитектури за дълбоко обучение, е обичайно да сте запознати с основните показатели за оценка на модели за класификация , особено ако ролята включва продукти с данни, атрибуция на кампании или откриване на измами в рекламните технологии.

Отправната точка е матрицата на объркването , която обобщава успехите и неуспехите на двоичен или многокласов класификатор. В двоичния случай тя се разделя на истински положителни (TP), истински отрицателни (TN), фалшиво положителни (FP) и фалшиво отрицателни (FN). Пълното разбиране на тези четири категории е ключово.

От матрицата се извеждат показатели като точност , която измерва процента на правилните прогнози от общия брой; прецизност (TP / положителни прогнози); и пълнота на отчитане или чувствителност (TP / действителни положителни резултати). Последните две са особено важни, когато класовете са небалансирани.

Резултатът F1 комбинира точност и припомняемост, използвайки хармоничната средна, като санкционира особено ниските резултати и за двете. Това е често срещан показател в сценарии, където както фалшиво положителните, така и фалшиво отрицателните резултати са скъпоструващи, като например откриване на измами, оценяване на потенциални клиенти или откриване на заболявания.

Други разширени показатели: ROC-AUC, logloss, Jaccard и други

За позиции със по-силен компонент за наука за данни или маркетингов анализ, компаниите обръщат внимание на това дали владеете по-напреднали показатели като ROC-AUC , която измерва площта под ROC кривата и отразява способността на модела да разделя класовете.

ROC кривата представлява връзката между процента на истински положителни резултати (повторимост) и процента на фалшиво положителни резултати (1 – специфичност) за различни прагове на вземане на решение. Случаен модел би попаднал на диагонална линия, докато добър модел би бил по-близо до горния ляв ъгъл. Колкото по-голяма е площта под кривата, толкова по-добра е дискриминационната способност.

Друга често срещана метрика е загубата на логаритъм (logloss) , която оценява качеството на прогнозираните вероятности, като силно наказва прекомерната самоувереност и грешките. Перфектният модел би имал загуба на логаритъм от 0 и като цяло, колкото по-ниска е загубата на логаритъм, толкова по-добре.

Може да ви попитат и за индекса на Жаккард , който измерва сходството между две множества като размера на пресечната точка, разделен на размера на обединението. Той се използва за оценка на класификатори, сегментиране и системи за препоръки, наред с други неща.

В някои контексти се споменават диаграми за печалба и покачване , които показват какъв процент от целевите групи обхващате, използвайки само част от популацията (например, първите 20% от потребителите, оценени от вашия модел). Това се използва широко в маркетинга, за да се реши към кого да се насочим първо.

Колмогоров-Смирнов, коефициент на Джини и задълбочена оценка

Ако компанията е силно фокусирана върху моделите за оценяване или риск, могат да се появят показатели като статистиката на Колмогоров-Смирнов (КС) , която измерва степента на разделяне между разпределенията на положителните и отрицателните резултати.

Стойност на KS, близка до 100 (като процент), показва, че моделът разделя двете популации почти перфектно; стойност, близка до 0, означава, че моделът не разграничава по-добре от случайност. На практика, моделите от реалния свят попадат в междинни стойности и се сравняват помежду си, за да се избере най-добрият.

Коефициентът на Джини е друг показател, извлечен от ROC-AUC, използвайки формулата Джини = 2 × AUC – 1. Много популярен в кредитирането и застраховането, той се интерпретира и като мярка за неравенство: колкото по-висок е Джини, толкова по-голяма е способността на модела да концентрира истински положителни стойности при по-високи резултати.

В по-напреднали интервюта може да бъдете помолени да обясните как тези показатели са имплементирани в Python, използвайки scikit-learn (напр. confusion_matrix, accuracy_score, roc_auc_score, f1_score…) и да коментирате кога бихте използвали всяка една от тях в зависимост от естеството на проблема и дисбаланса в класа.

Как да структурирате отговорите си по време на техническото интервю

Освен кода, който пишете, интервюиращите обръщат голямо внимание и на това как мислите и как се обяснявате . Лошо структурираният отговор може да ви накара да изглеждате по-младши, отколкото сте в действителност, дори ако знаете правилното решение.

Много полезен подход за отговаряне на технически въпроси е следният: първо, обяснете концепцията с едно изречение , след това дайте конкретен пример (в идеалния случай свързан с един от вашите собствени проекти) и, ако е уместно, споменете алтернативи или нюанси . Това работи еднакво добре за SQL, Python или показатели на модели.

Например, ако ви попитат за какво е CTE, бихте могли да кажете, че това е именувана временна подзаявка, която подобрява четимостта на сложни заявки, да добавите, че я използвате, когато трябва да използвате повторно междинен резултат няколко пъти, и да споменете, че в някои случаи може да бъде заменена от вложени подзаявки, въпреки че е по-малко ясно.

Мисленето на глас също е ключово . Ако се затрудните, не мълчете: кажете вербално какво се опитвате да направите, каква информация ви липсва, какви предположения правите. Това помага на интервюиращия да види вашия мисловен процес и понякога дори ви дава насоки или разяснения, които улесняват продължаването напред.

Най-често срещаните грешки в интервюта за технически данни

Много кандидати биват елиминирани не защото нямат достатъчни умения за SQL или Python, а поради комбинация от лоша подготовка и комуникационни грешки . Изключително важно е да сте напълно наясно с често срещаните капани, за да ги избегнете.

Първото е запомняне без разбиране . Познаването на синтаксиса на RANK или ламбда функция не е много полезно, ако не можете да обясните в какви случаи бихте използвали тези инструменти или защо са за предпочитане пред други алтернативи.

Друга много често срещана грешка е неспособността да се оцени качеството на данните в упражненията. Ако ви е даден набор от данни, преди да започнете да агрегирате, е препоръчително да проверите за нули, дубликати или отклонения, които биха могли да изкривят анализа. Това демонстрира добра преценка и практически опит.

Също така е изключително вредно да се избягва задаването на уточняващи въпроси . В бизнес казус за рекламни кампании, например, е напълно логично да се попита за сезонността, целевия времеви диапазон, дали се търсят показатели за потребител или за импресия и т.н. Мълчанието и правенето на предположения често води до решения, които не са в съответствие с това, което интервюиращият е имал предвид.

И накрая, избягвайте подхода на „прекодиране“: създаване на ненужно сложни решения, когато заявката или скриптът биха могли да бъдат по-прости. В реални работни среди се ценят яснотата, поддръжката и ефективността, а не решенията, подобни на пъзели.

Интензивен план за подготовка след две седмици

Ако имате ограничено време преди интервюто, можете да следвате кратък план, който обхваща трите ключови области: SQL, Python с pandas и практическо приложение. Няма да направите чудеса за 14 дни, но можете да пристигнете със солидно ниво на владеене и разумна увереност.

През първите няколко дни е добра идея да се съсредоточите върху SQL за начинаещи до средно напреднали : прегледайте основния синтаксис, JOIN-ове, GROUP BY, подзаявки и най-често срещаните функции за прозорци. Отделете време както за четене на примери, така и за писане на ваши собствени заявки.

Във втората фаза се фокусирайте върху pandas : зареждане на данни, почистване, филтриране, групиране, сливания и бърза визуализация с matplotlib или seaborn. Не е необходимо да изграждате сложни табла за управление, но е необходимо да можете да репликирате в Python същите трансформации, които бихте извършили в SQL.

След това отделете няколко дни за практически упражнения на платформи като HackerRank или хранилища за технически интервюта. Целта е да свикнете с формата, времевите ограничения и напрежението от писането на код в контролирана среда.

Накрая, изпробвайте една или две пълни симулации на интервюта : вземете публичен набор от данни, задайте разумни бизнес въпроси, решете ги с SQL или Python и обяснете на глас цялото си разсъждение, от първоначалното проучване до крайните заключения.

С добра комбинация от теоретичен преглед, насоки за практика и реалистични упражнения, ще стигнете до деня на интервюто със солидна основа в SQL на средно ниво, Python за анализ на данни и показатели за моделиране – точно това, което повечето компании в рекламните технологии и анализа на данни очакват да видят.