Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Войти
Войти
Забыли пароль?
Создать аккаунт
Создавая аккаунт, я соглашаюсь с правилами использования сайта и даю согласие на обработку персональных данных.
Восстановление пароля
Восстановление пароля
Получить код в Telegram
или продолжите с
Войти через Google Войти через VK ID Войти с Яндекс ID
Создать сообщество

Топ прошлой недели

  • EvaPtits EvaPtits 33 поста
  • bgafk bgafk 67 постов
  • dyadka1337 dyadka1337 50 постов
Посмотреть весь топ
Вакансии

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая кнопку «Подписаться на рассылку», я соглашаюсь с Правилами Пикабу и даю согласие на обработку персональных данных.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Новости Пикабу Помощь Кодекс Пикабу Реклама О компании
Верификации Награды Контакты О проекте Зал славы
Промокоды Скидки Вакансии Курсы
Блоги Купоны Мегамаркет Купоны Мвидео Купоны Hoff
Android iOS

Техническое задание

Теги
С этим тегом используют:
Юмор Работа Заказчики Картинка с текстом IT юмор IT Скриншот
Все теги
Рейтинг
Автор
Сообщество
Тип постов
любые текстовые картинка видео [мое] NSFW
Период времени
за все время неделя месяц интервал
471 пост сначала свежее
awfun
6 дней назад
Лига программистов

Простые требования легче реализовывать⁠⁠

Всем привет, работаю java разработчиком 10 лет. Хотел бы на примере пояснить, почему важно внимательно вникать в требования, и не допускать их избыточного утяжеления.

Представим, что нам нужно сделать систему, проводящую платежные поручения, и у каждого поручения должен быть свой уникальный идентификатор. Поддержку уникальности осуществляет реляционная база данных, идентификатор используется как primary key. Какой тип и правило задать для генерации идентификатора?

  • integer, числовая последовательность: 0001, 0002, ...

  • UUID.random() : 8c061868-5bbd-4ea7-824f-d8640fb4f6e3, ...

UUID может совпасть при двух генерациях, но с крайне малой вероятностью - можно сказать что он уникален. Значения в последовательности тоже уникальны. То есть уникальность поддерживается там и там.

Так как эти уникальные значения можно сравнивать, то можно привести их к полному порядку - отсортировать и расположить в виде структуры с эффективным доступом (например, дерево со сложностью logN).

Числовая последовательность обеспечивает не какой-то порядок - он еще и совпадает с порядком добавления записей в таблицу. Если в конце месяца мы захотим подарить подарок 1000-му пользователю сервиса, то это можно сделать если исходный порядок сохранен.

В большинстве реляционных баз реализована поддержка реплик - узлов в резерве, на случай падения основного узла, осуществляющего запись. Реплики копируют данные с основного узла с небольшим отставанием, например последний платеж может в какой-то момент времени еще не дойти до реплики:

main: (0001, 0002, 0003)
replica: (0001, 0002)

Если основной узел выйдет из строя, то дальше все операции по записям возьмет на себя реплика. В указанном случае она будет выдавать идентификаторы далее: 0003, 0004, ... . Получается, у разных узлов будет разное представление об операции с id = 0003 - это создаст конфликт, если первый узел вернется к жизни.

Можно было бы вместо этого выбирать тысячную запись не по id, а по времени создания. В этом случае можно использовать UUID как идентификатор, и добавлять время создания записи, чтобы позже по нему выявить 1000-го пользователя. В случае падения основного узла конфликта с id не будет, но на разных узлах может не совпадать время - а это бывает при проблемах с ntp сервисами. Например, во время выхода из строя основного узла время на нем было 15:20, а на реплике 15:12, и у новых пользователей время будет меньше чем у существующих.

Еще можно было бы согласовывать следующее число в последовательности общим решением всех узлов, но такой подход более затратен и имеет свои проблемы.

На этом примере видно, что разработчику стоит строго фильтровать требования от бизнеса - пользуясь глубоким пониманием используемых решений давать справедливую оценку сложности доработок. Всем удачных проектов и профессионального роста!

