Опрос кого-либо на общие навыки Unix [закрыто]

Как бы вы протестировали разработчика, который утверждает, что имеет опыт работы с * nix shell (просто для ясности, мы не хотим проверять, может ли кто-то разрабатывать на * nix, только чтобы он знал свой путь в командной строке).

Я думал о том, чтобы заставить их решить проблему извлечения информации из файлов журналов, которая включала бы некоторые основы, такие как cat, grep, cut, ... в сочетании с трубопроводом.

Какие еще базовые знания вы бы попросили? Еще раз, это не для собеседования с кем-то, кто будет разрабатывать для систем * nix, а также не для системных администраторов * nix, а только для обычных разработчиков, которым иногда требуется некоторая работа в системе * nix.

Из моего личного опыта разработчик, работающий над системой * nix, должен знать:

• переменные оболочки (как установить / получить + знание о специальных, таких как PATH)
• перенаправление оболочки (захват результатов программы)
• каналы (извлечение некоторой информации из файла журнала - отличный пример)
• управление процессом (ps, nice / renice, kill)
• права доступа к файлу (ls / chmod / chown / chattr)
• пользователи (но в основном в контексте файлов / процессов, то есть: может ли этот процесс получить доступ к этому файлу? почему он может / не может?)

... и в качестве бонуса:

• запуск / остановка системных служб

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

Из моего опыта работы с многочисленными коллегами с тех пор, как я начал работать, никто не хочет подделывать знания Unix: либо они « разбираются в командной строке », либо просто говорят «ни за что!».

Просто спросите, готов ли кандидат работать на рабочей станции Unix, и пусть он скажет вам, как далеко он может пройти bash. Он в конце концов назовет некоторые команды; наиболее очевидные из них cd, cat, moreили less, viили emacs, grep, awk, sed. Слушайте внимательно, упоминает ли он man.

Если для развития, он должен быть знаком с makeи Makefiles, а некоторые из командной строки управления версиями интерфейса ( svn, git, cleartool, hg, cvs...)

Зачем это делать?

Оболочки * nix (и другие оболочки ОС, fwiw) представляют собой очень глубокую и широкую рабочую среду. Кто-то может потратить годы, работая там и используя только очень маленький процент от вместимости снарядов.

Если вы не ожидаете, что человек а) будет работать с программой оболочки или б) будет администрировать систему из оболочки, то почему это имеет значение? Все, что будет сделано, будет на таком базовом уровне, что удобная шпаргалка * nix более чем компенсирует «недостаток навыков».

Вдобавок ко всему, я бы спросил их о двух вещах:

1. Когда вы ранее использовали командную строку * nix, сталкивались ли вы со случаем, когда хорошо продуманная команда сэкономила вам много времени? Если так, уточните.

2. Пожалуйста, объясните основные различия между командной строкой * nix и стандартным рабочим столом Windows. Каковы преимущества и недостатки каждого?

Понятно, что первое даст вам представление о том, насколько глубоки знания кандидата о командной строке. Если он годами работал над * nix, он не просто скажет вам, что гордится тем, что запустил grep. Не ожидайте, что они будут помнить точные команды конечно (для этого всегда есть man-страницы), но общее представление о том, что они сделали.

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

Зависит от того, что вы хотите, чтобы они сделали.

Для получения информации из лог-файлов, ваше предложение для cat + grep имеет смысл. Я бы добавил к этому ls, cd и less / more.

Если вы ожидаете, что они также сделают некоторые незначительные правки (скажем, в конфигурационных файлах), то имеет смысл добавить тестирование для vi и / или emacs и для таких вещей, как cp / mv / rm / mkdir.

Я бы порекомендовал им знать emacs или vi / m, tar, sed, e / f / grep, различные компиляторы, некоторые сценарии оболочки. Возможно, запустите тест, в котором они должны использовать эти инструменты, чтобы извлечь некоторый код из одного файла, не открывая его, вставить его в другую программу; затем скомпилируйте программу, которая остановится на какой-то тривиальной ошибке. Затем они должны использовать текстовый редактор, чтобы войти и найти ошибку, заставить работать код и заархивировать двоичный файл. Затем отправьте его по почте куда-нибудь, предоставив получателю разрешения на его запуск.

Я не знаю о вас, но я бы немного расстроился, если бы мой интервьюер спросил меня, а я не знал, как работать в Linux.

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

Это зависит от того, какой уровень опыта вы хотите, чтобы они имели. Если это не для кого-то, кто будет разрабатывать для систем * nix, а также не для системных администраторов * nix, а только для обычных разработчиков, которым иногда требуется некоторая работа в системе * nix, какой опыт им действительно нужен?

Все, что может понадобиться такому разработчику в * nix оболочках (ls, chmod, cat и т. Д.), Может быть написано на одной странице шпаргалки. Если это так, то, требуя знания оболочки * nix там, где это не требуется, можно исключить некоторых хороших кандидатов.

Я обычно выбираю простое задание и прошу человека написать скрипт на доске.

«У вас есть каталог« foo »и резервный каталог« foo_backup ». Напишите сценарий оболочки, чтобы увидеть, что изменилось в« foo »после изменения« foo_backup ».

«Объясните процесс входа в Linux так подробно, как вам удобно» - хороший вопрос. Процесс входа в систему включает переключение пользователей, прав доступа и владельцев, а также множество общих принципов Unix. Если они могут четко объяснить, как и почему есть /etc/passwdи /etc/shadow, и как непривилегированный пользователь может изменить свой собственный пароль, но не другие, это означает, что они «получают» Unix.

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

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

зачем заставлять их писать функциональную программу? что плохого в том, чтобы сказать «скажи мне разницу между grep и sed, или что делает команда X?» и т. д. таким образом, вы можете немного их привести.

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

У гуру Unix есть основные команды командной строки, такие как sed, grep и т. Д., И они могут легко использовать их для достижения того, чего они хотят, используя всевозможные кавычки, сложные регулярные выражения и т. Д., Поэтому иногда вы видите сценарий и думаете, что это будет легче понять, написано на китайском;)

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

Они будут знать внутреннюю конфигурацию системы Unix, поэтому, если вы попросите их изменить раскладку клавиатуры (fg добавьте некоторую привязку к правому alt +), они не будут смущены.

Управление установленными пакетами также не будет проблемой. Установка Oracle, запуск 4 серверов приложений, каждый с другой JVM - тоже не проблема. Конфигурация виртуальной сети, расширенная маршрутизация и фильтрация портов, виртуальные машины и т. Д., Управление безопасностью - также идет туда.