Таҳлили боздидҳои клубҳои фитнес Шумо ҳамчун таҳлилгар дар шабакаи клубҳои фитнес кор мекунед. Шумо маълумот дар бораи боздидҳои корбарон ва обунаҳое, ки онҳо мехаранд, доред. Зарур аст, ки самаранокии истифодаи обунаҳоро таҳлил кунед. Барои ҳар як навъи обуна: • шумораи умумии корбароне, ки ин навъи обунаро истифода бурдаанд. танҳо user_id-ҳои беназмро ба назар гиред; • шумораи умумии боздидҳо бо ин обуна. Ҳама боздидҳои корбарон бо ин обунаҳоро ба назар гиред; • ҳиссаи корбарон аз ин обуна дар фоиз аз шумораи умумии корбарон (ба як нуқтаи пас аз нӯг). Барои ҳисоб кардани ҳисса, нисбати шумораи корбарон бо ин обуна ба шумораи умумии корбарон назар кунед. Ҳар корбар метавонад танҳо як обуна дошта бошад. Натиҷаро ба навъи обуна ба тартиби алифбоӣ сорт кунед. Формати воридот Ҷадвали memberships: • membership_id (int) — шенасоии беназмии обуна • user_id (int) — шенасоии беназмии корбар • membership_type (text) — навъи обуна Ҷадвали visits: • visit_id (int) — шенасоии беназмии боздид • user_id (int) — шенасоии корбар • visit_date (timestamp) — санаи ва вақти боздид Маълумотҳо ягон арзишҳои холӣ ё нодуруст надоранд. Формати натиҷа Пурсиш бояд таблицаро бо майдонҳо дар чунин тартиб баргардонад: • membership_type (text) — навъи обуна • users_count (int) — шумораи корбарони беназм бо ин навъи обуна • total_visits (int) — шумораи умумии боздидҳои корбарон бо ин обуна • user_share (numeric) — ҳиссаи корбарон дар фоиз бо ин обуна аз шумораи умумӣ (ба як нуқтаи пас аз нӯг).
Data Engineer
Оё шумо бо методологияи Domain Driven Design (DDD) шиносед? Агар ҳа, намунаҳои истифодаи онро дар лоиҳаҳои худ мубодила кунед.
Чӣ тавр бояд субмодул ва файлҳои алоқаманд бо он аз лоиҳа хориҷ карда шавад? git submodule remove <роҳи-субмодул> git rm --cached <роҳи-субмодул>; бахши .gitmodules-ро тоза кунед; git commit git clean --submodules <рӯҳ> git submodule delete <рӯҳ> git remove submodule <рӯҳ>
Ҳамён платформасида кодда горизонтал сўзиш мавжуд create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
Оё дар зерпурсӣи зерин истифодаи индексро намекунад агар дар ҷадвали records (id) индексии оддӣ B-Tree дар id сохта шуда бошад? select * from records where id % 2 = 0 - Барои id, индекс GIN лозим аст - Индексон дар боёнҳои WHERE кор намекунанд - % як амали муқоиса аст, на филтр - limit ва offset барои оптимизатсия бо индекс ҳатмӣ мебошанд - Суроға ба майдони рақамӣ, на матнӣ меравад
Дар процеси кор кардани git bisect, шумо бо як commit рӯ ба рӯ шудед, ки бо сабаби набудани муҳити зарурӣ, намешавад санҷида шавад. Дар чунин ҳолат чӣ бояд кард? - Командаро git bisect start бо хешҳои дигар такрор кунед - Ин commit-ро бо командои git bisect skip гузаронед - Бисектро бо командои git bisect reset барқарор кунед - Commit-ро ҳамчун хуб бо командои git bisect good нишон диҳед - Commit-ро ҳамчун бад бо командои git bisect bad нишон диҳед
Отчет для логистической компании Вы аналитик логистической компании, которая ведет учет операций на складах. Вам необходимо составить отчет по эффективности работы каждого склада. Для каждого склада рассчитайте: • общее количество операций (count_operations); • общее количество товаров, обработанных на складе (sum_quantity); • среднее время обработки операции (avg_processing_time), учитывая только операции с указанным временем (не NULL), округленное до целого числа; • максимальное и минимальное количество товаров, обработанных в одной операции (max_quantity, min_quantity); • количество операций каждого типа («поставка», «отгрузка», «перемещение») в отдельных колонках: supply_operations, shipment_operations, transfer_operations. Отфильтруйте склады, у которых общее количество операций больше 2 и среднее время обработки не превышает 60 минут. Отсортировать результат по ID склада по возрастанию. Формат ввода Таблица operations: • operation_id (int) — уникальный идентификатор операции • warehouse_id (int) — идентификатор склада • operation_type (text) — тип операции: «поставка», «отгрузка», «перемещение» • quantity (int) — количество единиц товара в операции • operation_date (timestamp) — дата и время операции • processing_time (int) — время обработки операции Колонка processing_time может содержать пропуски. Формат вывода Запрос должен вернуть таблицу с полями в таком порядке: • warehouse_id (int) — уникальный идентификатор склада • count_operations (int) — общее количество операций, выполненных на складе • sum_quantity (int) — общее количество товаров, обработанных на складе • avg_processing_time (numeric) — среднее время обработки операции (в минутах), учитывая только операции с не NULL временем, округленное до целого числа • max_quantity (int) — максимальное количество товаров, обработанных в одной операции • min_quantity (int) — минимальное количество товаров, обработанных в одной операции • supply_operations (int) — количество операций типа «поставка» • shipment_operations (int) — количество операций типа «отгрузка» • transfer_operations (int) — количество операций типа «перемещение»
Тамсозиш махсус реттілик, номи even_sequence бўлиб, фақат juft sonлар ишлаб чиқаради. [...]-нинг ўрнига нима қўйилиши керакки, агар even_column қиймати қўшишда кўрсатилмаса, қиймат even_sequence-дан олинсин? create table some_table( even_column [...] ); integer computed as nextval('even_sequence') integer generated always as identity (start with 2 increment by 2) integer default nextval('even_sequence') integer unique default nextval('even_sequence') integer generated by even_sequence’
Тавзеҳ диҳед, ки Git LFS чӣ гуна ба таври техникӣ кор мекунад ва кадом бартарӣҳоро дар муқоиса бо Git стандартӣ дар кор бо файлҳои калон медиҳад.
Оё таҷрибаи кор бо китобхонаи Langchain доред? Кадом вазифаҳоро бо ёрии он ҳал кардед?
Чӣ кор кардан мехоҳед дар дастаи мо?
Кайси тиип бирикмани ишлатиш керак, ки танловга ҳам заказлари бўлмаган фойдаланувчилар ҳам кирсин? Жадваллар: users(id, name) ва orders(id, user_id, created_at). CROSS JOIN RIGHT JOIN INNER JOIN FULL JOIN LEFT JOIN
Чӣ тавр Git Flow тавсия медиҳад, ки барномаи навро расмӣ гардонем? - Бо эҷоди шохаи issue нав - Бо эҷоди шохаи hotfix аз master - Бо эҷоди шохаи release ҷудогона аз develop - Бо анҷоми коммити мустақим ба шохаи master - Бо ҳамҷоя кардани шохаи master бевосита ба develop
Кадом аз изҳороти зерин натиҷаҳои чунин амалҳоро аз нуқтаи назари Git Flow васеъшуда ва идоракунии таърихи тағирот инъикос мекунад?
Шумо дарёфтед, ки дар таърихи асосии репозитории Git коммитҳое мавҷуданд, ки маълумоти махфии муҳимро дар бар мегиранд. Ин маълумотҳоро бояд комилан аз тамоми таърихи репозитории хориҷ кард. Баҳо диҳед, ки истифодаи стратегияи зерин чӣ қадар дуруст ва бехатар аст: сохтани як коммити нав, ки маълумоти махфиро аз нусхаи ҳозираи файлҳо хориҷ мекунад ва онро ба main мефиристад. - Дуруст, аммо оптималӣ нест. Беҳтар аст, ки барои бекор кардани коммитҳо аз git revert истифода баред - Шартан дуруст. Ин як ҳалли муваққатӣ аст, то ки роҳи бештар радикалӣ барои хориҷ кардани маълумот пайдо шавад - Нодуруст ва бехатар нест. Маълумотҳо аз нусхаи ҳозира хориҷ мешаванд, аммо дар таърихи репозитории дастрас мемонанд - Нодуруст. Ин коммит метавонад дар пайванд кардан бо шохаҳои дигар боиси муноқишаҳои нав гардад - Дуруст ва бехатар. Ин усул кафолат медиҳад, ки маълумотҳо хориҷ мешаванд ва дигар дар репозитории пайдо намешаванд
Шумо дар шохи dev дар бораи функсияи нав кор мекунед. Нақшаан, зарур аст, ки зуд ба шохи main гузаред, то хатои имло дар файли README.md-ро бартараф кунед. Шумо чанд тағиротро, ки ҳоло комит нашудаанд, доред: дар src/feature.js (беиндексшуда) ва styles/main.css (индексшуда). Шумо мехоҳед ҳамаи ин тағиротро муваққатӣ нигоҳ доред, то баъдтар ба онҳо дар шохи dev баргардед. Кадом пайдарпайии фармонҳоро бояд барои ин истифода баред? git stash save "WIP on feature" && git checkout main && [fix] && git checkout dev && git stash pop git stash push -m "WIP on feature" && git checkout main && [fix] && git checkout dev && git stash pop git stash && git checkout main && [fix] && git checkout dev && git stash apply git add . && git stash && git checkout main && [fix] && git checkout dev && git stash drop git commit -m "Temp commit" && git checkout main && [fix] && git checkout dev && git reset HEAD^
Анализ продаж по категориям товаров в розничном магазине Вы работаете аналитиком в розничном магазине. Ваша задача — сформировать отчет о продажах по категориям товаров с расчетами: • общее количество проданных единиц в категории (total_units_sold); • суммарная выручка по категории, учитывая скидки, где скидка применяется как unit_price × units_sold × (1 − discount/100). Если скидка отсутствует (NULL), считать скидку равной 0%. Округлить до двух знаков после запятой; • среднее количество проданных единиц на одну продажу (avg_units_per_sale), округленное до двух знаков после запятой; • долю продаж без скидки (no_discount_share) — количество продаж с NULL или 0% скидкой, деленное на общее количество продаж в категории, округленную до трех знаков после запятой. Результат сначала отсортируйте по убыванию total_revenue, затем по возрастанию среднего количества единиц в продаже (avg_units_per_sale), в конце — по названию категории в алфавитном порядке. Формат ввода Таблица sales: • sale_id (int) — уникальный идентификатор продажи • product_id (int) — идентификатор товара • category (text) — категория товара • sale_date (timestamp) — дата и время продажи • units_sold (int) — количество проданных единиц • unit_price (numeric) — цена за единицу товара • discount (numeric) — скидка на товар в процентах, может быть NULL Колонка discount может содержать пропуски. Формат вывода Запрос должен вернуть таблицу с полями в таком порядке: • category (text) — категория товара • total_units_sold (int) — общее количество проданных единиц товаров в данной категории • total_revenue (numeric) — общая выручка по категории с учетом скидок, округленная до двух знаков после запятой • avg_units_per_sale (numeric) — среднее количество единиц товара в одном заказе, округленное до двух знаков после запятой • no_discount_share (numeric) — доля продаж без скидок в категории (значение от 0 до 1), округленная до трех знаков после запятой Результат сортируется сначала по убыванию total_revenue, затем по возрастанию среднего количества единиц в продаже (avg_units_per_sale), в конце — по названию категории в алфавитном порядке.
[ном] хатолар ва услубро дар матн ислоҳ кард: «Салом! Ман [ном], пештар дархост карда будӣ, ки ба Telegram гузарӣ» — бо эҳтиром, вале дар сатҳи дӯстона
Оё таҷрибаи кор бо рамкаи веб Gin доред? Лутфан бештар дар бораи вазифаҳои ки бо ёрии он ҳал кардаед, нақл кунед.
Доля трафика от ботов Команда антифрода разработала механизм определения трафика от ботов на сайт магазина — при входе бота на сайт в параметры его URL добавляется подстрока "bot" (без учета регистра). Если user_id хотя бы один раз был определен как бот в декабре, то он всегда должен определяться как бот. Изучите датасет с визитами пользователей на сайт и посчитайте долю ботов от общего числа пользователей в декабре 2024 года (округлите ее до одного знака после запятой). Формат ввода Таблица visits: - event_date (date) — дата визита - user_id (int) — уникальный идентификатор пользователя - url (string) — ссылка, по которой был осуществлен переход Данные не содержат пропусков или некорректных значений. Формат вывода Запрос должен вернуть таблицу с полями: - share (float) — доля ботов от общего числа пользователей в декабре, округленная до одного знака после запятой.