Показать полностью
[моё] Разработка IT Программирование Техническое задание Текст
4
Meantol21
11 дней назад

Это вызов для разработчиков! Для всех кто хочет сделать мир лучше! Техническое задание на создание мобильного приложения "Честная цена"⁠⁠

Это вызов для разработчиков! Для всех кто хочет сделать мир лучше! Техническое задание на создание мобильного приложения "Честная цена" Инновации, Изобретения, Программирование, Цены, Техническое задание, Разработка, Фотография, Приложение, Длиннопост

🚀 Присоединяйтесь к Революции в Мире Шопинга с Нашим Новым Приложением!

🌟 Вы когда-нибудь сталкивались с трудностями при попытке понять, сколько на самом деле стоит продукт, если цена указана за упаковку или за нестандартный вес? Наша жизнь полна таких ситуаций, будь то в супермаркете или на рынке. Сколько раз вы считали в уме, пытаясь выяснить, выгодно ли предложение или нет?

🌍 Мы представляем революционное приложение, которое изменит ваш опыт покупок навсегда! Это приложение – ваш личный помощник в расчёте стоимости товара за килограмм. Проще говоря, оно поможет вам делать осознанные и экономически выгодные выборы, не тратя лишнее время и силы на расчёты.

✨ Как это работает?

  • Простота использования: Введите цену продукта и его вес – приложение мгновенно выдаст цену за килограмм.

  • Экономия времени: Забудьте о сложных подсчётах в магазине. Теперь все расчеты сделает приложение за вас.

  • Лучшие решения: Сравнивайте цены на разные продукты и выбирайте самые выгодные предложения.

  • Образовательный аспект: Улучшайте свои навыки в финансовом планировании и бюджетировании.

🌐 Мы приглашаем разработчиков, дизайнеров, маркетологов и всех, кто хочет внести вклад в создание этого уникального приложения, присоединиться к нашей команде. Вместе мы сможем создать нечто по-настоящему ценное для миллионов пользователей по всему миру.

💪 Присоединяйтесь к нам и станьте частью решения! Вместе мы сделаем покупки проще, умнее и выгоднее для всех!


Этот призыв нацелен на вовлечение и мотивацию потенциальных участников проекта, подчеркивая важность и полезность приложения для повседневной жизни.

Это вызов для разработчиков! Для всех кто хочет сделать мир лучше! Техническое задание на создание мобильного приложения "Честная цена" Инновации, Изобретения, Программирование, Цены, Техническое задание, Разработка, Фотография, Приложение, Длиннопост

Техническое задание на создание мобильного приложения "PricePerKilo"

1. Введение

Цель этого документа - описать требования к разработке мобильного приложения "PricePerKilo". Это приложение предназначено для вычисления стоимости продуктов за килограмм по данным, полученным с камеры смартфона.

2. Описание приложения

2.1. Функциональные требования

  1. Распознавание данных с фотографии: Приложение должно распознавать цену и вес продукта с фотографии, сделанной камерой смартфона.

  2. Ручной выбор данных: Пользователь должен иметь возможность вручную выделить на фотографии цену за упаковку и вес в граммах.

  3. Вычисление стоимости за килограмм: На основе полученных данных приложение должно автоматически вычислять стоимость продукта за 1 килограмм.

  4. Сохранение результатов: Результаты вычислений должны сохраняться в памяти устройства.

  5. Сравнение цен: Пользователь должен иметь возможность сравнивать сохраненные данные по разным продуктам.

2.2. Нефункциональные требования

  1. Интерфейс: Интуитивно понятный и удобный интерфейс.

  2. Отсутствие рекламы: Приложение должно быть свободно от рекламы.

  3. Автономность: Приложение должно работать без доступа к интернету.

  4. Безопасность: Защита личных данных пользователя и сохраненной информации.

3. Технические требования

3.1. Распознавание изображений

  • Использование библиотеки для распознавания текста на изображениях (например, Tesseract OCR).

  • Алгоритмы для выделения и распознавания числовых данных на фото.

