Дял на трафика от ботов Екипът за борба с измамите е разработил механизъм за откриване на трафика от ботове в сайта на магазина: когато бот влезе в сайта, към параметрите на неговия URL се добавя поднизът "bot" (без значение от големината на буквите). Ако user_id е бил определен като бот поне веднъж през декември, той винаги трябва да се счита за бот. Изследвайте набора от данни с посещенията на потребителите на сайта и изчислете дела на ботовете от общия брой потребители през декември 2024 г. (закръглете до една десетична точка). Формат на въвеждане Таблица visits: - event_date (date) — дата на посещението - user_id (int) — уникален идентификатор на потребителя - url (string) — линк, по който е осъществено посещението Данните не съдържат пропуски или некоректни стойности. Формат на изхода Заявката трябва да върне таблица с полета: - share (float) — делът на ботовете от общия брой потребители през декември, закръглен до една десетична точка.
Data Engineer
В PostgreSQL е необходимо да се оптимизира производителността на транзакциите чрез минимално ниво на изолация, при което: • паралелните транзакции могат да виждат незавършени промени една на друга; • възможни са "мръсни четения" (dirty read). Кой ниво на изолация трябва да се посочи за транзакцията, за да се постигне тази цел? мръсно четене не е възможно в PostgreSQL repeatable read read uncommitted read committed serializable
Има две транзакции. Първата транзакция изпълнява команда. След това втората транзакция изпълнява команда. След това първата транзакция продължава. Коя последователност ще доведе до взаимно блокиране? ```sql -- първа транзакция update accounts set balance = balance + 100 where id = ?; -- втора транзакция update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
Как да възстановите работата от отдалечена клонка, ако при опит да изпълните `git checkout hotfix/missing-footer` получите съобщение за грешка, че клонът не е намерен?
Анализ на активността на потребителите в рекламните кампании Фирмата води отчет за събития, свързани с рекламните кампании. Предоставени са два таблици: • campaigns — списък на рекламните кампании с техните идентификатори и имена; • events — събития на потребители по кампании с информация за типа на събитието (например 'click' (клик)) и времето. Необходимо е да се създаде отчет за всяка кампания с следните показатели: • Общо количество събития. • Брой уникални потребители, извършили събития. • Време на първото и последното събитие по кампания. • Ранг на кампанията по намаляващ брой на общите събития. Рангът е число, което се присвоява на всеки ред в резултатния набор въз основа на реда на данните. Ако две или повече реда имат еднаква стойност, те получават същия ранг, но следващият ранг се пропуска. Отчетът трябва да включва само кампании, които са имали събития: кампании без събития не се вземат предвид. Финалният отчет трябва да бъде сортиран първо по ранг на кампанията във възходящ ред, а след това по campaign_name в азбучен ред. Формат на входа • campaign_name (string) — името на рекламната кампания • start_date (timestamp) — дата и час на започване на кампанията • end_date (timestamp) — дата и час на приключване на кампанията Таблица events: • event_id (int) — уникален идентификатор на събитието • user_id (int) — уникален идентификатор на потребителя, който е извършил събитието • campaign_id (int) — уникален идентификатор на кампанията • event_type (string) — тип на събитието, например 'click' или 'conversion' • event_time (timestamp) — дата и час на събитието Данните не съдържат липсващи или неправилни стойности. Формат на изхода Заявката трябва да върне таблица с полета в този ред: • campaign_name (string) — името на рекламната кампания • total_events (int) — общият брой събития, свързани с кампанията • unique_users (int) — броят на уникалните потребители, които са извършили събития • first_event_time (timestamp) — дата и час на първото събитие на кампанията • last_event_time (timestamp) — дата и час на последното събитие на кампанията • campaign_rank (int) — ранг на кампанията по намаляващ брой събития Подредете данните по ранг на кампанията във възходящ ред, а след това по campaign_name в азбучен ред.
Какво трябва да направите, ако искате да промените клона, към който сочи подмодулът? - Подмодулите не поддържат смяна на клонове - Изтрийте подмодула и го добавете отново с желания клон - Променете клона в подмодула и направете комит в основното хранилище - Изпълнете git checkout на желания клон в подмодула и запишете промените в основното хранилище - Изпълнете git submodule update --branch, като посочите новия клон
Защо в момента разглеждате предложения за работа?
Какво се случи и как да възстановите работата?
В PostgreSQL, заглавието на версията на реда включва параметъра xmax. Каква е ролята му в управлението на транзакциите? - За създаване на уникален идентификатор на реда в таблицата - За проверка на видимостта на реда от други транзакции - За обозначаване на номера на транзакцията, която е изтрила или актуализирала реда - За блокиране на реда срещу едновременни промени от няколко транзакции - За указване на максималната стойност, която може да бъде записана в числова колона
Клонът feature съдържа няколко комита с неправилно комитнат файл config.yaml, който по-късно е бил коригиран. В резултат екипът реши напълно да премахне всички промени на файла от историята, за да избегне разкриването на конфиденциални настройки. Първоначалното състояние на клона (изходът от git log --oneline): 1 a4b5c67 (HEAD -> feature) Рефакторирана логика на услугата 2 d9f0a11 Коригирана правописна грешка в config.yaml 3 7c1d3f2 Добавен временен config.yaml 4 e3a98cd Първи комит 5 След преписване на историята за премахване на файла config.yaml, изходът от git log --oneline стана: 6 b9e7d42 (HEAD -> feature) Рефакторирана логика на услугата 7 41f3b60 Първи комит Каква операция е извършила екипът? - Изпълни git revert върху комита с config.yaml - Изпълни git filter-branch --index-filter "git rm --cached config.yaml" -- --all - Изпълни git rebase -i, като премахна комитите, съдържащи промени във файла - Изпълни git commit --amend и git push --force - Използва git cherry-pick за създаване на нов клон без config.yaml
Таблицата notifications съдържа поле status, в което стойностите са: 'sent', 'delivered', 'read'. Кой от заявките е правилен? select * from notifications where status like '%sent%' order by created_at desc limit 5 select * from notifications where status = 'read' order by created_at desc limit 5 select * from notifications order by status desc limit 5 select * from notifications where status not in ('sent', 'delivered') order by created_at asc limit 5 select * from notifications where status in ('sent', 'delivered') order by created_at desc limit 5
Моля, разкажете ни защо ви интересува тази ваканция.
Създадена е структурата на таблиците, посочена на изображението. Необходимо е да изпълните заявката, посочена на изображението. Какъв вид join трябва да се използва на мястото на [...], за да се получи в резултата за записите с type = 'table_aw' да бъде попълнена колоната 'naming', а за записите с type = 'table2' — колоната 'serial_number'? create table multirelation( type varchar not null, entity_id integer not null ); create table table_aw( id integer primary key, naming varchar not null ); create table table2( id integer primary key, serial_number varchar not null ); -- структура на таблиците select m.type,m.entity_id, ta.naming, t2.serial_number from multirelation m [...] join table_aw ta on m.entity_id = ta.id and m.type='table_aw' [...] join table2 t2 on m.entity_id = t2.id and m.type='table2'; -- заявка Оставете празно inner cross right left
Коя команда от кореновата папка на проекта трябва да се използва, за да се актуализира подмодулът docs/ до последната версия от отдалечения репозитори и да се подготви тази промяна за комит? git fetch docs/ && git merge docs/FETCH_HEAD git pull --recurse-submodules git submodule update --remote docs/ cd docs/ && git pull && cd .. && git commit -am "Обновяване" git submodule update --init docs/
Анализ на посещаемостта на фитнес клубов Работите като анализатор в мрежа от фитнес клубове. Имаме информация за посещенията на потребителите и за закупените от тях членства. Необходимо е да анализирате ефективността на използването на членствата. Изчислете за всеки тип членство: • общия брой потребители, използвали този тип членство. Включвайте само уникални user_id; • общия брой посещения с това членство. Включвайте всички посещения на потребителите с това членство; • делът на потребителите с това членство в проценти от общия брой на всички потребители (закръглен до една десета). За изчисляване на делът, използвайте отношението между броя на потребителите с това членство и общия брой на уникалните потребители. Всеки потребител може да има само едно членство. Резултатът сортирайте по тип членство в азбучен ред. Формат на входа Таблица memberships: • membership_id (int) — уникален идентификатор на членството • user_id (int) — уникален идентификатор на потребителя • membership_type (text) — тип членство Таблица visits:
Бързо трябва да върнете няколко файла към версията от последния комит, без да засягате останалите промени. Как да постъпите? git reset --hard HEAD Изтрийте и създайте файловете ръчно git fetch и git merge git revert HEAD git checkout HEAD^ <файл1> <файл2>
Какво се случи и как да върнете работата?
На какви проекти на Scala сте работили преди? Споделете конкретни задачи и постижения в тази технология.
Какво може да се каже за коректността на следния заявка? select * from sessions where ended_at is null and status != 'pending';
Имаш две свързани таблици: first_table и second_table. Искаш да изпълниш командата TRUNCATE TABLE second_table CASCADE;, за да изтриеш всички редове от second_table и всички зависими от нея данни. Какви могат да бъдат последствията от изпълнението на тази команда? create table first_table ( id integer primary key ); create table second_table ( id serial primary key, first_table_fk integer references first_table(id) ); - Последователността second_table_id_seq ще бъде нулирана до началната стойност. - Ще бъдат изтрити всички записи от first_table, свързани чрез външен ключ с second_table. - Съществуващите индекси за second_table ще бъдат изтрити и автоматично пресъздадени. - При последващи вмъквания в second_table, стойността по подразбиране за id може да започне с некоректна стойност. - Ще възникне грешка, тъй като командата CASCADE е забранена за таблици с външни ключове.