Простая проверка на предрасположенность студента к поиску нестандартных решений в программировании

А у вас диплом или курсы?

после прочтения комментарииев хочу заметить

Вы вообще очень страннор и резко реагируете на критику считая исключительно свою точку зрения верной на 100% ))) при этом почему то дискутирующих с вами считаете глупее вас

Хотя я много читаю текстов, ваша статья увы по больше части невнятна и написана трудночитаемым текстом, начиная о постановки второй части задачи и до самого описания решения данной задачи

Боюсь даже представить чему и как и каким образом вы учите 8класников )))

И да к критикующим обоснованно вас людям надо быть терпимее , может тогда вас и не будут под КАЖДЫМ комментарием минусить

Нет-нет. Я возбудился как раз на то, что из контекста поста следует что ТС далеко не случайный человек в этой отрасли. Вон, об алгоритмах же рассуждает...

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

Ну и на самом деле так ведут себя далеко не все заказчики - многие вполне себе умеют в строгую формализацию ТЗ.

С генерацией случайного числа и потом поиска его множителей есть проблема, которая состоит в том, что для начала было бы неплохо понять, а не простое ли это число. Конечно от 1 до 100 их не так много и можно захардкодить их и пытаться перегенирировать, но уже на этом этапе понятно, что генерация сразу произведения сопряжена с некоторыми сложностями и стоит поискать путь попроще

а потом долго будет думать "а каких двух чисел это произведение".

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

Это если вы работаете напрямую с клиентом. Если работаете с аналитиком или архитектором, тогда основная трудность именно написать программу, т.к. требования описаны, иногда вплоть до формата ответа сервисов.

очевидно в тезисе автора о том, что проблема наличествует

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

Ещё раз. У вас нет никаких доказательств корреляции между умением решать подобные задачки и опытом и компетентностью. Никаких. Только интуитивные домыслы. А интуитивным домыслам в инженерном деле не место. Всё должно проверяться и доказываться. Проведите широкое статистическое исследование и возвращайтесь. С превеликим удовольствием изучим этот материал.

И задача на 6 с плюсом - как это делать правильно, не просто выдёргивая вилку из розетки...

Олды тут?

А кроме шуток интересная была бы статья, если in-depth. Почему так можно, а так нельзя, а что может быть если вот так, а когда не может и т.п.

Ее без тонны глубоких знаний не напишешь.

Что как раз таки нужно делать на собеседовании.

Не то чтобы дословно писать, но оглавление накидать точно было бы полезнее. Какие подходы, какие подводные камни в каких местах на простейшем примере кода.

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

Блокчейн и нейросеть забыли.

Какие виртуалки? Только кубер. И обязательно нужны OpenTelemetry и Sentry

На хабре есть статья - hello world на микросервисах.

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

Надо было брать. Обычно такие - самородки :)

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

потому что на решение "в лоб" сразу вопрос "а если чисел миллиард?"

О, этого я насмотрелся. Из-за непонимания этого обычно следуют возгласы неофитов: "Да я такое за неделю сделаю...". Да без проблем! И это возможно будет работать на... десятке тысяч единиц информации. А если их миллион? А если триллион? То оказывается, что ни одно готовое решение не подходит. Более того известные алгоритмы не подходят, и приходится искать оригинальные компромиссные решения.

В общем... гладко было на бумаге...

на решение "в лоб" сразу вопрос "а если чисел миллиард?"

...а на такой вопрос сразу ответ "все условия, явно не оговорённые в задании, кандидат имеет право выбирать на своё усмотрение!"

алгоритмы Манро-Паттерсона или Канна-Гринвальда (и про тот и про другой здесь когда-то писали)

Могли бы и ссылочку привести.

почему не просто return sorted_nums[mid] ?

Не работает для чётного числа элементов.

Истинно так, только, выходит, тильда там по ошибке, должен быть минус.

Чтобы так решить эту задачку, надо было мыслить примерно так:

Цель: получить два соседних средних элемента (если кол-во элементов четное) или средний элемент два раза (если кол-во элементов нечетное). И всё это сделать без дополнительных условий.

Для этого автор решения хочет взять второй элемент, отсчитывая с начала списка, а первый - с конца списка.

Если получить индекс среднего элемента путем целочисленного деления длины списка на 2 (mid = len(nums) // 2), то мы получим индекс второго элемента (для четной длины). Но как получить индекс первого элемента? -mid будет на 1 больше, чем надо.

Например (в скобках пишу значения переменных):
nums = [1,2,3,4,5,6]
mid = 6 // 2 (в mid индекс 3)
nums[3] (вынимаем число 4) - ок, это правильно
nums[-3] (вынимаем число 4) - это неправильно, промахнулись на один элемент, нужен индекс -4.

Что делать? Вспоминаем, что отрицательные числа хранятся в памяти в двоичном дополнительном коде. Как получается дополнительный код? Инверсией битов и прибавлением 1 (на этом уровне нет отрицательных чисел, просто старший бит установлен в 1).

Например число -3 в дополнительном коде (считаем для простоты слово размером в 4 бита, старший бит означает знак):

0011 - это 3
1100 - это ~3 (инверсия битов)
+
0001 - дополняем единицей
1101 - это -3 в дополнительном коде

Замечаем, что инвертированная побитно 3 отличается от допополнительного кода (т.е. -3) на 1, а это то, что нам нужно: ~3 == -4

Всё! Поэтому вынимаем два средних элемента:
nums[mid], nums[~mid]
т.е. nums[3], nums[~3],

что соответствует элементам: 4 и 3. Это то, что надо - побитовая инверсия дает отрицательное исходное число с коррекцией на 1.

Для нечетной длины списка это решение также работает без изменений.

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

Но в продакшене так извращаться, конечно, не надо.

Генерация работать будет быстро, так что за секунду можно нагенерить много вариантов. Подход может и не совсем правильный архитектурно, но если это учебная/тестовая задача - не вижу проблем.

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

Сравните:
вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)

вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.

Второй вариант явно сложнее.

С точки зрения здравого смысла и пользы для сугубо гипотетического юзера "обучающей программы" — соглашусь, конечно так.

С точки зрения программиста-буквоеда на интервью — вопросы неизбежны :)

Именно таким мышлением отличается кодер от программиста )))

Задача слишком простая и от этого вариантов много :)
К примеру можно использовать MVVM из UI фреймов, таких как MAUI к примеру. Суть его в том, что есть View - то что видит пользователь, Model - то, что управляет VIew т.е. непосредственно контентом, и ViewModel - данные, с которыми работает Model:

class TaskViewModel{
  private ITask[] _tasks;
  TaskView(ITask[] tasks){
    _tasks = tasks;
  }
  public void StartTesting(){
    foreach(var task in _tasks){
      Console.WriteLine(task.GetTask());
      HandleAnswer(task.CheckAnswer(Console.ReadLine()));
    }
  }
  private void HandleAnswer(bool isRight){
    if(isRight){
      Console.WriteLine("Верно");
    }
    else
    {
      Console.WriteLine("Не верно");
    }
  }
}

interface ITask{
  string GetTask();
  bool CheckAnswer(string answer);
}

Вот реализация MVVM в крайне грубом варианте :) (Правда называть это MVVM - неправильно, т.к. это View-Model или View-ViewModel) View здесь это - Console.

И как писал funca выше - это хорошая (хоть и нечестная) задача заставляющая изучить тему, и вы как учитель сильно подстегнули аудиторию :)