3.2. Платформы

  • iOS и Android.

3.3. Язык программирования

  • Рекомендуется Kotlin для Android и Swift для iOS.

3.4. Локальное хранилище данных

  • SQLite или аналогичная система для хранения результатов расчетов.

4. Дизайн и пользовательский интерфейс

  • Современный и минималистичный дизайн.

  • Удобная навигация по приложению.

  • Визуальное выделение выбранных данных на фотографии (цена, вес).

5. Тестирование

  • Модульное тестирование основных функций приложения.

  • Интеграционное тестирование для проверки взаимодействия различных компонентов приложения.

  • Функциональное тестирование интерфейса пользователя.

6. Заключение

Данное приложение представляет собой уникальное решение для помощи пользователям в сравнении цен на продукты в магазинах. Разработчик, успешно реализовавший этот проект, действительно может считать себя героем, так как его работа будет вносить значительный вклад в повседневную жизнь пользователей.

Это вызов для разработчиков! Для всех кто хочет сделать мир лучше! Техническое задание на создание мобильного приложения "Честная цена" Инновации, Изобретения, Программирование, Цены, Техническое задание, Разработка, Фотография, Приложение, Длиннопост
Показать полностью 2
[моё] Инновации Изобретения Программирование Цены Техническое задание Разработка Фотография Приложение Длиннопост
33
Leonidis.Popov
Leonidis.Popov
14 дней назад
Человек в Китае
Серия «Работки»

Опять проверка образцов для Пикабушников⁠⁠

Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост

На этот раз проверял детскую посуду с присосками. Она не бьется, не нагревается и не сложно перевернуть. Что максимально безопасно для детеныша.
Единственное мягкие вилки по факту бесполезны и достаточно одной ложки. Потому что вилку невозможно использовать из-за ее мягкости и это получается вторая ложка в наборе, просто дырявая

Ну и чтобы облегчить вам работу с Китаем и себе собственно с вами)

Прикрепляю пример ТЗ, по которому нужно было проверить этот образец:

Т.З. для проверки.

1.1 Замеряем упаковку (хорошо бы взвесить если найдутся весы).
1.2 Трясем упаковку. Бултыхается ли вообще что-то , или в ложементах уложено?

2.1 Вскрываем и стараемся понять, если неприятный запах посуды. И субъективно, приятные ли ощущения когда держишь посуду в руках? Ручки вилки и ложки, и все остальное?
2.2 Из чего, внешняя упаковка, насколько крепкая (если гофракартон, толщина его), внешний вид со всех сторон. Дополнительно внутри есть ли что то (пенопласт, пузырьковая пленка, иное) снять на видео или фото

Внимание, прежде чем устраивать краш-тесты учитываем, что потом это будет делать ребенок. То есть сначала применяем половину своих усилий, смотрим на результат. Если продукция выдерживает, фиксируем это. После этого уже прикладываем максимум усилий для выполнения краш-теста. (но без фанатизма)

3. Смотрим внешний вид на аккуратность и распаковка (фото и видео):
3.1 есть ли не ровные края у посуды, остатки технологических швов.
3.2 есть ли замятия у липучек, которые не позволят прилипать к поверхности?
3.3 прилепить тарелку к столу (желательно испытать на разных поверхностях) хорошо ли держится.
3.4 Много ли надо усилий чтоб прилепить и отлепить посуду, так же сдвинуть в бок, до момента пока посуда не отлепиться. (снять на видео)
3.5 постараться выдернуть деревянную часть вилки и ложки из силиконовой, возможно ли это? Если да, то возможно ли вставить обратно? Много ли надо усилий для данных манипуляций?
3.6 попробовать порвать тарелку растягивая и изгибая ее, снять на видео.
3.7 налить горячую воду в кастрюлю и опустить туда посуду, есть ли изменения в формах посуды? (если есть возможность то, вскипятить, у нас жива доктрина "всё кипятить")
3.8 поильник
3.8.1 крепко ли сидит крышка на поилке, налить туда воду и уронить на столе. Выливается ли вода от туда. Перевернуть поильник, сильно ли льется вода?
3.8.2 Гибкая ли трубочка? Можно ли ее выдернуть?
3.8.3 легко ли надевается вторая крышка на поильник
3.9 слюнявчик
3.9.1 легко ли застегиваются и закрепляются крепления? Снять на видео.
3.9.2 попробовать оторвать крепления, много ли надо усилий для этого? Снять на видео.
3.9.3 деформируются ли крепления при растягивании и застегиваются ли они потом? Ели да, прислать фото и видео.

