Я пытаюсь найти достойный ответ на этот вопрос интервью: «Что было самым сложным в моей последней роли?»
Я был в основном обезьяной виджета пользовательского интерфейса больше года в компании, очень мало изучив, кроме ReactJS. Я был в команде из 4 разработчиков. Нас наняли, чтобы исправить полностью сломанный беспорядок в плохом аутсорсинговом проекте.
Я многому научился в ReactJS, JavaScript, стандартах оформления кода, стандартах качества кода, но на этом все, и через 6 месяцев мне было до слез скучно. Это не подходило. Мне практически не разрешалось принимать самостоятельные решения, а если бы я и разрешил, то мне, скорее всего, пришлось бы переделывать это позже или столкнуться с критикой за то, как я это сделал. Но если бы я попытался говорить об этом в то время, когда это появилось, некоторых людей бы раздражало, что я не могу сделать выбор или мне придется ждать новых спецификаций и переключать передачи. Это действительно истощало. Я никогда не чувствовал, что мои предложения воспринимаются всерьез.
Что мне показалось сложным:
Некоторые сложные вещи, над которыми я работал, но у меня не было возможности сделать это в одиночку:
Вещи, которые я делал один, но не считал самыми сложными частями приложения:
Производительность против шаблона проектирования против ремонтопригодности Поскольку у нас было много вложенных виджетов ReactJS, иногда родительские компоненты только передавали данные дочерним компонентам. Если вы используете этот метод вместе с shouldComponentUpdate, код может стать непригодным для сопровождения, хотя это, вероятно, лучший способ решить проблему с точки зрения производительности. Решение заключалось в использовании контекста или создании других представлений пользовательского интерфейса в качестве «поставщиков данных». Я не придумал окончательного решения, но определил проблему и обсудил ее со старшими разработчиками.
Старшие разработчики сказали мне, что разрешения были самой сложной частью первой фазы проекта, но я не нашел ее сложной. В основном это было просто размышление о некоторых сложных спецификациях, а затем черновая работа.
Какой ответ я могу дать?
Вы можете интерпретировать слово «сложный» двояко: во-первых, перечислить то, что вы считаете трудным и, надеюсь, у вас не будет на новой работе, а во-вторых, перечислить то, в чем вы стали лучше в ходе работы. Я не рекомендую смешивать и сопоставлять эти два возможных определения. Вместо этого выберите один, расскажите интервьюеру, какое определение термина «вызов» вы используете, а затем перечислите несколько, по одному предложению в каждом.
Если пойти первым путем:
Несколько вещей на моей нынешней работе разочаровывают, и это одна из причин, по которой я ищу новую. Один паттерн, который часто встречался, заключался в том, что его просили начать до того, как были приняты все решения, и приходилось переделывать работу позже, когда спецификации были полностью поняты. Другой заключался в обнаружении проблем с производительностью, но не в возможности участвовать во внедрении исправлений. Я надеюсь, что на этой должности команды обмениваются информацией и [все, что вы хотите, отличается от этой работы.]
Если пойти вторым путем:
Когда я начинал, я мало что знал о ReactJS, JavaScript, стандартах стиля кода или стандартах качества кода, поэтому за время, которое я занимал в этой должности, я многому научился. Теперь я чувствую, что я [сильное заявление о том, что я много знаю или хорошо разбираюсь в технологиях, которых требует новая работа.]
Обратите внимание, как в каждом случае:
Акцент в ответе на этот вопрос должен быть сделан на том, как вы преодолели эту проблему. Выберите любой вызов, который позволяет вам это сделать.
Я бы остановился на №1 или №2. Предполагая, конечно, что вы действительно приобрели знания предметной области и изучили JavaScript и другие технологии, вы, вероятно, захотите рассказать о том, как вы это сделали; если вы выберете № 2, придерживайтесь «Меня бросили в глубь — и я смог плавать».
Не говорите что-то вроде «У меня не было никаких знаний в предметной области, поэтому я не мог делать предложения по пользовательскому интерфейсу» — упоминайте об этом только в том случае, если вы действительно преодолели эту проблему (т.е. вы узнали знание предметной области ) .
Я настоятельно рекомендую избегать № 3 и № 4, потому что это звучит так, как будто вы очерняете своего бывшего работодателя, который обычно считается непрофессиональным и, как правило, сильно отталкивает (потому что тогда они зададутся вопросом, что вы скажу о них , когда ты в итоге уйдешь, плюс ты можешь показаться нытиком).
Одра Куинн
Аллахджане
Юха Унтинен