P.S. - Чем подробнее ТЗ вы сделаете, тем легче мне будет провести проверку и тем более лучший результат вы получите!

Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост
Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост
Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост
Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост
Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост
Опять проверка образцов для Пикабушников Китай, Проверка, Образцы, Работа, Услуги, Техническое задание, Длиннопост
Показать полностью 7
[моё] Китай Проверка Образцы Работа Услуги Техническое задание Длиннопост
0
Партнёрский материал Реклама
specials
specials

Вы смотрите геймерские шоу и игровых блогеров? А ссылочкой поделитесь?⁠⁠

Мы составляем подборку интересных игровых каналов, шоу и даже просто рубрик про игры, которые можно найти на просторах RUTUBE. Пожалуйста, поделитесь ссылками на то, что смотрите сами, и расскажите, почему вам нравится этот контент.

В конце декабря в этом профиле выйдет подборка. Если ваши предложения окажутся в ней — придет уведомление к «колокольчик»!

Компьютерные игры Блогеры
Kaladinn
Kaladinn
16 дней назад
Лига программистов
Серия «Карьера в IT. Системный аналитик.»

Карьера в IT. Системный аналитик, не номерная часть. Подходы к степени детализации и проработки ТЗ системным аналитиком⁠⁠

❕Сегодня хочу поговорить на очень спорную тему, я бы даже сказал философскую. Отчасти из-за нее, возникает очень много непонимания между коллегами, работающими в одном и том же (казалось бы) "АйТи", но почему-то имеющих очень разное представление о процессах разработки и о том, что каждая роль команды должна выполнять. Особенно это часто всплывает в моих постах на этом ресурсе, в комментариях - это такой хороший срез из разных уголков нашего отечественного IT.

И это большая тема для постов и для рассуждений. Но сегодня сосредоточимся на небольшой части этой темы, касающейся непосредственно системных аналитиков.

Давайте поговорим о том, какие есть подходы к написанию ТЗ и степени его проработки на примере описания тех же микросервисов\их методов.

❕Представим, что мы является системным аналитиком в команде и нам поставили задачу - реализовать личный кабинет пользователя.

Т.е. когда пользователь нажимает на какую-нибудь иконку профиля в приложении или там на кнопку "Профиль" - ему должна открываться экранная форма, в которой ему отрисовывается определенный набор полей и эти поля заполняются информацией. Также допустим, что у нас сам объект "Пользователь" уже есть в системе, атрибутивный состав понятен и нужно только реализовать процесс получения данных о пользователе на фронт по его идентификатору (ТЗ на фронт, на экранную форму и на интеграцию его с бэком опустим).

Какие есть варианты написания ТЗ для данной задачи?

1️⃣Самый минимальный уровень детализации. Это когда системный аналитик просто ставит задачу на разработку Джире (ну или в рамках небольшой страничке в конфлю\ворде, в зависимости от того, как принято) и в постановке этой задачи пишет что-то вроде "Требуется реализовать процесс получения данных о пользователе и передачу ее с бэка на фронт по REST-запросу. Со стороны фронта требуется создать новую экранную форму приложения - "Личный кабинет" или "Профиль пользователя". Со стороны бэка требуется реализовать новый метод, который будет использовать фронт для запроса информацию по пользователю (и, скорее всего, перечисляет набор полей, которые должны передаваться на фронт в формате "Фамилия", "Имя" и т.д.)". Усё

Я не утрирую - это один из вариантов реального "ТЗ" на эту задачу. Плюсом к этому может быть описан пользовательский сценарий в вольном формате или в формате UC (и то это будет в лучшем случае). Т.е. по сути в рамках такого процесса разработчик получает из полезной информации - только состав полей, передачу которых ему нужно реализовать по запросу с фронта, и то только их наименования.

2️⃣Вариант с немного лучшей детализацией. В этом формате системный аналитик уже пишет ТЗ в каком-либо формате, в рамках которого указывает, что: "Требуется реализовать новый метод GET /users/{id}, указывает полноценно параметры, которые данный метод должен потреблять на вход и параметры, которые он должен отдавать на выходе." Плюс может описать, также как в предыдущем пункте, верхнеуровневый сценарий взаимодействия с этим методом.

Уже чуть лучше и чуть больше полезной информации для разработчика, правда?

3️⃣Вариант с достойной реализацией. Этот вариант обычно используется на большинстве проектов ФинТеховских и я считаю его достаточным для того, чтобы написать хорошее, качественное ТЗ и разгрузить разработчика так, чтобы он не думал о деталях реализации, хотя бы алгоритмических и системных (то, к чему нужно стремиться со стороны СА, имхо).

В рамках этого варианта будет всё из предыдущих + будет полностью описана логика работы данного метода, как бизнесовая, так и техническая. Будут описаны все корнер-кейсы, правила обработки ошибок, варианты того, что может вернуться в ответе (кроме успешного ответа, еще и все варианты негативных). Логика может быть описана или на уровне псевдокода или просто словами - конкретно это уже не имеет значимой роли, главное то - что эта логика пошагово и подробно описана.

Пример подобного описания я приводил ранее в своих постах. Я топлю всегда как минимум за этот вариант описания любых задач - что бэковых, что фронтовых, любых. Избавить разработчиков от лишней работы с точки зрения проработки алгоритмов и логики, если мы вполне это можем сделать сами - у них хватает работы и так, можете поверить.

4️⃣Более полноценный вариант придумать не могу =)

Плюсом к 3 пункту дополнительно описывается еще и swagger-спецификация микросервиса в целом и конкретных эндпоинтов в частности. Кроме того, что это просто удобно, наглядно и очень детально - эту спецификацию разработчики могут использовать, чтобы сконвертировать ее напрямую в готовый код с расписанными классами и эндпоинтами, останется "только" докрутить бизнес-логику и метод готов (Тут просьба поправить меня коллегам, которые более глубоко погружены в разработку - так ли это или есть еще какие-то бенефиты для разработчиков. Могу в этом предложении быть не прав, пишу исходя из того, как мне это объясняли).

Кроме этого, такой подход хорошо использовать в парадигме swagger-first, особенно когда у вас есть насыщенный и активный процесс кросс-командной разработки. Отдать другой команде сваггер аналитику куда проще и быстрее, чем отдать полноценное ТЗ на сервис - хотя бы просто по времени. А большего им и не нужно (потому что им пофиг на то, как работает ваш сервис внутри, главное понять, как вас вызывать и что вы вернете в ответе).

А если это все еще и использовать в связке с asciidoc-документацией, выкладывании ее в git- ммм, сказка просто. Как вспоминаю об этих процессах, наворачивается скупая слеза ностальгии - как же это было здорово! Жаль, что я встретил это ровно в одном проекте, а во всех последующих так и не смог продавить внедрение чего-то похожего.

И я вполне понимаю почему (например, очень удобно когда ты почти не тратишь время и ресурсы на написание глубокого ТЗ - достаточно пары фраз, а дальше нехай разработчик разбирается. И чем дольше пишешь в таком режиме, тем больше он тебя поглощает). Но кроме этого есть и множество других, о чем поговорим в следующий раз.

А с какими процессами и подходами работаете вы?

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-, хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

Показать полностью
[моё] Пост Карьера IT Системный анализ Обучение Профессия Поиск работы Текст Длиннопост Системные требования Техническое задание Удаленная работа
0
Vic333
Vic333
1 месяц назад
Юмор для всех и каждого

Рыдаю от техзадания!⁠⁠

Получил сегодня техническое задание на составление отчёта по НИОКР.
Короткая переписка с заказчиком.
Рыдаю!

Рыдаю от техзадания! Техническое задание, Переписка, Скриншот
[моё] Техническое задание Переписка Скриншот
21
Dr.BuLkin
Dr.BuLkin
1 месяц назад

Восстание началось⁠⁠

Восстание началось Программирование, IT, Telegram (ссылка), Картинка с текстом, Повтор, IT юмор, Техническое задание

Источник: IT-Комедия: Улётные Приколы

Показать полностью 1
Программирование IT Telegram (ссылка) Картинка с текстом Повтор IT юмор Техническое задание
14
Kaladinn
Kaladinn
2 месяца назад
Лига программистов
Серия «Карьера в IT. Системный аналитик.»

Карьера в IT. Системный аналитик, часть 9. Список тем для подготовки к собеседованию на позицию джуна. Часть 2⁠⁠

Продолжаем список тем и вопросов, ответы на которые нужно знать, чтобы пройти собеседование на позицию джуниора.

Еще небольшое предисловие - судя по комментариям к предыдущему посту, не все понимают, что не обязательно, что ВСЕ эти вопросы попадутся вам одновременно. Это наиболее вероятные вопросы, которые вам зададут ( по крайней мере актуально для ФинТех сферы). Ну и опять же, всё очень зависит от интервьюера, его опыта и тех целей, которые ему поставило руководство компании\проекта, на интервью.

Есть еще очень хороший подход к интервью, когда ты задаешь вопросы по каждой теме, и чем больше правильных ответов дает соискатель - тем глубже ты копаешь в эту тему, пока его знания по вопросу не иссякнут. Это позволяет не просто прогнать человека по заданным темам, которые нужны компании, но и в целом представить его уровень более детально (плюс так куда интересней для всех участников собеса).

Более техническая часть собеса:

  1. Архитектурно-интеграционные вопросы:

    1. Что такое клиент-серверная архитектура? Что такое тонкий и толстый клиент, чем они отличаются? (Тут никто не ждет прям уверенных технических знаний и деталей реализации того или иного подхода, но в общих чертах знать нужно).

    2. Что такое HTTP? Какие основные методы HTTP вы знаете? Какие функции они выполняют? Расскажите про структуру HTTP-сообщений. (Если вы перечислите основные методы и скажете, что у сообщения есть заголовок, строка и тело - это уже, в целом, неплохо. Если знаете больше этого, вообще замечательно).

    3. Что такое REST? Какие основные принципы у него есть? Какие методы есть в REST? В чем разница между GET и POST запросом?

    4. В каких местах (четырех) мы можем передать атрибуты в запросе? (Path, Body, Query, Header).

    5. Что вы знаете про концепцию CRUD?

    6. Что такое идемпотентность? Какие методы являются идемпотентными?

    7. Что такое синхронные и асинхронные интеграции? В чем между ними разницы? С помощью чего можно их реализовать?

    8. Можно ли реализовать асинхронную интеграцию через REST? (Вряд ли этот вопрос будут задавать, если вы не ответите на предыдущие. Это скорее со звездочкой и не обязательный)

    9. Что такое очередь сообщений? Как передаются сообщения через очередь? Какие очереди сообщений есть и в чем между ними разница? (Если расскажете про PUSH/PULL-стратегии - плюсик в карму обеспечен)

    10. Что такое гарантированная доставка сообщений и какими механизмами ее можно обеспечить?

    11. Какие вообще способы интеграции существуют? С какими из них приходилось работать? В чем их преимущества и недостатки? (Интеграция через обмен файлами, через общую БД, через веб-сервисы и обмен сообщениями)

  2. Базы данных:

    1. Что такое базы данных? Какими они бывают? С каким БД приходилось работать?

    2. Что такое ER-диаграммы? Приходилось ли их проектировать?

    3. На какой уровень оцениваете свой уровень владения SQL? С какими инструментами по работе с БД знакомы?

    4. Ну тут могут конечно и про формы нормализации спросить, но уже лишнее, как по мне. Я обычно спрашиваю больше про опыт проектирования БД в целом. Приходилось ли проектировать базу в целом и под конкретные задачи в частности, каким образом это было сделано.

  3. Различные задачки:

    1. Тут вообще кто во что горазд в плане придумывания задач. В среднем, вам дадут умозрительное задание на проектирование какой-либо системы и попросят выделить основные классы этой системы (возможно, предварительно нужно будет собрать требования с интервьюера), спроектировать интеграцию между частями этой системы/интеграцию с внешними системами (плюс объяснить выбор технологии интеграции). Основной упор на ваши размышления, в основном именно в подобных вопросах можно понять уровень соискателя, потому что все остальные можно заучить. А тут проверяется именно понимание того, о чем вы рассказывали предыдущую часть собеседования.

  4. Небольшие оффтопные вопросы:

    1. Расскажите, что такое авторизация, аутентификация и идентификация? Чем они отличаются друг от друга? (почему-то один из самых любимых вопросов некоторых людей)

    2. Чем верификация отличается от валидации?

    3. Приходилось ли работать с JIRA\Confluence?

Конечно, так получается, что если вы знаете ответы на все эти вопросы, или больше 80-90%, то как будто бы вы уже не джун. Но чем лучше вы отвечаете, чем лучше вы соответственно подготовились - тем больше вам зададут вопросов (в нормальном интервью, а не шаблонном). Что очень сильно повысит ваши шансы получить оффер и выделиться среди других кандидатов.

Поэтому, конечно, можно, и зачастую нужно, пробовать собеседоваться, при наличии знаний, которые позволят ответить вам на половину из этих вопросов - шансы всё еще будут, плюс вы получите опыт прохождения собеседований (что само по себе очень важно) и определите те темы, про которые часто спрашивают, но в которых вы пока еще не сильны.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-,хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

Показать полностью
[моё] Пост Карьера IT Системный анализ Обучение Профессия Поиск работы Текст Длиннопост Системные требования Техническое задание Удаленная работа
13
vadbel1310
vadbel1310
2 месяца назад
Специфический юмор
Серия «На отвлеченные темы»

Посвящается всем, кто что-то у кого-то заказывает⁠⁠

Посвящается всем, кто что-то у кого-то заказывает Жизнь, Техническое задание, Люди, Заказ, Работа, Непонимание, Свинья, Конфеты, Заказчики, Труд, Деньги, Юмор, Шоколад, Упаковка, Дизайн, Дизайнер, Производство, Картинка с текстом

Когда 23-летней девочке-дизайнеру родом из Питера и суровому 60-летнему технологу пищевого производства родом из станицы в Ростовской области поставили задачу сделать конфету в виде хрюшки.

Показать полностью 1
Жизнь Техническое задание Люди Заказ Работа Непонимание Свинья Конфеты Заказчики Труд Деньги Юмор Шоколад Упаковка Дизайн Дизайнер Производство Картинка с текстом
51
Партнёрский материал Реклама
specials
specials

Расскажите, что вы мечтаете найти под елкой⁠⁠

Два человека из трех мечтают получить в подарок на Новый год технику — так показывают опросы общественного мнения. Но ведь техника бывает такой разной! Расскажите, о чем мечтаете именно вы. Представьте: разворачиваете подарок, а там…

Подарки Технологии
Посты не найдены
12345659Далее
О Пикабу
О проекте
Контакты
Реклама
Сообщить об ошибке
Отзывы и предложения
Новости Пикабу
RSS
Информация
Помощь
Кодекс Пикабу
Награды
Верификации
Бан-лист
Конфиденциальность
Правила соцсети
О рекомендациях
Наши проекты
Блоги
Вакансии
Промокоды
Скидки
Курсы
Зал славы
Mobile
Android
iOS
Партнёры
Fornex.com
Промокоды Мегамаркет
Промокоды Мвидео
Промокоды в Пятёрочке
Промокоды Hoff
Промокоды в Ленте Онлайн
Промокоды МТС
Промокоды Сбермаркет
Промокоды Яндекс Маркет
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии