Комментарии 199
устроился на вакансию с IT вообще никак не связанную. Через год планирую, поднабравшись знаний, снова начать поиски.
Имхо лучше ужаться по деньгам, посидеть без работы и догнать знания в режиме интенсива. Иначе есть вероятность прогореть за год.
и устроился на вакансию с IT вообще никак не связанную. Через год планирую, поднабравшись знаний, снова начать поиски.
Имхо через год выглядеть продажником, решившим сменить профессию, ещё хуже, чем джуниором без опыта.
Лучше ужаться по деньгам и поработать таки где-нибудь джуниором. Так опыт реальной работы год это гораздо ценнее, нежели чем год набираться каких-то абстрактных знаний.
Я был согласен на любую зарплату. Даже на 10000, был прецедент. Однако звёзды встали таким образом, что ни одна компания, ищущая джуниоров в период конец марта-начало мая меня не приняла, из чего делаю совершенно логичный вывод — мне не хватает знаний.
НЛО прилетело и опубликовало эту надпись здесь
Поправка, после получения опыта сразу переходите в компании. В компаниях вы получаете один из самых ценных опытов: Работа в команде. Это очень важный навык, которым владеют очень немногие.
Это мое личное мнение никак не связанное с мнением комментатора выше.
Ну во фрилансе вы тоже не обязательно один в поле. Сейчас, например, я работаю в команде из 7 человек, постоянно приходится переписываться то с клиентом, то с главным девелопером, то другим девелопером, то с новым девелопером которому отдали часть моей работы, даже с дизайнером.
Плюс, все из разных стран — клиент и дизайнер из США, главный девелопер из Сербии, другой девелопер из Молдавии, новый девелопер из Гонконга. Так что какой-никакой, но тоже опыт.
Плюс, все из разных стран — клиент и дизайнер из США, главный девелопер из Сербии, другой девелопер из Молдавии, новый девелопер из Гонконга. Так что какой-никакой, но тоже опыт.
Вы до этого работали в компании, или после вуза сразу с фриланса начали?
Это может прозвучать странно, но я не учился в вузе.
После колледжа немного поработал, а потом фриланс.
После колледжа немного поработал, а потом фриланс.
Даже так, круто! Но все же после первый опыт командной работы получили на своем первом месте?
Я к чему все это — я лично не представляю как бы в первый раз сходу начал бы с фриланса :)
Я к чему все это — я лично не представляю как бы в первый раз сходу начал бы с фриланса :)
А в чём проблема сходу начать с фриланса?
Очень много проблем. Начиная с того, как поймать заказ, когда вокруг полно таких же фрилансеров и к тому же занимающиеся этим фултайм жмакая каждую минуту F5, заканчивая таким банальным вопросом, как «сколько взять?». Или один я такой?
Ну эти вопросы работой в компании вряд ли решатся — в компании ловить заказ не надо, да и с «сколько взять» могут возникнуть проблемы, если вы на зарплате.
Универсального ответа на вопрос, как поймать заказ вряд ли есть. Просто откликайтесь на заказы с нормальным cover letter'ом, кто-нибудь да ответит.
Ещё, по-моему, не стоит зацикливаться на отосланных бидах. Увидел понравившийся, отправил и забыл. Увидел ещё, ещё отправил и забыл. Сидеть и думать, как там ваш бид, смысла особо нет. Как и не отправлять новый, руководствуясь тем, что уже отправил 30 на которые никто не ответил. Если вам ответят на старый бид, но вы будете уже заняты, то вообще не проблема написать, что мол извините, но я уже занят.
Универсального ответа на вопрос, как поймать заказ вряд ли есть. Просто откликайтесь на заказы с нормальным cover letter'ом, кто-нибудь да ответит.
Ещё, по-моему, не стоит зацикливаться на отосланных бидах. Увидел понравившийся, отправил и забыл. Увидел ещё, ещё отправил и забыл. Сидеть и думать, как там ваш бид, смысла особо нет. Как и не отправлять новый, руководствуясь тем, что уже отправил 30 на которые никто не ответил. Если вам ответят на старый бид, но вы будете уже заняты, то вообще не проблема написать, что мол извините, но я уже занят.
А чем не прокачка скилла. Сколько взять — вопрос часто нужный не только во фрилансе. Вернее, часто возникает вопрос «сколько дать, чтобы не переплатить, но и чтобы получить решение задачи». Умея решать этот вопрос со стороны исполнителя, будет легче ориентироваться и со стороны заказчика.
$20/час — многовато для junior'a без опыта.
На месте соискателя я бы дальше пытался устроиться — крупные компании берут на стажировку, можно и технологию сменить если будет желание.
И главное вас сейчас возьмут не за знание конкретной технологии, а за умение думать и быстро разбираться в новых технологиях(я бы так сделал).
На месте соискателя я бы дальше пытался устроиться — крупные компании берут на стажировку, можно и технологию сменить если будет желание.
И главное вас сейчас возьмут не за знание конкретной технологии, а за умение думать и быстро разбираться в новых технологиях(я бы так сделал).
А тут специфика php — нужны дешёвые кодеры… Вот Java, .Net, c/c++ — предпочитают брать джунов со знанием языка и умением думать и быстро разбираться. Но языки сложнее и требуют большей теоретической подготовки, да.
Можно подробнее?
Чем отличается Java от PHP в плане программирования?
Кроме строгой типизации и обязательности исключений?
Это довольно разные инструменты для разных задач.
Например в Web имея 100 файликов с информацией проще их достать на PHP и отдать по JSON. Тут с типами данных в файлах как то паралельно, если задача взять и отдать (какой нибудь array с ключами)
А вот на стороне клиента получить HasMap в Java и провести нужный анализ, GUI и т.д. — это уже другая задача.
Чем отличается Java от PHP в плане программирования?
Кроме строгой типизации и обязательности исключений?
Это довольно разные инструменты для разных задач.
Например в Web имея 100 файликов с информацией проще их достать на PHP и отдать по JSON. Тут с типами данных в файлах как то паралельно, если задача взять и отдать (какой нибудь array с ключами)
А вот на стороне клиента получить HasMap в Java и провести нужный анализ, GUI и т.д. — это уже другая задача.
Да много чем отличается. То что php проглотит — в java может просто не компилироваться.
Разница в подходе, разница в пороге вхождения, разница в задачах.
Вот простенькую страничку можно и разумно напилить на php, а вот веб-бекэнд — уже стоит задуматься о java или любом другом, более приспособленном к высокой сложности систем, языке.
Можно, конечно, возразить, что есть и на php крупные проекты — действительно есть, но цена поддержки и разработки таких систем для php возрастает быстрее, чем на других языках (VK и FaceBook уже свои диалекты языка запилили).
Разница в подходе, разница в пороге вхождения, разница в задачах.
Вот простенькую страничку можно и разумно напилить на php, а вот веб-бекэнд — уже стоит задуматься о java или любом другом, более приспособленном к высокой сложности систем, языке.
Можно, конечно, возразить, что есть и на php крупные проекты — действительно есть, но цена поддержки и разработки таких систем для php возрастает быстрее, чем на других языках (VK и FaceBook уже свои диалекты языка запилили).
я просил примеры не связанные со строгой типизацией ) (наличием компилятора и т.д.)
Ну так задайте вопрос подробнее: на общий вопрос — общий ответ. ;-)
Я считаю что программирование отличается только строгой типизацией и неопределенным поведением при некоторых неопределенных операциях.
Всё.
Хотел услышать от вас что не так с PHP
А порог вхождения один и тот же.
Всё.
Хотел услышать от вас что не так с PHP
А порог вхождения один и тот же.
- Меньше стандартов,
- Быстрее виден результат,
- Требуется меньше теории
== порог вхождения один и тот же?
Вопрос один меня мучает — вы на какой языке программируете-то?
Список за последний месяц:
AVR asm
AVR C
C++ (до 11)
java
php
js (JQuery)
Bash (shell)
Основной PHP(серверная часть)+Java(Клиент)
AVR asm
AVR C
C++ (до 11)
java
php
js (JQuery)
Bash (shell)
Основной PHP(серверная часть)+Java(Клиент)
Т.е. с Java на бэкэнде вы не работаете? Чисто j2se? В то время когда php — это бекэнд с кучей надстроек (фреймворков) и стандартов? Тогда ваше мнение понятно.
Впрочем с равным порогом вхождения я всё равно не согласен.
Впрочем с равным порогом вхождения я всё равно не согласен.
Уж простите, может я и заложник шаблонов, но такой набор языков, да в течении месяца, да не являясь программистом, да, как следует из комментария ниже, уйдя в возрасте 17 лет «на первую попавшуюся любую»… интересно посмотреть на ваш код. Либо степень программирования на каждом языке заключается в «подпатчивании в пару местах», либо жуткий фарш.
Даже просто зная несколько языков (я о лингвистике) тяжело в короткий промежуток времени переключаться с одного на другой и на третий в произвольном порядке. Да и программирование, плюс ко всему, «Вам не шахматы — тут думать надо».
Даже просто зная несколько языков (я о лингвистике) тяжело в короткий промежуток времени переключаться с одного на другой и на третий в произвольном порядке. Да и программирование, плюс ко всему, «Вам не шахматы — тут думать надо».
за один день очень сложно даже на 2х писать
в разные дни на разных — пофиг.
Нарисовал себе UML диаграмки, в тетради набросал алгоритмы/автоматы, и пиши себе потихоньку.
я не работаю в команде, по этому не могу не знать что такое «хороший код».
Есть задача, она решается, практика показывает, что мои решения работают годами без сбоев.
Получается что то в этом роде
habrastorage.org/files/643/fb5/4ac/643fb54ac9444b7896a646e2544ae2dc.png
в разные дни на разных — пофиг.
Нарисовал себе UML диаграмки, в тетради набросал алгоритмы/автоматы, и пиши себе потихоньку.
я не работаю в команде, по этому не могу не знать что такое «хороший код».
Есть задача, она решается, практика показывает, что мои решения работают годами без сбоев.
Получается что то в этом роде
habrastorage.org/files/643/fb5/4ac/643fb54ac9444b7896a646e2544ae2dc.png
У меня как-то был очень интересный период, когда занимался разработкой сразу двух проектов. Точнее разработкой одного (c++, python) и поддержкой другого (php, js). Не сказать что было сильно сложно, но то function забудешь написать, то доллар перед переменной поставить. Спасибо IDE что не дают так легко это сделать.
я не работаю в команде, по этому не могу не знать что такое «хороший код».
Тут, видимо, опечатка закралась. По логике вещей, если не работаете в команде, то "
вы правы
А если в команде никто не знает? Или даже если и знает, то не хочет? Наличие команды еще ничего не дает. Есть масса литературы, статей и т.д. Есть митапы, конференции и прочее. Сейчас как мне кажется все эти дешевые отговорки вообще смысла не имеют.
Как был пример выше
Оцените ваш код от 0 до 10……
Мы узнали что мы можем назвать любое число от 0 до 10
Я знаю что местами он хороший, местами плохой. Доказывать это не вижу смысла.
Когда приходится поддерживать плохой код переписывается.
Есть конечно плохой код, который живет уже 8 лет. Но живет себе спокойно и ни кому не мешает.
Что такое рефакторинг и т.д. и как делать хорошо я знаю.
Хотите взять на работу — открою код.
Оцените ваш код от 0 до 10……
Мы узнали что мы можем назвать любое число от 0 до 10
Я знаю что местами он хороший, местами плохой. Доказывать это не вижу смысла.
Когда приходится поддерживать плохой код переписывается.
Есть конечно плохой код, который живет уже 8 лет. Но живет себе спокойно и ни кому не мешает.
Что такое рефакторинг и т.д. и как делать хорошо я знаю.
Хотите взять на работу — открою код.
del
Немного не согласен, java и php языки разные, в этом нет сомнения и спору, но вот в пороге вхождения это явно миф. Нет конечно «hello word» написать на php, предварительно скачав денвер быстрее, это да, но все остальное. Я помню как я метался в студенчестве от языка к языку, ядро знаний набитое на паскале уже было заточено под строгую типизацию, да я даже тогда заранее динамических размеров массив не знал как создать. Потом все это ООП, базы данных, кодировки, стринг билдеры, не строго типизированные переменные (php) и прочее просто нарастало вокруг того базиса который у меня был. Я бы не сказал, что начав писать когда на java после php я внезапно увидел что тут все НАСТОЛЬКО сложно и пошел спать, нет все было не так. Да конечно сложности есть, но они не уникальны, чем изучение тонкостей java отличается от тонкостей php + потом yii + потом zend + потом drupal + потом wordpress? Да ничем, везде есть над чем голову поломать.
P.S.: Знавал я одну конторку в которой писали порталы на java. Ну как на java, ребята знали чисто пару тегов jstl, использовали простейшие переменные, простейшие циклы, если я не ошибаюсь они даже массивов не использовали и все логические операции делали на js на клиентской стороне. Но при этом они всем гордо заявляли о том что они не какие то php`шники, а крутые java девелоперы.
P.S.: Лично я считаю что если человек не дурак то он выучит любой язык не особо напрягаясь.
P.S.: Знавал я одну конторку в которой писали порталы на java. Ну как на java, ребята знали чисто пару тегов jstl, использовали простейшие переменные, простейшие циклы, если я не ошибаюсь они даже массивов не использовали и все логические операции делали на js на клиентской стороне. Но при этом они всем гордо заявляли о том что они не какие то php`шники, а крутые java девелоперы.
P.S.: Лично я считаю что если человек не дурак то он выучит любой язык не особо напрягаясь.
Это не миф, хотя и согласен с тем, что порог вхождения в java тоже не самый высокий (вот hex-коды… это да :)
Знаете, что означает на самом деле «порог вхождения»? Он состоит из нескольких компонент:
— насколько легко/быстро можно увидеть результат (тут скрипты всегда в выигрыше),
— сколько отвлечённых знаний нужно, чтобы понять язык. Для php список поменьше будет.
Не надо сравнивать java vs php + yii + zend + drupal + wordpress. Тогда логичнее сравнить с java + spring + spring-security + j2ee + куча прочих фреймворков и стадартов + magnolia + куча прочих cms.
PS ну вы же сами прекрасно видите, что это не работа на java. А понты есть везде. Их можно легко игнорировать/опустить (по вкусу).
PS выучит или поймёт? Я вот lisp в своё время выучил, но не понял… Толку? Только нелюбовь к функциональщине возникла.
Знаете, что означает на самом деле «порог вхождения»? Он состоит из нескольких компонент:
— насколько легко/быстро можно увидеть результат (тут скрипты всегда в выигрыше),
— сколько отвлечённых знаний нужно, чтобы понять язык. Для php список поменьше будет.
Не надо сравнивать java vs php + yii + zend + drupal + wordpress. Тогда логичнее сравнить с java + spring + spring-security + j2ee + куча прочих фреймворков и стадартов + magnolia + куча прочих cms.
PS ну вы же сами прекрасно видите, что это не работа на java. А понты есть везде. Их можно легко игнорировать/опустить (по вкусу).
PS выучит или поймёт? Я вот lisp в своё время выучил, но не понял… Толку? Только нелюбовь к функциональщине возникла.
А можно конкретнее что вы не поняли в LISP?
Я понял бы, если речь шла про какой нибудь пролог для нейронных сетей.
А тут перебор, в чистом виде синтаксис и алгоритмистика. Или я ошибаюсь?
Я понял бы, если речь шла про какой нибудь пролог для нейронных сетей.
А тут перебор, в чистом виде синтаксис и алгоритмистика. Или я ошибаюсь?
Я не так давно натолкнулся на вопрос на тостере, о том какой язык лучше выбрать в начале, и я там тоже понаписал кучу примеров доказывающих, что нет разницы, но другой человек написал очень лаконичный ответ, который я не смог сформулировать, но он точно выражал мои мысли. Программирование это не знание языка, это образ мышления, умение решать определенные задачи и писать алгоритмы. А язык это всего лишь инструмент.
Про увидеть результат, немного не согласен, на самом деле если следовать четко и верно написанной инструкции (ну либо имея свои знания если ты не джуниор) и имея уже настроенное окружение, то увидеть результат и на java можно очень быстро.
Про отвлеченные знания поясните, что вы имеете ввиду, я немного не понял.
Ну здесь я согласен, что у java тоже не только java есть, но согласитесь, что архитектура технологий внутри языка тоже требует изучения и не поверю если вы скажите, что решения на java черт ногу сломит, а на php вчерашний филолог все поймет за 5 минут (разумеется я предполагаю, что изучение того же drupal это изучение api и прочей начинки, а не накликать сайт за 5 минут)
Да согласен, но ведь они разрабатывали на java, да не так как это должно быть, но это был ее стек технологий.
Ну тут тоже немного не ясно, чем понимание php сложнее чем понимание java? Java это же не какой нибудь Prolog где реально другой подход.
Про увидеть результат, немного не согласен, на самом деле если следовать четко и верно написанной инструкции (ну либо имея свои знания если ты не джуниор) и имея уже настроенное окружение, то увидеть результат и на java можно очень быстро.
Про отвлеченные знания поясните, что вы имеете ввиду, я немного не понял.
Ну здесь я согласен, что у java тоже не только java есть, но согласитесь, что архитектура технологий внутри языка тоже требует изучения и не поверю если вы скажите, что решения на java черт ногу сломит, а на php вчерашний филолог все поймет за 5 минут (разумеется я предполагаю, что изучение того же drupal это изучение api и прочей начинки, а не накликать сайт за 5 минут)
Да согласен, но ведь они разрабатывали на java, да не так как это должно быть, но это был ее стек технологий.
Ну тут тоже немного не ясно, чем понимание php сложнее чем понимание java? Java это же не какой нибудь Prolog где реально другой подход.
Н. Вирт
Программы = Алгоритмы + Структуры данных
Программы = Алгоритмы + Структуры данных
1. А разница с какого языка начинать — есть ;)
А вот подсказать с какого лучше — это надо крепко подумать, но однозначно не php/js — слишком низкий порог вхождения. Первый язык надолго закладывает свою парадигму в голову и начать мыслить в других парадигмах требует осознанного усилия.
2. Полторы минут компиляции (спасибо Kaspersky, без него 40 секунд) и 2 минуты на запуск сервера… Это очень быстро? А результаты бывают и хуже. Всё зависит от конкретного юзкейса. Для чистого php перезапуск не требуется, так что сразу можно посылать запрос.
3. В php можно не догадываясь о ООП писать, есть и другие теоретические области знания, которые очень важны в java, но могут игнорироваться в php не превращая программирование в быдлокодинг. Впрочем тут больше от задачи зависит.
4. Зато вчерашний филолог быстрее сможет внести небольшую правку в php, нежели в java.
5. Нет, они разрабатывали jsp/jstl. Это не полная java.
6. А в php уже выпилили процедурную парадигму? Или в Java её запилили? Ну и не помню я, чтобы говорил, что «понимание php сложнее чем понимание java»
А вот подсказать с какого лучше — это надо крепко подумать, но однозначно не php/js — слишком низкий порог вхождения. Первый язык надолго закладывает свою парадигму в голову и начать мыслить в других парадигмах требует осознанного усилия.
2. Полторы минут компиляции (спасибо Kaspersky, без него 40 секунд) и 2 минуты на запуск сервера… Это очень быстро? А результаты бывают и хуже. Всё зависит от конкретного юзкейса. Для чистого php перезапуск не требуется, так что сразу можно посылать запрос.
3. В php можно не догадываясь о ООП писать, есть и другие теоретические области знания, которые очень важны в java, но могут игнорироваться в php не превращая программирование в быдлокодинг. Впрочем тут больше от задачи зависит.
4. Зато вчерашний филолог быстрее сможет внести небольшую правку в php, нежели в java.
5. Нет, они разрабатывали jsp/jstl. Это не полная java.
6. А в php уже выпилили процедурную парадигму? Или в Java её запилили? Ну и не помню я, чтобы говорил, что «понимание php сложнее чем понимание java»
Нет разницы на каком языке практиковать написание алгоритмов. Но да, каждый должен попробовать пописать на Си.
Написание алгоритмов можно и на псевдоязыке практиковать… А вот программировать придётся на реальном.
Есть еще вопрос мотивации. То есть если вы будете описывать алгоритмы блок схемами, на псевдокоде, словом, не видя реального результата… Это не так весело. Так что отрабатывать написания алгоритмов лучше с возможностью быстренько проверить работоспособность сего, иначе станет скучно и снизится желание этим заниматься дальше.
1. Мне все же кажется это субъективно, тем более что начало это начало, вы там не ОС пишете, простенькие алгоритмы которые почти везде одинаково пишутся.
2. Опять же субъективно, помню ту кучу вопросов и проблем для решения которые у меня были на старте, 2-3 минуты на запуск приложения это сущие пустяки на этом фоне.
3. Не поверите но на Java тоже можно писать не догадываясь о ООП, создайте всего один класс, представите, что методы это функции, свойства это переменные, конструктор просто тело программы, о наследовании тоже можно не знать)
4. Аргументируете (напомню мы в этом пункте обсуждаем не просто hello word, а код целых фреймворков и cms)?
5. Не полная, но ведь java.
6. Нет конечно, не выпилили и не запилили, но понимание ООП не на много сложнее простой процедурки. «Но языки сложнее и требуют большей теоретической подготовки» — это ваши слова.
Вообще как не крути не понимая я жалоб на тяжелые пороги вхождения в контексте php, java, c++. Вот у ассемблера тяжелый порог, я как то день убил на то что бы просто текст с клавы в переменную загнать, а вы говорите 2 минуты на компиляцию))
2. Опять же субъективно, помню ту кучу вопросов и проблем для решения которые у меня были на старте, 2-3 минуты на запуск приложения это сущие пустяки на этом фоне.
3. Не поверите но на Java тоже можно писать не догадываясь о ООП, создайте всего один класс, представите, что методы это функции, свойства это переменные, конструктор просто тело программы, о наследовании тоже можно не знать)
4. Аргументируете (напомню мы в этом пункте обсуждаем не просто hello word, а код целых фреймворков и cms)?
5. Не полная, но ведь java.
6. Нет конечно, не выпилили и не запилили, но понимание ООП не на много сложнее простой процедурки. «Но языки сложнее и требуют большей теоретической подготовки» — это ваши слова.
Вообще как не крути не понимая я жалоб на тяжелые пороги вхождения в контексте php, java, c++. Вот у ассемблера тяжелый порог, я как то день убил на то что бы просто текст с клавы в переменную загнать, а вы говорите 2 минуты на компиляцию))
В ассемблере не столько тяжелый порог вхождения, сколько отсутствие наработанных инструментов и библиотек, которые есть в языках высокого уровня.
Не спорю, но для меня было очень тяжело, то что ты пишешь тестовый пример, а он не работает, пишешь второй он тоже не работает, гуглишь ошибку, исправляешь по совету с форума, оно опять не работает. То есть я еще в самом начале изучения, вообще о языке ничего не знаю, а передо мной уже стоит задача о дебаге нерабочего кода.
У меня assembler (x86) был 10 лет назад
дебажить ассемблер — одно удовольствие
Что ты написал, то и дебажишь :)
Знания минимальные
смотришь что в регистрах, смотришь что в стеке.
Как кубики собирать :)
дебажить ассемблер — одно удовольствие
Что ты написал, то и дебажишь :)
Знания минимальные
смотришь что в регистрах, смотришь что в стеке.
Как кубики собирать :)
Я сначала изучил Visual Basic
Потом assembler
Почему у вас возникли сложности?
Используем api bios или os — 16h? и 21h(dos) соответственно.
Причем на разные подсистемы у bios разные прерывания.
Закинули что и куда нужно, вызвали int 21h, забрали результат.
Потом assembler
Почему у вас возникли сложности?
Используем api bios или os — 16h? и 21h(dos) соответственно.
Причем на разные подсистемы у bios разные прерывания.
Закинули что и куда нужно, вызвали int 21h, забрали результат.
1. Разница есть — язык прививает мышление и привычки. JS и PHP плохи тем, что они очень не требовательны к оформлению => не формируется понятие о code-style на начальном этапе вообще никак.
2. Сравните 2-3 минуты на запуск приложения у новичка и 3-4 минуты на запуск у разработчика, ага? Кстати, для того, чтобы получить полторы минуты компиляции я не слабо так переработал мавен-проект — на момент применения изменений, несмотря на добавление двух дополнительных операций в процесс сборки мне удалось снизить время сборки на 30%. С тех пор добавилось несколько компонент и время сборки снова выросло (а ещё сменилась версия каспера и время сборки резко увеличилось).
3. Нет, не догадываясь невозможно — как минимум один класс создать придётся. Конечно можно всячески нарушать и игнорировать принципы ООП, но вот public class будет маячить перед глазами всё равно.
4. Легко — мой отец (электрик) ковырялся с друпалом — скачал какой-то пробный модуль, он не завёлся — он его поковырял, основываясь на инфе нарытой в интернете и заставил работать (несколько строк кода изменил). С Java сможете аналогичный пример привести?
5. Разработкой на java это называть уже нельзя.
6. А вы привели доказательство обратного? Ещё раз повторюсь — в зависимости от задачи на java требуются различные дополнительные теоретические знания, тот же ООП — всегда, для php просто нет такого спектра задач! А имеющиеся зачастую требуют меньшего объёма теоретических знаний (ибо условно-обязательных стандартов меньше).
Ну это вы сами лопухнулись. У нас были по ассемблеру лабы на 2ом курсе — я в hiew (ну не подружился я с masm) лабы склепал за час (там тоже была обработка клавиатуры, ввод-вывод и ещё что-то). А на приведение в порядок скрипта сборки я убил 3 дня ;-) После этого удалось сборку версий запихнуть в teamcity (ещё за полтора дня).
2. Сравните 2-3 минуты на запуск приложения у новичка и 3-4 минуты на запуск у разработчика, ага? Кстати, для того, чтобы получить полторы минуты компиляции я не слабо так переработал мавен-проект — на момент применения изменений, несмотря на добавление двух дополнительных операций в процесс сборки мне удалось снизить время сборки на 30%. С тех пор добавилось несколько компонент и время сборки снова выросло (а ещё сменилась версия каспера и время сборки резко увеличилось).
3. Нет, не догадываясь невозможно — как минимум один класс создать придётся. Конечно можно всячески нарушать и игнорировать принципы ООП, но вот public class будет маячить перед глазами всё равно.
4. Легко — мой отец (электрик) ковырялся с друпалом — скачал какой-то пробный модуль, он не завёлся — он его поковырял, основываясь на инфе нарытой в интернете и заставил работать (несколько строк кода изменил). С Java сможете аналогичный пример привести?
5. Разработкой на java это называть уже нельзя.
6. А вы привели доказательство обратного? Ещё раз повторюсь — в зависимости от задачи на java требуются различные дополнительные теоретические знания, тот же ООП — всегда, для php просто нет такого спектра задач! А имеющиеся зачастую требуют меньшего объёма теоретических знаний (ибо условно-обязательных стандартов меньше).
Ну это вы сами лопухнулись. У нас были по ассемблеру лабы на 2ом курсе — я в hiew (ну не подружился я с masm) лабы склепал за час (там тоже была обработка клавиатуры, ввод-вывод и ещё что-то). А на приведение в порядок скрипта сборки я убил 3 дня ;-) После этого удалось сборку версий запихнуть в teamcity (ещё за полтора дня).
Последние версии самого PHP и некоторых фреймворков очень много позаимствовали именно из Java и его экосистемы. Собственно, емнип, PHP единственный популярный скриптовый язык, идущий в направлении энтерпрайза, а не RAD — почти статическая типизация нескаляров, контроль видимости членов классов, интерфейсы, абстрактные классы и т. п. — при этом сохраняя присущую изначально гибкость.
Под PHP есть две категории джунов. CMS-разработка, тут да. А есть еще нормальная backend-разработка, где уже нужно знать язык нормально, иметь базу хоть какую-то… Словом, не сказал бы багаж необходимых знаний для JAVA-джуниора сильно отличается от PHP-джуниора. Во всяком случае далеко не для каждой вакансии.
Что такое CMS разработка?
Что такое «знать язык»? Его API, библиотеки?
Правило простое. Есть сомнения что делаешь много работы — лезь в API.
нет в API, ищи библиотеку.
Много переборов в циклах — лезь в API, они написаны например на «С»
А дальше вопрос проектирования системы.
А всякие каллейбл и итерейбл это не знания языка, это больше знания проектирования.
Что такое «знать язык»? Его API, библиотеки?
Правило простое. Есть сомнения что делаешь много работы — лезь в API.
нет в API, ищи библиотеку.
Много переборов в циклах — лезь в API, они написаны например на «С»
А дальше вопрос проектирования системы.
А всякие каллейбл и итерейбл это не знания языка, это больше знания проектирования.
CMS-разработка — массовая разработка на каких wordpress/joomla и т.д.
Пожалуй не знать язык, а уметь им пользоваться. API можно всегда подсмотреть, заучивать названия функций или какие аргументы и в каком порядке передавать я лично смысла не особо вижу, голову можно забить более полезными вещами.
Мне кажется вы сильно упрощаете эти правила. Они в большинстве случаев либо не работают, либо люди до него не дошли.
callable/iterable это больше относится к незнанию средств языка, но в контексте вопроса незнание оного не так страшно. К вопросам проектирования скорее относятся самые базовые принципы, которые вообще не привязаны к языку программирования. Например сильная/слабая связанность системы и какое это отношение имеет к MVC, SOLID и как слабая связанность помогает улучшить масштабируемость систем, когда лучше применять сильное связывание и т.д.
Пожалуй не знать язык, а уметь им пользоваться. API можно всегда подсмотреть, заучивать названия функций или какие аргументы и в каком порядке передавать я лично смысла не особо вижу, голову можно забить более полезными вещами.
Мне кажется вы сильно упрощаете эти правила. Они в большинстве случаев либо не работают, либо люди до него не дошли.
callable/iterable это больше относится к незнанию средств языка, но в контексте вопроса незнание оного не так страшно. К вопросам проектирования скорее относятся самые базовые принципы, которые вообще не привязаны к языку программирования. Например сильная/слабая связанность системы и какое это отношение имеет к MVC, SOLID и как слабая связанность помогает улучшить масштабируемость систем, когда лучше применять сильное связывание и т.д.
Про слабую связанность могу сказать сразу.
О ней можно почитать, но ты не поймешь нахрена она нужна, пока тебе не попадется огромный проект, а он может попасться только на работе, на которую тебя не берут, пока ты не узнаешь что такое слабая связанность. :)
О ней можно почитать, но ты не поймешь нахрена она нужна, пока тебе не попадется огромный проект, а он может попасться только на работе, на которую тебя не берут, пока ты не узнаешь что такое слабая связанность. :)
Почему все думают что опыта можно набраться только работая за деньги? Есть Opensource проекты, где тебе и бесплатный code-review будет если проект интересный, и в резюме плюсик. Можно в конечном счете присоединиться к какому-нибудь проектику небольшому и делать pull-реквесты.
А кушать тоже код? o_0
После работы, пару часов в день. Так же вполне нормально держать где-нибудь на такой вот переломный момент парочку (лучше 5-6) зарплат, что бы не умереть с голоду.
и за 5-6 месяцев по 2 часа в день вы станете хорошим программистом? И получите много опыта? Странно это.
по 2 часа в день не уходя с основной работы, и по сколько можно живя на эти отложенные ЗП. Пол года активной разработки (за деньги или нет) вполне достаточно что бы дорасти до джуниора. А если повезет с проектом, будут знакомые и т.д. можно и быстрее. Но это не исключает необходимости иметь какой-то базы.
Есть забавный факт
Никогда не слышал про SOLID, но знаю и стараюсь соблюдать все принципы SOLID, не подозревая о том, что это SOLID...)
Никогда не слышал про SOLID, но знаю и стараюсь соблюдать все принципы SOLID, не подозревая о том, что это SOLID...)
Да, такое частенько случается. Да и если и знают, если просто спросить «Знаешь о принципе подстановки Барбары Лисков»? и человек в ступоре довольно часто.
Это так же с предметом «Стандартизация и спецификация» (как то так)
Мы проходили то, что «все гайки сделаны по стандарту, по этому есть стандартные ключи»
Для любого Советского ребенка это само собой разумеющееся было и подумать об обратном в голову не приходило.
Такая же фигня с принципом Парето.
9 из 10 моих знакомых знают правило 20/80, 3 из 10 вывели его сами в процессе взросления/получения опыта
А то что это именно ОН — знают человека 1-2.
Мы проходили то, что «все гайки сделаны по стандарту, по этому есть стандартные ключи»
Для любого Советского ребенка это само собой разумеющееся было и подумать об обратном в голову не приходило.
Такая же фигня с принципом Парето.
9 из 10 моих знакомых знают правило 20/80, 3 из 10 вывели его сами в процессе взросления/получения опыта
А то что это именно ОН — знают человека 1-2.
odesk, elance, да хоть на форумах по программированию можно заказы собирать, тогда можно и изучать что-то и некоторую сумму зарабатывать.
Я был согласен на любую зарплату. Даже на 10000, был прецедент.
Недавно помню статья попадалась, что вилка зарплат подразумевает в том числе и нижнюю границу, то есть меньше определенной суммы вас тоже на работу не возьмут, т.к. просите «подозрительно мало».
НЛО прилетело и опубликовало эту надпись здесь
нет
Если человеку нужны деньги, пусть работает кем хочет
Я в свое время так же искал работу.
Знал в свои 17 (без вышки) целую линейку языков начиная от ассемблера и заканчивая C++, имел несколько программ.
Работу программистом не нашел в то время.
Пошел «на первую попавшуюся любую»
В этом году праздную 10 лет в своей отрасли. 8 из которых руковожу своими отделами. Была своя организация.
У человека довольно не плохо получается систематизировать знания. Ему это поможет в любой сфере.
А продажи это хорошо. Периодически такие топорные HRы попадаются, что нужно себя продать, а потом уже говорить о проф навыках.
Впервые за 10 лет подумываю кардинально сменить род деятельности и уйти наконец в программисты.
Из опыта программирования имею несколько построенных систем проверенных временем, кучу обученных людей (и программированию в том числе), имею представление о workflow по созданию проекта с 2х сторон (заказчик/исполнитель). Подрабатывал сингл разработчиком и разработчиком в команде.
А с таким предвзятым отношением про «продажника» и как он будет выглядеть — жить нельзя. Для этого и дают тестовые задания.
Ну а если еще к работе подходить «ему 25 лет, а знает он на 23», то это уже и в какие ворота не лезет.
Если человеку нужны деньги, пусть работает кем хочет
Я в свое время так же искал работу.
Знал в свои 17 (без вышки) целую линейку языков начиная от ассемблера и заканчивая C++, имел несколько программ.
Работу программистом не нашел в то время.
Пошел «на первую попавшуюся любую»
В этом году праздную 10 лет в своей отрасли. 8 из которых руковожу своими отделами. Была своя организация.
У человека довольно не плохо получается систематизировать знания. Ему это поможет в любой сфере.
А продажи это хорошо. Периодически такие топорные HRы попадаются, что нужно себя продать, а потом уже говорить о проф навыках.
Впервые за 10 лет подумываю кардинально сменить род деятельности и уйти наконец в программисты.
Из опыта программирования имею несколько построенных систем проверенных временем, кучу обученных людей (и программированию в том числе), имею представление о workflow по созданию проекта с 2х сторон (заказчик/исполнитель). Подрабатывал сингл разработчиком и разработчиком в команде.
А с таким предвзятым отношением про «продажника» и как он будет выглядеть — жить нельзя. Для этого и дают тестовые задания.
Ну а если еще к работе подходить «ему 25 лет, а знает он на 23», то это уже и в какие ворота не лезет.
Серьёзно, HR, почему вы не можете потратить пять минут на человка, который потратил на вас день?
Отрасль РНР-Джуниор — это океан и есть подозрение что выбрать 1 кандидата из океана задача не проста не только для соискателя но и для того кто ищет!
Я могу порекомендовать такой маневр:
— Не лезьте в общие вещи, типа РНР могу все! Определитесь что конкретно вы можете/хотите делать!
— Выбрать движок/фреймворк, который и учите.
То есть, пока вы сосредоточились на узкой специализации, вы себе делаете круг общения из людей которые здесь варятся и их не много, поэтому вы знаете друг друга в аватару (в случае общего РНР — вы один из тысячи и ваше общение будет всегда с новыми людьми и вы для всех новый).
Следующий момент, так как круг узкий то в этом кругу плавают и свои компании с которыми вы познакомитесь даже не ищя их, они вас сами найдут!
Для вас проще хорошо выучить один фреймворк, чем кучу CMS/фрейморков, где вы будете «так себе».
Кстати, чем меньше специалистов по узкой отрасли тем больше у них зарплаты!
Вообщем я веду к тому что чем уже круг, тем вам проще найти работу!
Отрасль РНР-Джуниор — это океан и есть подозрение что выбрать 1 кандидата из океана задача не проста не только для соискателя но и для того кто ищет!
Я могу порекомендовать такой маневр:
— Не лезьте в общие вещи, типа РНР могу все! Определитесь что конкретно вы можете/хотите делать!
— Выбрать движок/фреймворк, который и учите.
То есть, пока вы сосредоточились на узкой специализации, вы себе делаете круг общения из людей которые здесь варятся и их не много, поэтому вы знаете друг друга в аватару (в случае общего РНР — вы один из тысячи и ваше общение будет всегда с новыми людьми и вы для всех новый).
Следующий момент, так как круг узкий то в этом кругу плавают и свои компании с которыми вы познакомитесь даже не ищя их, они вас сами найдут!
Для вас проще хорошо выучить один фреймворк, чем кучу CMS/фрейморков, где вы будете «так себе».
Кстати, чем меньше специалистов по узкой отрасли тем больше у них зарплаты!
Вообщем я веду к тому что чем уже круг, тем вам проще найти работу!
… результатом двухмесячного поиска…
- в той или иной мере был контакт с 20+ работодателями
- выполнено 12 тестовых заданий
- пройдено 8 собеседований с техническими специалистами
печаль, может стоит усердно поработать над собой?
Через год планирую
начинайте работать над собой сейчас
Лучший способ что-то выучить — сделать стартап © Неизвестный говнокодер
Скажите, а как работодатели реагируют на то, что человек 30 левела претендует на замещение вакансии джуниора? Из-за возраста проблем не возникало?
Возраст не так важен, как опыт. И мало вероятно, что опытный специалист(если 30 лвл подходит в эту категорию) захочет получать меньше, чем предлагает рынок.
А так, подумайте сами: платить 500$ уже опытному человеку или новичку.
А так, подумайте сами: платить 500$ уже опытному человеку или новичку.
У нас есть компании которые джуниорам платят и по 150-200, зато берут всех кого только могут.
Ну не знаю даже. (о возрасте)
Мне 20, работаю в небольшой конторе на несколько команд, был у меня один человек, которому было ~40 и скорость его прокачки была значительно ниже, чем у ребят, которые моложе.
Да и было заметно, что взрослому мужику не очень нравилось, что мелочь всякая ему показывала/указывала и т.д.
В итоге дядя продержался пару месяцев.
Хотя люди разные бывают, это да.
Мне 20, работаю в небольшой конторе на несколько команд, был у меня один человек, которому было ~40 и скорость его прокачки была значительно ниже, чем у ребят, которые моложе.
Да и было заметно, что взрослому мужику не очень нравилось, что мелочь всякая ему показывала/указывала и т.д.
В итоге дядя продержался пару месяцев.
Хотя люди разные бывают, это да.
Сам удивляюсь, но нет, не возникало. По крайней мере не озвучивалось.
Извините, может пропустил этот момент, но как долго Вы кодите на php+…?
Прежде, чем пошел на позицию .NET Junior, пару лет ушло на книги/кодинг/фреймворки/тех. английски и чуть-чуть фриланса. Без этого просто не представляю, как можно работать.
Прежде, чем пошел на позицию .NET Junior, пару лет ушло на книги/кодинг/фреймворки/тех. английски и чуть-чуть фриланса. Без этого просто не представляю, как можно работать.
Главное что должен знать джуниор — знать куда идти работать. Идти в компании где от джуниора хотят больших знаний — бред, они сразу дают сигнал, что не собираются вас учить. Идти нужно туда, где будут учить, плевать даже на меньшую зарплату, сами вы будете и год и пять учиться, потому что будете узнавать отовсюду по немного, но из-за нехватки структурности знания будут вымываться через месяц.
Самое главное требование от джуниора — уметь доводить дело до конца и поевать сколько у него знаний, ТС отложил на год, то что нельзя откладывать даже на завтра. Печаль.
Самое главное требование от джуниора — уметь доводить дело до конца и поевать сколько у него знаний, ТС отложил на год, то что нельзя откладывать даже на завтра. Печаль.
Могу посоветовать автору (и другим начинающим разработчикам) одну методику, которую когда-то применял сам. Нужно зарегистрироваться на нескольких форумах программистов и начать отлавливать разные темы с просьбами помочь. Эти задачи — то, с чем сталкиваются такие же начинающие разработчики. Надо стараться решать их и смотреть, какие решения предлагают другие. Это поможет расширить «горизонты» и набить руку.
Кроме того, хорошо бы поискать подельников и организовать какой-нибудь проект на хорошем фреймворке. Может получиться хороший опыт работы в команде. На выходе будет и опыт разработки, и может даже то, о чем не стыдно будет сказать на собеседовании.
Удачи в трудоустройстве.
Кроме того, хорошо бы поискать подельников и организовать какой-нибудь проект на хорошем фреймворке. Может получиться хороший опыт работы в команде. На выходе будет и опыт разработки, и может даже то, о чем не стыдно будет сказать на собеседовании.
Удачи в трудоустройстве.
Ваши знания PHP как такового интересуют весьма незначительную часть работодателей
Я не был ни на одном собеседовании, но, по моему, это вообще несерьёзный подход.
При наличии базиса программист всегда сможет разобраться не только в новомодном фреймворке, но и в другом языке — если нужно. А так выходит «специалист по программированию в MS Excel», который теряется при виде Libre Office Calc.
НЛО прилетело и опубликовало эту надпись здесь
джуниор плохо знающий php, но хорошо знающий фреймворк
Опять же, я не специалист, но звучит как бред — «джуниор плохо знающий алфавит, но хорошо знающий русский язык».
Если бы ходил на собеседования в аутсорс контору, то бредом бы это не казалось. В аутсорсе ты используешь только базовые конструкции языка и кучу фреймворков со своим синтаксисом, конфигами и никому не нужной сложностью, за которой ты и сути не видишь.
Ну и нафига так работать?
Ты имеешь в виду контору или программиста?
Если контору, то она получает деньги от заказчиков. Суть не в том, чтобы выполнить задачу заказчика, а в том, чтобы получить от него деньги. Для этого нанимаются крутые менеджеры проектов, которые способны продать лед эскимосам по цене за баррель нефти. Это просто бизнес.
Если программиста, то джуниору надо получить свою первую работу и первый опыт. Не каждый сразу находит работу своей мечты и т.д. Приходится заниматься и такими вещами.
Если контору, то она получает деньги от заказчиков. Суть не в том, чтобы выполнить задачу заказчика, а в том, чтобы получить от него деньги. Для этого нанимаются крутые менеджеры проектов, которые способны продать лед эскимосам по цене за баррель нефти. Это просто бизнес.
Если программиста, то джуниору надо получить свою первую работу и первый опыт. Не каждый сразу находит работу своей мечты и т.д. Приходится заниматься и такими вещами.
НЛО прилетело и опубликовало эту надпись здесь
Это не таких людей нежно называют «говнокодерами»?
Да, именно таких, но сейчас железо стоит дешевле работника, так что говнокод простителен, например, есть два Drupal разработчика, один может все написать кодом, а другой может сделать тот же функционал но накликивая мышкой в админке, в первом случае все будет в два-три раза быстрее работать, а во втором будет в два-три раза быстрее сделано. На мелких проектах почему-то всегда выбирают второй вариант.
Кстати знал одного «разработчика» который с легкостью писал запросы бд в цикле, но при этом при сравнении специально приводил типы данных обуславливая тем что так быстрее выполняется.
Кстати знал одного «разработчика» который с легкостью писал запросы бд в цикле, но при этом при сравнении специально приводил типы данных обуславливая тем что так быстрее выполняется.
> На мелких проектах почему-то всегда выбирают второй вариант.
Почему почему-то? По конкретной причине — в два-три раза быстрее работающее (но не особо заметные на глаз) погоды не сделает, особенно, если скорость не критична, а в два-три раза быстрее (и дешевле) сделано — это ощутимо.
Если говорить о каких-то мелких и некритичных проектах на заказ, то там часто заказчику дико не интересно, что написано, как написано, отвечает ли написанное высокому званию разработчика — ему надо в срок и чтобы работало сейчас, а не после 3ёх переписываний и чтобы было идеально.
Почему почему-то? По конкретной причине — в два-три раза быстрее работающее (но не особо заметные на глаз) погоды не сделает, особенно, если скорость не критична, а в два-три раза быстрее (и дешевле) сделано — это ощутимо.
Если говорить о каких-то мелких и некритичных проектах на заказ, то там часто заказчику дико не интересно, что написано, как написано, отвечает ли написанное высокому званию разработчика — ему надо в срок и чтобы работало сейчас, а не после 3ёх переписываний и чтобы было идеально.
Я нормально к этому отношусь, просто по идее этот же принцип должен работать и для проектов по-больше, но некоторые заказчики которые уже наученные опытом с быстрой разработкой теперь выбирают первый вариант. Хотя мне сейчас интересны способы как выкрутится когда заказчик хочет быстро, а ты хочешь сделать хорошо =). Если найду вариант то поделюсь.
Хотя мне сейчас интересны способы как выкрутится когда заказчик хочет быстро, а ты хочешь сделать хорошо
Я пробовал. Переработка в ущерб сну и деньгам на единицу времени. После нескольких раз я понял, что этот трайхард никому не нужен (включая меня).
Теперь я исхожу с позиции того, что всему свое время и место, и «хороший код ради хорошего кода» больше не крутится в голове. Да и вообще, другое отношение — не «я пишу код», а «я участвую в разработке продукта», и действовать я должен в интересах этой разработки, а не в интересах своего желания поиграть с кодом.
Вспоминается случай, когда кто-то хотел заняться рефакторингом одноразового баш скрипта, «на всякий случай».
«Говнокод» — это, прежде всего, не медленно работающий код, а не читаемый другими (а то и собой) код.
Сейчас в отдел ищем Junior PHP Developer. За последний месяц пассивного поиска провели 20+ собеседований, вот собственно результат.
Напишите функцию, которая выводит содержимое массива, учитывая что значением может быть вложенный массив:
— Смогли написать правильно цикл 6 человек
— Смогли использовальзовать рекурсию из них 4 человека
При использовании паттерна MVC, где мы впервые «встречается» с запросом:
— В контроллере сказало 8 человек
— В модели (!) сказало 4 человека
— Один человек сказал в Базе Данных (тогда я реально выпал)
В резюме вы указали, что знание JavaScript у Вас на уровне х (от 5 до 7 в 10-ти бальной), как получить ноду по id:
— document.getElementById вспомнило 3 человека
— document.querySelector 1 человек
— jQuery 6 человек
До вопросов связанных с Framework'ами ни одного из претендентов не удалось довести, они валились на знаниях БД (обычный SELECT с GROUP BY не смогли написать, либо даже не смогли построить правильно две таблицы), знаниях ООП (7 человек не знали как определить конструктор).
В общем сейчас очень сложно найти хоть одного нормального Junior'а либо даже Trainee. Это как-то очень печально.
Напишите функцию, которая выводит содержимое массива, учитывая что значением может быть вложенный массив:
— Смогли написать правильно цикл 6 человек
— Смогли использовальзовать рекурсию из них 4 человека
При использовании паттерна MVC, где мы впервые «встречается» с запросом:
— В контроллере сказало 8 человек
— В модели (!) сказало 4 человека
— Один человек сказал в Базе Данных (тогда я реально выпал)
В резюме вы указали, что знание JavaScript у Вас на уровне х (от 5 до 7 в 10-ти бальной), как получить ноду по id:
— document.getElementById вспомнило 3 человека
— document.querySelector 1 человек
— jQuery 6 человек
До вопросов связанных с Framework'ами ни одного из претендентов не удалось довести, они валились на знаниях БД (обычный SELECT с GROUP BY не смогли написать, либо даже не смогли построить правильно две таблицы), знаниях ООП (7 человек не знали как определить конструктор).
В общем сейчас очень сложно найти хоть одного нормального Junior'а либо даже Trainee. Это как-то очень печально.
Укажите, какие требования вы предъявляете для Junior? Тогда будет проще вникать в ваш контекст.
1. Рекурсия — хорошо понимать что это такое… но не в любом ведь случае применимо, или вы не рассматривали её как безусловный плюс?
2. А что такое запрос применительно к модели MVC?
3. Печально (особенно предпочтение jQuery при такой банальной задаче).
4. БД… Кхм… а вот это для джуна не самое страшное — вполне можно в процессе научить. Плохо это только если это выпускник/студент старших курсов IT-специальности.
5. ООП — тоже что и БД. Кстати, а какой версии PHP конструктор нужен был (да-да, я отстал от жизни и помню ещё PHP без ООП… ну так не мой хлеб:)
2. А что такое запрос применительно к модели MVC?
3. Печально (особенно предпочтение jQuery при такой банальной задаче).
4. БД… Кхм… а вот это для джуна не самое страшное — вполне можно в процессе научить. Плохо это только если это выпускник/студент старших курсов IT-специальности.
5. ООП — тоже что и БД. Кстати, а какой версии PHP конструктор нужен был (да-да, я отстал от жизни и помню ещё PHP без ООП… ну так не мой хлеб:)
1. Если человек идет на PHP разработчика (не CMS разработчика), то ему желательно знать, что такое есть.
2. Ну если брать HTTP сервер, то HTTP запрос (в данном случае берется абстрактный такой себе сервер, в котором минуется слой инициализации, роутинга, и т.д.)
3. Согласен, если у большинства людей забрать jQuery, они не смогут даже цикл по массиву написать
4. Ну если бы он шел на CMS Developer'а, то да. Но тут знания нужны хоть какие-то.
5. PHP5+ то-есть __construct, ну если бы он сказал бы с именем класса, то тоже было бы неплохо.
2. Ну если брать HTTP сервер, то HTTP запрос (в данном случае берется абстрактный такой себе сервер, в котором минуется слой инициализации, роутинга, и т.д.)
3. Согласен, если у большинства людей забрать jQuery, они не смогут даже цикл по массиву написать
4. Ну если бы он шел на CMS Developer'а, то да. Но тут знания нужны хоть какие-то.
5. PHP5+ то-есть __construct, ну если бы он сказал бы с именем класса, то тоже было бы неплохо.
2. Кхм… а модель тут при чём? Это уже практическое применение модели (знание которого может быть плюсом, но к вопросу прямого отношения не имеет). Ну и запрос запросу рознь — если контроллер находится на вебсервере, а вью — в браузере, то запрос — действие вью, а если и контроллер в браузере — то тогда запрашивает контроллер… Зависит ведь от архитектуры приложения. Уверены что корректно так спрашивать знание MVC?
3. вы про for (var i....) или array.forEach(function)? И знание какого приоритетней? :) Впрочем незнание js, но знание jQuery по меньшей мере странно… Это скорее не знание, получается, а скилл/рефлекс… В общем умение пользоваться без понимания… А в программирование это чревато проблемами. :(
3. вы про for (var i....) или array.forEach(function)? И знание какого приоритетней? :) Впрочем незнание js, но знание jQuery по меньшей мере странно… Это скорее не знание, получается, а скилл/рефлекс… В общем умение пользоваться без понимания… А в программирование это чревато проблемами. :(
2) при том что это один из вариантов. Если мы допускаем что слой инициализации мы пропускаем, то запрос сначала должен дойти до контроллера. Слой представления мы имеем в любом случае, если у нас API то это представление в виде JSON/XML… Этот вопрос более чем корректен, ибо из него выплывает непонимание зачем нужен контроллер, модель и т.д. Вообще это основы, человек должен понимать как работает приложение хотя бы на упрощенном уровне. Он должен понимать что есть запрос, он куда-то передается, с ним что-то делается, формируется ответ… И что так при любой реализации серверной части, будь у вас просто index.php или демон на ReactPHP.
3) если человек не в состоянии написать простой for in цикл, то грусть.
3) если человек не в состоянии написать простой for in цикл, то грусть.
2. Если мы говорим о веб-приложении, то MVC у нас может присутствовать на различных архитектурных уровнях и без их уточнения даже спец не сможет уверенно сказать, а что же его спросили таким вопросом. Ну если он не привык именно к таким вопросам и под ними не подразумевается конкретная часть модели. Вы рассматриваете исключительно тот вариант, когда контроллер == бэкенд, представление — отдаваемый контент, а я не могу не рассматривать и случай, когда сервер выступает моделью, а представление и контроллер — в браузере. Есть и ещё варианты. И составные варианты так же присутствуют.
3. for in слишком спецефично js-ный. Мало программирующим на этом языке не всегда легко о нём вспомнить (хоть он и корректней для массивов). Так что не совсем грусть, хотя да, это важный момент.
3. for in слишком спецефично js-ный. Мало программирующим на этом языке не всегда легко о нём вспомнить (хоть он и корректней для массивов). Так что не совсем грусть, хотя да, это важный момент.
2. О том MVC мы говорим? Model-View-Controller?
Controller — обрабатывает запрос от пользователя, и этим самым производит связь между пользователем и системой.
Model — репрезентация данных, например полученных из БД, ну и может манипулировать этими данными
View — отображение данных (то что мы отдаем обратно клиенту) в HTML, Json, Plain text, etc
Вот в принципе классический MVC.
Controller — обрабатывает запрос от пользователя, и этим самым производит связь между пользователем и системой.
Model — репрезентация данных, например полученных из БД, ну и может манипулировать этими данными
View — отображение данных (то что мы отдаем обратно клиенту) в HTML, Json, Plain text, etc
Вот в принципе классический MVC.
Начнем с того что MVC это паттерн (или набор паттернов, которые используются вместе)
Если вы все паттерны используете «как написано в книге», то тут явно ваш просчет.
Видет кучу реализаций MVC
MVC как паттерн
Java MVC (еще может называться MVCv2)
.NET MVC
Yii шный MVC очень сильно отличается. Там с моделью вообще какой то бардак.
Если вы все паттерны используете «как написано в книге», то тут явно ваш просчет.
Видет кучу реализаций MVC
MVC как паттерн
Java MVC (еще может называться MVCv2)
.NET MVC
Yii шный MVC очень сильно отличается. Там с моделью вообще какой то бардак.
Я об этом. А вы о MVC применительно к вебу с бекэндом на php.
Классический MVC:
Модель — данные (не репрезентация) и методы их обработки (не связанные с представлением)
Вью — представление данных и интерфейс пользователя
Контроллер — обеспечивает взаимодействие, реакцию (изменение состояния и/или информирование о нём) модели на события интерфейса.
Модель — данные (не репрезентация) и методы их обработки (не связанные с представлением)
Вью — представление данных и интерфейс пользователя
Контроллер — обеспечивает взаимодействие, реакцию (изменение состояния и/или информирование о нём) модели на события интерфейса.
2. Человек идет на собес PHP-джуниора, а следовательно на вакансию backend разработчика. Если у него спрашивают про запрос, то это 99,9% что http-запрос который должен обработать сервер. Более того, у вас сервер никогда не будет моделью, он будет хранилищем данных. Модель же включает в себя несколько больше. Да и на том же сервере, как бы мы с высоты фронтэнда себе это не представляли, всеравно будет контроллер, который будет обрабатывать ваш запрос, модель и представление (JSON/XML).
Главная проблема новичков, они не понимают как работает сервер. То есть что происходит до вызова контроллера. Люди не понимают различий между обычными HTTP запросами и AJAX запросами (фактически их нет, но люди этого не понимают) и отсюда появляется океан тупых вопросов.
3. for in есть в python, ruby, d, c#… да много где. Это одна из основных конструкций языка. Это как не знать if/else.
p.s. Вы либо тролите, либо не понимаете предмета разговора.
Главная проблема новичков, они не понимают как работает сервер. То есть что происходит до вызова контроллера. Люди не понимают различий между обычными HTTP запросами и AJAX запросами (фактически их нет, но люди этого не понимают) и отсюда появляется океан тупых вопросов.
3. for in есть в python, ruby, d, c#… да много где. Это одна из основных конструкций языка. Это как не знать if/else.
p.s. Вы либо тролите, либо не понимаете предмета разговора.
2. Сервер в рамках MVC представления вполне может выполнять роль модели. Всё зависит от архитектуры. ;-) И вы проморгали фразу «И составные варианты так же присутствуют»
А запрос… нет, запрос к серверу, http-запрос, запрос браузера,… прочие варианты с уточняющими словами — да, формализуют что за запрос имеется в виду. Но если человека спрашивают MVC и говорят «где запрос» — вот это троллинг. Потому что в самой MVC запросов нет — там другие термины.
А новички должны понимать как работает сервер? Вот прям до миллиметра? Ну и потом — всё зависит от того, чего вы хотите от нуба — если нужно, чтобы он сразу начал приносить прибыль — это одни требования, если вырастить себе нужного спеца — совсем другие требования.
3. for in отсутствует в c, c++, pascal, delphi, java, много-где-ещё. Простите, но получать ключ в форич-подобном цикле меня не прёт. Предпочитаю, чтобы у меня была возможность выбирать, что же я хочу получать в переменную. Коллекции в Java способствуют таким желаниям.
PS у нас просто разные взгляды на некоторые моменты, которые не дают вам понять меня ;-)
А запрос… нет, запрос к серверу, http-запрос, запрос браузера,… прочие варианты с уточняющими словами — да, формализуют что за запрос имеется в виду. Но если человека спрашивают MVC и говорят «где запрос» — вот это троллинг. Потому что в самой MVC запросов нет — там другие термины.
А новички должны понимать как работает сервер? Вот прям до миллиметра? Ну и потом — всё зависит от того, чего вы хотите от нуба — если нужно, чтобы он сразу начал приносить прибыль — это одни требования, если вырастить себе нужного спеца — совсем другие требования.
3. for in отсутствует в c, c++, pascal, delphi, java, много-где-ещё. Простите, но получать ключ в форич-подобном цикле меня не прёт. Предпочитаю, чтобы у меня была возможность выбирать, что же я хочу получать в переменную. Коллекции в Java способствуют таким желаниям.
PS у нас просто разные взгляды на некоторые моменты, которые не дают вам понять меня ;-)
Откуда вы взяли 99.9%? А запрос в базу данных (да-да-да, все та же терминология) к бэкенду не относится?
А Вы попытались выяснить, что имел в виду тот единственный человек, который ответил про БД на вопрос про запросы?
Капец, слов нет.
А Вы попытались выяснить, что имел в виду тот единственный человек, который ответил про БД на вопрос про запросы?
Капец, слов нет.
Запрос в базу не подходит в контексте. Если бы собеседуемый человек на самом деле перепутал HTTP запрос и запрос в базу (что на самом деле в контексте вопроса довольно странно), то его можно быстро поправить. Суть все же не в том что бы проверить знает или не знает, а умеет ли человек думать и делать какие-то предположения и выводы. Даже если выводы эти ошибочные, всегда интересно узнать как человек к ним пришел и поправить в случае чего.
Не соглашусь с вами про незнание работы сервера.
Вы хотите услышать сервер.
Тоже самое, если я скажу «жучка», то вы должны сказать «Собака»
У джуниоров нет этих рефлексов, они ни с кем не обсуждали эти вещи.
Зачастую они о них знают, но не понимают что вы от них хотите.
Скажите иностранцу «Juchka», он в скольки случаях ответит «Dog»?
И вы правда считаете что он ничего не знает от «Собаках»?
Вы хотите услышать сервер.
Тоже самое, если я скажу «жучка», то вы должны сказать «Собака»
У джуниоров нет этих рефлексов, они ни с кем не обсуждали эти вещи.
Зачастую они о них знают, но не понимают что вы от них хотите.
Скажите иностранцу «Juchka», он в скольки случаях ответит «Dog»?
И вы правда считаете что он ничего не знает от «Собаках»?
Я не хочу услышать «сервер», я хочу услышать что человек понимает что такое архитектура «клиент-сервер» и как они взаимодействуют между собой. Если человек не может ответить на этот вопрос, я бы попробовал подвести его намеками к правильному ответу, заодно посмотреть как человек рассуждает.
Джуниор это все же не нулевой разработчик, он должен знать основы. У него может не быть опыта работы, но осознание того чем придется заниматься и как — по хорошему хоть в каком-то виде должны быть. То что человек сходу скорее всего не сможет грамотно сформулировать свои мысли — это нормально, понимание важнее знаний.
Джуниор это все же не нулевой разработчик, он должен знать основы. У него может не быть опыта работы, но осознание того чем придется заниматься и как — по хорошему хоть в каком-то виде должны быть. То что человек сходу скорее всего не сможет грамотно сформулировать свои мысли — это нормально, понимание важнее знаний.
Может стоить задать вопрос вот так?:
«я хочу услышать что человек понимает что такое архитектура «клиент-сервер» и как они взаимодействуют между собой.»
Будет больше толку?
Я вот как раз об этом и говорю.
«я хочу услышать что человек понимает что такое архитектура «клиент-сервер» и как они взаимодействуют между собой.»
Будет больше толку?
Я вот как раз об этом и говорю.
Может быть вы понимаете разницу между вопросами джуниорам на собеседованиях и комментариями на хабре? Суть в том что если человек не знает в какой букве в абривиатуре MVC идет обработка запросов пользователя, то значит он не знает что такое MVC. В такой ситуации скорее всего я повернул бы дискуссию в то русло, при котором можно было бы путем логических умозаключений придти к верному вопросу и судить уже по тому, как рассуждает человек. На основе этих рассуждений уже можно строить какие-то выводы.
Ездил на собеседования. Разницу вижу.
Задают «вопрос в лоб» без объяснений. Можно было просто тест сделать.
Если вы правда пытаетесь дойти до цели, то вам большой и жирный плюс.
Задают «вопрос в лоб» без объяснений. Можно было просто тест сделать.
Если вы правда пытаетесь дойти до цели, то вам большой и жирный плюс.
По моей практике:
1 из 5 собеседующих интересуется моими рассуждениями, остальным нужен ответ и быстро. Ну т.е. или заучивай наизусть — или «не знаешь».
Хотя может что-то изменилось за 3 года?..
1 из 5 собеседующих интересуется моими рассуждениями, остальным нужен ответ и быстро. Ну т.е. или заучивай наизусть — или «не знаешь».
Хотя может что-то изменилось за 3 года?..
3. Согласен, если у большинства людей забрать jQuery, они не смогут даже цикл по массиву написатьПроблема «Держания синтаксиса JavaScript в голове». Откроет простейший учебник по JavaScript и через 2 минуты получите решение вашей задачи.
Мне казалось видение алгоритма важнее синтаксиса языка.
3. А в чем печаль применения jQuery для человека, который претендует на Junior?
4. БД сами сказали не критично. Даже для выпускника старших курсов это некритично, т.к. лабораторные работы могут делаться на MS Access, где самого SQL студент даже в глаза не видел, а видел лишь: тыкнуть галку сюда, ввести в формочку здесь, нажать ключик вон там.
5. ООП никогда не являлось серебряной пулей. Ну да хорошо выражаться в терминах паттернов, фабрик и т.д. Однако я за свою карьеру программиста столько говнокода перевидал от любителей ООП, что не вижу особого смысла общаться в абстрактных категориях полиморфизм, инкапсуляция, наследование. Лучше поставить реальную задачу и попросить набросать приблизительную архитектуру для ее решения.
4. БД сами сказали не критично. Даже для выпускника старших курсов это некритично, т.к. лабораторные работы могут делаться на MS Access, где самого SQL студент даже в глаза не видел, а видел лишь: тыкнуть галку сюда, ввести в формочку здесь, нажать ключик вон там.
5. ООП никогда не являлось серебряной пулей. Ну да хорошо выражаться в терминах паттернов, фабрик и т.д. Однако я за свою карьеру программиста столько говнокода перевидал от любителей ООП, что не вижу особого смысла общаться в абстрактных категориях полиморфизм, инкапсуляция, наследование. Лучше поставить реальную задачу и попросить набросать приблизительную архитектуру для ее решения.
3. Печаль == не знание javascript, но попытки оперировать jQuery, который без js почти ничего не стоит. (Оперирование сложным инструментом без понимания)
4. Если специальность не IT-шная, то такой расклад допустим. Если IT-шная то в ней с очень высокой вероятностью был курс реляционных баз данных, включающий некий практикум => знание базиса SQL подразумевается.
5. Обратите внимание, что ООП я оцениваю как и БД == «для джуна не самое страшное, если он не с IT специальности». Потому что узнать всё равно придётся, но для начала — не критично. Ну и не надо приводить говнокод как оправдание принижения значения базовых архитектур. Так и функциональное и процедурное программирование можно опустить ниже некуда. А это всего-лишь паттерны, призванные облегчить разработку ПО для определённого круга задач.
4. Если специальность не IT-шная, то такой расклад допустим. Если IT-шная то в ней с очень высокой вероятностью был курс реляционных баз данных, включающий некий практикум => знание базиса SQL подразумевается.
5. Обратите внимание, что ООП я оцениваю как и БД == «для джуна не самое страшное, если он не с IT специальности». Потому что узнать всё равно придётся, но для начала — не критично. Ну и не надо приводить говнокод как оправдание принижения значения базовых архитектур. Так и функциональное и процедурное программирование можно опустить ниже некуда. А это всего-лишь паттерны, призванные облегчить разработку ПО для определённого круга задач.
Печаль == не знание javascript, но попытки оперировать jQuery, который без js почти ничего не стоит. (Оперирование сложным инструментом без понимания)
Можете привести конкретные примеры?
Вот с ходу? Нет. Но неоднократно натыкался на такие. Архитектурные навороты в 5-10 строчек, для которых достаточно 2-4х на чистом js…
Make an AJAX call
JS
jQuery
Отсюда. Там как раз эта проблема и представлена в ироничной форме.
JS
var r = new XMLHttpRequest();
r.open("POST", "path/to/api", true);
r.onreadystatechange = function () {
if (r.readyState != 4 || r.status != 200) return;
alert("Success: " + r.responseText);
};
r.send("banana=yellow");jQuery
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script>
$.ajax({
type: 'POST',
url: "path/to/api",
data: "banana=yellow",
success: function (data) {
alert("Success: " + data);
},
});
</script>Отсюда. Там как раз эта проблема и представлена в ироничной форме.
А вы уверены что в вашем браузере есть XMLHttpRequest?
Помню что он есть не во всех, а через JQuery — об этом заботится библиотека, которая кормит целый зоопарк «XMLHttpRequest» для всех браузеров.
Помню что он есть не во всех, а через JQuery — об этом заботится библиотека, которая кормит целый зоопарк «XMLHttpRequest» для всех браузеров.
В чём, собственно, проблема? Особенно здесь (если предположить, что jquery используется в проекте, а не подключена ради этой конкретной штуки):
vs
var s = document.getElementById('thing').style;
s.opacity = 1;
(function fade(){(s.opacity-=.1)<0?s.display="none":setTimeout(fade,40)})();
vs
$('#thing').fadeOut();
AJAX — плохой пример. Без штук типа jQUery или каких-то оберток довольно сложно на самом деле, особенно если в требованиях к проекту можно с тоской прочитать IE7+.
Ну ни фига не смешно. Чисто для примера посмотрите как создавать кросс-браузерный запрос и это минимально необходимый код:
github.com/Raynos/xhr/blob/master/index.js
github.com/Raynos/xhr/blob/master/index.js
Знание JS это не столько знание DOM API, сколько умение писать поддерживаемый модульный код в JS и не седеть при изменении требований. А джуниор пусть пишет на jQuery. Это действительно очень удобный инструмент с более понятным синтаксисом и API, чем встроенные API. А для джуниора это критически важные преимущества. Я и сам, когда только начинал писать на JS, писал на jQuery и лапше из функций.
(Оперирование сложным инструментом без понимания)
Миллионы водителей водят машину, даже не понимая, как она работает. Миллионы юзеров тыкают в иконочки и окошечки в виндовсе, даже не понимая, как он работает. Примеров — уйма. Многое в этой жизни делается по принципу чёрного ящика: нажал на кнопку, получил результат. А понимание внутренних процессов приходит с опытом. Которого (вот поворот, а?) у них нет!
Если уж пошли в сравнение, то представьте что джуниор, это водитель, который хочет сам отремонтировать свою машину. Какие-то представления о том из чего состоит машина у него все же должны иметься. Да, ему не обязательно в самом начала знать какие-то тонкости, но общий принцип работы того же двигателя внутреннего сгорания ему должен быть известен. А с учетом доступности информации в наше время, даже с википедии достаточно знаний подчерпнуть. Только самые базовые основы, которые не зависят от типа двигателя, производителя и т.д.
У джуниора должен быть какой-то багаж знаний в той отрасли, в которую он идет, иначе можно просто брать людей с улицы.
Что до черных ящиков… Ну как бы да, это единственный способ не свихнуться. Всего знать уже просто не получится, слишком большой объем информации. И от джуниора не требуется знать как работает или из каких черных ящиков состоит его черный ящик, но он должен уметь сколотить свой такой ящик из других.
У джуниора должен быть какой-то багаж знаний в той отрасли, в которую он идет, иначе можно просто брать людей с улицы.
Что до черных ящиков… Ну как бы да, это единственный способ не свихнуться. Всего знать уже просто не получится, слишком большой объем информации. И от джуниора не требуется знать как работает или из каких черных ящиков состоит его черный ящик, но он должен уметь сколотить свой такой ящик из других.
Ух, сложно у вас, наверное работать:
Как правильно прочитать этот вопрос?
Мне лично никогда не нравились вакансии в которых мне предлагали оценить свои знания по 10-бальной шкале. Потому что это нереально. Есть куча всяких нюансов в языке, конструкций, фреймворков. Поэтому единственный реальный профит от вопроса, это узнать, что человек достаточно умен, чтобы назвать цифру где-то посередине от 0 до 10.
Если к вам приходит Junior Developer это означает, что человек прочитал пару книжек, может вывести Hello World в консоль и катастрофически не имеет нормального опыта, который необходим для работы.
Я вспоминаю свое первое собеседование на позицию Junior Java Developer, как много я говорил слов невпопад:
1. Путал в сервлетах ServiceContext и RequestContext.
2. Не пользовался Idea, а писал в Notepad++.
3. Ничего не знал о Spring и Hibernate.
4. Не умел пользоваться debugger.
5. Не знал вообще Javascript и даже jQuery.
Первый месяц было очень тяжело, т.к. я чувствовал себя самым тупым человеком на свете, потому что тебе дают задачу, а ты элементарно не знаешь с какого конца приняться. Для коллег эта задачка была раз плюнуть и они быстро могли ее решить.
Поэтому надо просто брать человека и работать вместе с ним. Главное не то, сколько технологий он знает, а как быстро он может этому научится. Мы все были Junior, надо не забывать этого простого факта. Всем надо с чего-то начинать.
паттерна MVC, где мы впервые «встречается»
Как правильно прочитать этот вопрос?
знание JavaScript у Вас на уровне х
Мне лично никогда не нравились вакансии в которых мне предлагали оценить свои знания по 10-бальной шкале. Потому что это нереально. Есть куча всяких нюансов в языке, конструкций, фреймворков. Поэтому единственный реальный профит от вопроса, это узнать, что человек достаточно умен, чтобы назвать цифру где-то посередине от 0 до 10.
Если к вам приходит Junior Developer это означает, что человек прочитал пару книжек, может вывести Hello World в консоль и катастрофически не имеет нормального опыта, который необходим для работы.
Я вспоминаю свое первое собеседование на позицию Junior Java Developer, как много я говорил слов невпопад:
1. Путал в сервлетах ServiceContext и RequestContext.
2. Не пользовался Idea, а писал в Notepad++.
3. Ничего не знал о Spring и Hibernate.
4. Не умел пользоваться debugger.
5. Не знал вообще Javascript и даже jQuery.
Первый месяц было очень тяжело, т.к. я чувствовал себя самым тупым человеком на свете, потому что тебе дают задачу, а ты элементарно не знаешь с какого конца приняться. Для коллег эта задачка была раз плюнуть и они быстро могли ее решить.
Поэтому надо просто брать человека и работать вместе с ним. Главное не то, сколько технологий он знает, а как быстро он может этому научится. Мы все были Junior, надо не забывать этого простого факта. Всем надо с чего-то начинать.
С последним полностью согласен. Собеседование — это не экзамен, это способ проверить адекватность и стремление человека. Если у человека знаний мало, но есть стремление, мы такого человека берем и обучаем.
Ну вот, в обсуждении этой статьи наконец-то слышен глас разума :)
Хотел сам написать подобный комментарий, но вот наткнулся на ваш.
Последний абзац подпишусь под всеми словами *THUMBS_UP*
Хотел сам написать подобный комментарий, но вот наткнулся на ваш.
Последний абзац подпишусь под всеми словами *THUMBS_UP*
В резюме вы указали, что знание JavaScript у Вас на уровне х (от 5 до 7 в 10-ти бальной), как получить ноду по id:
— document.getElementById вспомнило 3 человека
— document.querySelector 1 человек
— jQuery 6 человек
DOM — не JavaScript.
— document.getElementById вспомнило 3 человека
— document.querySelector 1 человек
— jQuery 6 человек
DOM — не JavaScript.
а з\п какая если не секрет?
«как получить ноду по id» вовсе не является частью JS. Я вообще когда вопрос прочитал подумал, что надо в каком то списке найти какую то хрень у которой есть свойство id.
При использовании паттерна MVC, где мы впервые «встречается» с запросом:
— В контроллере сказало 8 человек
— В модели (!) сказало 4 человека
— Один человек сказал в Базе Данных (тогда я реально выпал)
Вот именно этот вопрос сформулирован очень уж непонятно. Я бы тоже ответил «в модели», т.к. подумал что речь идет о запросе к БД (и не вижу никаких предпосылок к тому, что это — неверно). И последний вариант в таком случае — тоже не такой уж и глупый.
Про рекурсию
в начале 2000х годов очень часто натыкался на статьи «рекурсия это плохо, нужно ее разворачивать»
Сейчас что то поменялось?
А может это назвать деревом, тогда и задача будет проще решаться?
Как известно в вопросе содержится 80% ответа.
Чем правильнее задан вопрос, тем лучший ответ вы получите.
Проверьте как нибудь, назвав ваш массив деревом.
Опять же в вашем контексте много «специфического сленга»
Если я не работал в команде, то я могу не знать что такое «запрос в MVC», так как в слух это ни кто не произносил.
Но все изменения обрабатывает контроллер. Может пусть они своими словами расскажут что и как, а не устраивать тест как ЕГЭ? В Yii не контроллер, а роутер скорее всего встречает запрос, потом уже передает контроллеру.
Опять же есть понятие MVC, есть MVCv2, в разных языках отличаются реализации. На каком нибудь PHP можно прийти к браузеру. Так как запрос идет на урл и т.д…
JavaScript про JQuery интересное решение. Человек знает о существовании css селекторов. Это разве плохо?
в начале 2000х годов очень часто натыкался на статьи «рекурсия это плохо, нужно ее разворачивать»
Сейчас что то поменялось?
Напишите функцию, которая выводит содержимое массива, учитывая что значением может быть вложенный массив:А может это назвать деревом, тогда и задача будет проще решаться?
Как известно в вопросе содержится 80% ответа.
Чем правильнее задан вопрос, тем лучший ответ вы получите.
Проверьте как нибудь, назвав ваш массив деревом.
Опять же в вашем контексте много «специфического сленга»
Если я не работал в команде, то я могу не знать что такое «запрос в MVC», так как в слух это ни кто не произносил.
Но все изменения обрабатывает контроллер. Может пусть они своими словами расскажут что и как, а не устраивать тест как ЕГЭ? В Yii не контроллер, а роутер скорее всего встречает запрос, потом уже передает контроллеру.
Опять же есть понятие MVC, есть MVCv2, в разных языках отличаются реализации. На каком нибудь PHP можно прийти к браузеру. Так как запрос идет на урл и т.д…
JavaScript про JQuery интересное решение. Человек знает о существовании css селекторов. Это разве плохо?
Почему рекурсия это плохо?
Сравните поддержку кода написанного рекурсивно и без использования рекурсии.
Если все правильно подсчитали, то должно получиться, что поддержка рекурсивного кода сильно проще и дешевле. Я, правда, не встречался с простыми реализациями итеративных алгоритмов :)
Естественно, не рассматриваем ситуацию, когда в условиях задачи стоит условно-бесконечная вложенность.
Сравните поддержку кода написанного рекурсивно и без использования рекурсии.
Если все правильно подсчитали, то должно получиться, что поддержка рекурсивного кода сильно проще и дешевле. Я, правда, не встречался с простыми реализациями итеративных алгоритмов :)
Естественно, не рассматриваем ситуацию, когда в условиях задачи стоит условно-бесконечная вложенность.
Не знаю почему рекурсия это плохо.
Я был молод и верил всему что пишут в журналах.
Я был молод и верил всему что пишут в журналах.
Рекурсия плохо из-за того, что стек ограничен (глубокие деревья свалят алгоритм) + немного напутав условия можно получить stack overflaw (как аналог бесконечному цикл).
Рекурсия плохо, когда у тебя двойной или тройной цикл. Тогда ты перестаешь понимать что ты делаешь точно также как и с итеративными алгоритмами.
В некоторых алгоритмах это важно — иначе никакого стека не хватит, чтобы уместить данные по всей цепочке вызовов.
Даже придумали такой финт ушами как хвостовую рекурсию, когда пишешь алгоритм рекурсивно, а он компилятором разворачивается в итеративный вариант.
А в кровавом ынтырпрайзе и сайтиках, сваяных за пару дней, где царствуют жава и пыха соответственно, такие вопросы крайне-крайне-крайне редко возникают.
Поэтому тут на первое место выходит поддержка и скорость написания.
Даже придумали такой финт ушами как хвостовую рекурсию, когда пишешь алгоритм рекурсивно, а он компилятором разворачивается в итеративный вариант.
А в кровавом ынтырпрайзе и сайтиках, сваяных за пару дней, где царствуют жава и пыха соответственно, такие вопросы крайне-крайне-крайне редко возникают.
Поэтому тут на первое место выходит поддержка и скорость написания.
Это я всё знаю. Просто тут одни говорят что это нужно и хорошо, вы говорите что плохо.
Выходит что для забивания гвоздей — молоток, а для закручивания гаек — ключ
Зачем тогда «требовать» решение задачи через рекурсию?
Выходит что для забивания гвоздей — молоток, а для закручивания гаек — ключ
Зачем тогда «требовать» решение задачи через рекурсию?
Посмотреть как «натренированы» мозги на алгоритмистику? Хотя я бы такой способ не применял.
Насчет хорошо/плохо. Я говорю, что это хорошо для определенного круга задач и плохо для другого. В большинстве случаев, рекурсия хорошо. Вот и все.
И не слушайте других, они че попало могут нести. Всегда задавайте вопрос зачем? почему?
Насчет хорошо/плохо. Я говорю, что это хорошо для определенного круга задач и плохо для другого. В большинстве случаев, рекурсия хорошо. Вот и все.
И не слушайте других, они че попало могут нести. Всегда задавайте вопрос зачем? почему?
Рекурсия это основы. Скажем вас попросят написать бинарный поиск (довольно популярная задачка на собеседованиях), и самый простой и быстрый способ, это реализовать рекурсию. Развернуть же стэк вызовов в очередь для работы с большими объемами данных, или применить хвостовую рекурсию — это уже дело техники.
Самое забавное что бинарный поиск мне приходилось реализовывать всего 2 раза (за 10 лет)
1) когда читал Вирта
2) когда изучал fork join на java
во всех остальных случаях за меня это делали всякие библиотеки.
1) когда читал Вирта
2) когда изучал fork join на java
во всех остальных случаях за меня это делали всякие библиотеки.
Можно пример задачи, где это так нужно знать? (я про двоичный поиск)
Поиск в тексте — не похоже
Поиск в отсортированном массиве — хорошо, а зачем? Плохо спроектировано что то?
Поиск в дереве — лучше, но это пишется 1 раз и работает годами.
Поиск в хеш таблице? Используется хешмап или array PHPшный, работать будет быстрее, нежели сам напишешь. PHP функции — скомпиленные, а самописный код — интерпретируемый + создает кучу мусора в памяти.
Я не думаю что знание двоичного поиска это один из вопросов
«проснись ночью и напиши мне алгоритм»
А на собеседованиях просят на бумаге это сделать… что не есть гуд.
Блок схему нарисовать — пожалуйста, а вот в коде, да еще на PHP, а прошлую неделю ты сидел в Java и bash… :)
Поиск в тексте — не похоже
Поиск в отсортированном массиве — хорошо, а зачем? Плохо спроектировано что то?
Поиск в дереве — лучше, но это пишется 1 раз и работает годами.
Поиск в хеш таблице? Используется хешмап или array PHPшный, работать будет быстрее, нежели сам напишешь. PHP функции — скомпиленные, а самописный код — интерпретируемый + создает кучу мусора в памяти.
Я не думаю что знание двоичного поиска это один из вопросов
«проснись ночью и напиши мне алгоритм»
А на собеседованиях просят на бумаге это сделать… что не есть гуд.
Блок схему нарисовать — пожалуйста, а вот в коде, да еще на PHP, а прошлую неделю ты сидел в Java и bash… :)
Не нужно ничего выдумывать, классическая задача бинарного поиска в отсортированном массиве, которые дают на первых курсах универов. Для собеседований, если конечно это не оговаривается, обычно нужно написать максимально простую реализацию. Если вам так неймется покричать что это никому не нужно, сначала решите задачу (это же займет какую-нибудь минуту), а потом уже ведите дискуссию на эту тему.
Рекурсивные алгоритмы частенько используются при обработке изображений (например метод ближайших соседний), задачи обхода графов, обход файловой системы и прочее. Да, обычно там используется поиск в ширину, но это не отменяет рекурсивной природы алгоритма.
Рекурсивные алгоритмы частенько используются при обработке изображений (например метод ближайших соседний), задачи обхода графов, обход файловой системы и прочее. Да, обычно там используется поиск в ширину, но это не отменяет рекурсивной природы алгоритма.
Ближайших соседей*
Я не говорю что это не нужно, я не понимаю почему это так важно на собеседовании?
Вам же ни когда не дадут задание «напишите двоичный поиск» в работе
У вас будет куча других заданий по поиску чего либо где либо.
А вот как вы это реализуете — показатель вашего умения как программиста.
Мое мнение такое.
Человеку важнее знать какие алгоритмы есть и где они используются, нежели среди ночи уметь их реализовывать.
Мне кажется больше толку будет от человека, который знает для чего нужен двоичный поиск, даже если он не смог его реализовать на собеседовании на листке бумаги, нежели человек, который зазубрил реализацию двоичного поиска, а нахрен он нужен — не знает.
Вы не согласны?
Вам же ни когда не дадут задание «напишите двоичный поиск» в работе
У вас будет куча других заданий по поиску чего либо где либо.
А вот как вы это реализуете — показатель вашего умения как программиста.
Мое мнение такое.
Человеку важнее знать какие алгоритмы есть и где они используются, нежели среди ночи уметь их реализовывать.
Мне кажется больше толку будет от человека, который знает для чего нужен двоичный поиск, даже если он не смог его реализовать на собеседовании на листке бумаги, нежели человек, который зазубрил реализацию двоичного поиска, а нахрен он нужен — не знает.
Вы не согласны?
Мне кажется больше толку будет от человека, который знает для чего нужен двоичный поиск
Джуниору не обязательно знать это. Его никто не собеседовании на будет спрашивать о том как реализован RecursiveDirectoryIterator, никто не будет давать задачки обхода графов, не будут спрашивать о том, как реализованы индексы в БД, которую он использует, или просто как бы он реализовывал индекс в его собственной СУБД (тут обычно бинарный поиск и всплывает, во всяком случае в литературе).
От джуниора обычно требуется база (понимание алгоритмов, системы типов в языке, который он будет использовать, какие-то основы по массивам, основы ООП), адекватность и обучаемость. Если у нас будет два человека на выбор, один много знает, а другой лучше обучаем, хоть и знает меньше, предпочтительнее взять второго.
Это в сферических случаях. Есть еще нюансы, типа род деятельности (возможно по работе человеку только и придется, что решать задачки поиска кратчайшего пути, использовать БД типа neo4j, делать какие-то скучные ресерчи алгоритмов и прочее), но это довольно редкая ситуация и обычно джуниоров так просто туда не садят.
Если вы не знаете рекурсию — о каком алгоритме вообще речь? Некоторые алгоритмы без рекурсии нормально написать невозможно (будет дикая лапша). Вот для проверки знаний рекурсии и даётся двоичный поиск (один из ярких представителей алгоритмов, выполняемых рекурсией). А рекурсия и в работе порой пригождается.
Про БД и MVC
Зачем джуниору лезть в запросы?
У вас часто джуниоры в системы запросы создают?
Может это дело модели по запросам строить саму себя?
А джуниор работает только с частью MVC?
Зачем джуниору лезть в запросы?
У вас часто джуниоры в системы запросы создают?
Может это дело модели по запросам строить саму себя?
А джуниор работает только с частью MVC?
До вопросов связанных с Framework'ами ни одного из претендентов не удалось довести, они валились на знаниях БД
Звучит как «до вопросов связанных с ПДД ни одного кандидата на вакансию водителя не удалось довести — они валились на знаниях технологии получения бензина».
В резюме вы указали, что знание JavaScript у Вас на уровне х (от 5 до 7 в 10-ти бальной), как получить ноду по id:
Ничего, что в JavaScript нет понятия «нода»? Это понятие DOM, которая в JavaScript не входит.
При использовании паттерна MVC, где мы впервые «встречается» с запросом:
В паттерне MVC такого понятия вообще нет.
Год назад я провалил Front-End тест из за неумения грамотно построить сайт/ньюслеттер используя таблицы (!) в HTML, хотя сейчас время div.
Обидно было тратить 1 день и 700км.
Обидно было тратить 1 день и 700км.
Попробуйте хоть куда-то, но все же в IT. Может быть стоит в админы. В команду какую-нибудь. Там и с людьми пообщаетесь — что очень ценно, от ИТ далеко не уйдете и строчка в резюме + рекомендацию заработаете. Незнаю как в Новосибе, но в Москве, если ты не лентяй, вполне реально с минимальными знаниями, на небольшую з/п, но в ИТ, к колегам, к знаниям и, что важнее, к кругозору в отрасли.
Скорее тогда не админом, а «эникейщиком». Именно админ без опыта — страшнее зверя нет ;) Но вообще, я сам нахожусь в Новосибирске и по роду деятельности уже около 14 лет являюсь работодателем для программистов разной специализации и уровня знаний.
И с моей точки зрения картинка какая-то инверсная выходит. Размещаешь вакансию на программиста PHP (на з/п чуть выше рынка) и потом долго-долго и упорно пытаешься выбрать из «грузчика мебельной фабрики» и «менеджера по продажам пылесосов»… В результате, за пару месяцев таки находишь человека.
Чтобы человек, который хоть что-то может писать на PHP (даже без реального опыта) не мог за ~20 т.р. найти работу в Новосибирске, имхо это какая-то фантастика.
Автору кстате, сильно советую вместе с php «подтягивать» sql и хоть чуть-чуть знать что такое NoSQL ибо без БД ни один реальный проект не живет. Также может стоить посмотреть в сторону Python'а, вакансий по нему поменьше, но зато и з/п выше, так как кол-во специалистов в Новосибе вообще стремится к 0.
Ну и ОДНОЗНАЧНО не стоит идти в область не связанную с IT. Все-таки когда приходит резюме программиста с опытом по «продажи пылесосов», смотрится это… ну как-то совсем не очень приятно :)
И с моей точки зрения картинка какая-то инверсная выходит. Размещаешь вакансию на программиста PHP (на з/п чуть выше рынка) и потом долго-долго и упорно пытаешься выбрать из «грузчика мебельной фабрики» и «менеджера по продажам пылесосов»… В результате, за пару месяцев таки находишь человека.
Чтобы человек, который хоть что-то может писать на PHP (даже без реального опыта) не мог за ~20 т.р. найти работу в Новосибирске, имхо это какая-то фантастика.
Автору кстате, сильно советую вместе с php «подтягивать» sql и хоть чуть-чуть знать что такое NoSQL ибо без БД ни один реальный проект не живет. Также может стоить посмотреть в сторону Python'а, вакансий по нему поменьше, но зато и з/п выше, так как кол-во специалистов в Новосибе вообще стремится к 0.
Ну и ОДНОЗНАЧНО не стоит идти в область не связанную с IT. Все-таки когда приходит резюме программиста с опытом по «продажи пылесосов», смотрится это… ну как-то совсем не очень приятно :)
Очень спорно. Направления всё-же слишком разные. Через год можно оказаться начинающим админом без какого-либо опыта в разработке. И всё с теми же перспективами.
Согласен с комментаторами выше — нужно продолжать искать место разработчика, может даже за бесплатно — на стажировку. Не стоит ограничиваться PHP. В крайнем случае фриланс.
Перерыв на самообучение может быть полезен, но год — слишком большой срок.
Согласен с комментаторами выше — нужно продолжать искать место разработчика, может даже за бесплатно — на стажировку. Не стоит ограничиваться PHP. В крайнем случае фриланс.
Перерыв на самообучение может быть полезен, но год — слишком большой срок.
По моему опыту работодателю всегда нужен просто смышлёный парень, который обладает базисом и при желании разберётся в незнакомых технологиях, потому что знать всё никто не может. Поэтому я не соглашусь с тем, что язык можно знать слабо, а фреймворки наоборот, мой опыт подсказывает совершенно противоположное. И ещё: на программистов сейчас спрос в разы выше, чем на специалистов других профессий, найти работу легко. Другое дело, что первая работа у всех плохо находится, просто потому, что опыта в поиске/собеседованиях нет (я бы, например, посоветовал идти не только на джуниоров, т.к. многие компании хотят найти хоть кого-то). Не отчаивайтесь, идите на 20-е, 30-е, 40-е собеседование (именно так, это тоже труд, особенно в начале), анализируйте и исправляйте ошибки, находите новые фишки и скоро у вас всё получится.
Я киевлянин и знаком с ситуацией в своей городе, применять мое мнение в для работодателей из других городов будет скорее всего ошибкой.
Первое, что хочу заметить про обучение. Не стоит уделять чересчур много времени теории. Знания (теоретические) без навыков (практического применения знаний) ничего не стоят. Так что всегда старайтесь закрепить то, что только что прочитали. И желательно десятком разнообразных задач, а не одним тестовым примером.
Второе, что касается самих вакансий. Есть компании, у которых вакансия джуниора означает поиск парня, на которого можно повесить стирку грязного белья. У них джун означает уровень ЗП, а не квалификацию соискателя. Подобные компании — отличное место для быстрого обучения в боевых условиях и последующего поиска адекватного работодателя.
Компания, которая осознает действительный уровень знаний джуниора никогда не будет требовать от него уверенного знания какого либо фреймворка или большого опыта работы (вакансии джунов с требованием уверенного использования принципов ООП и опытом разработки на РНР 1-3 года вызывают только улыбку). В подобных ваш конечный уровень определяется уже не столько знаниями, соклько навыками. Да, на одних навыках вы сможете вырости только до мидл уровня, синьер требует от вас хороших теоретических знаний и навыков использования этих знаний, но работая у работодателей второго класса вы сможете получить все необходимые знания и навыки. И самое главное, вы будете мотивированы оставаться работать и рости профессионально именно у них. К сожалению, подобных компаний не так много, как хотелось бы.
Первое, что хочу заметить про обучение. Не стоит уделять чересчур много времени теории. Знания (теоретические) без навыков (практического применения знаний) ничего не стоят. Так что всегда старайтесь закрепить то, что только что прочитали. И желательно десятком разнообразных задач, а не одним тестовым примером.
Второе, что касается самих вакансий. Есть компании, у которых вакансия джуниора означает поиск парня, на которого можно повесить стирку грязного белья. У них джун означает уровень ЗП, а не квалификацию соискателя. Подобные компании — отличное место для быстрого обучения в боевых условиях и последующего поиска адекватного работодателя.
Компания, которая осознает действительный уровень знаний джуниора никогда не будет требовать от него уверенного знания какого либо фреймворка или большого опыта работы (вакансии джунов с требованием уверенного использования принципов ООП и опытом разработки на РНР 1-3 года вызывают только улыбку). В подобных ваш конечный уровень определяется уже не столько знаниями, соклько навыками. Да, на одних навыках вы сможете вырости только до мидл уровня, синьер требует от вас хороших теоретических знаний и навыков использования этих знаний, но работая у работодателей второго класса вы сможете получить все необходимые знания и навыки. И самое главное, вы будете мотивированы оставаться работать и рости профессионально именно у них. К сожалению, подобных компаний не так много, как хотелось бы.
Я бы на вашем месте поискал работу в гос. компаниях. Там берут если человек хороший, собеседование больше как знакомство. Требования, впрочем как и зп — очень низкие.
Набраться опыта бесплатно тоже можно, берите Yii и делайте проект сами либо с другом ( подругой! )). Заливайте код на github, показывайте работодателю, получайте жирный + на собеседовании.
Еще не так давно был джуниором, поэтому могу поделиться своим опытом.
Очень важно выбрать хорошую компанию с крутыми людьми. Многие выбирают для первого опыта говноконторки, после чего весь свой опыт могут перенести только в другую говноконторку, так и оставаясь крутиться в подобном кругу до конца карьеры.
Нужно учиться у лучших. Читать самых крутых авторов, которых только можно найти, ходить на самые шикарные конференции, которые только можно посетить.
Учиться постоянно, везде и всюду. Неважно, относится это к PHP или нет. Дизайн, психология, публичные выступления, командная работа — отовсюду можно взять что-то, что поможет дальше. Очень многие знания о реальной жизни можно применить в программировании.
Заканчивать дело до конца, стремиться делать лучше. Будет очень трудно. А выйдя за пределы джуниора станет еще труднее, на самом деле (при условии, что захочется развиваться, а не сидеть на месте). Но нужно терпеть и преодолевать препятствия.
Важно информировать своего наставника о своих намерениях. Честно и открыто. И стараться понимать, почему он принял то или иное решение, касающееся вас. Ну и идти на диалог, спрашивать, узнавать что-то новое.
Очень круто писать свои проекты и выкладывать их в открытый доступ. Даже если это очень простой проект на пару вечеров. Это может сильно помочь при трудоустройстве.
Нужно смотреть много чужого кода. Даже если он с первого раза непонятен. Очень важный навык для разработчика.
Изучая простые вещи, не забывать про сложные. Использовал jQuery — посмотри как это можно сделать без него. Можно даже целые скрипты пробовать переписывать без того же jQuery.
И еще. Учиться пользоваться инструментами. Клавиатура — инструмент. Я научился печатать вслепую латиницей — теперь набирание кода не вызывает у меня головную боль. Раньше это было просто кошмаром. Git — тоже инструмент. Очень важно освоить терминал.
Если бы я выбирал самый важный пункт, то назвал бы “искать движуху и крутиться в ней постоянно”. Именно поэтому я в своё время переехал из Красноярска в Москву, именно поэтому я каждый день читаю в Твиттере самых крутых западных разработчиков.
Всем начинающим разработчикам могу посоветовать курс cs50.net. Основы программирования (и много чего еще крутого) от Гарвардского университета.
Все эти вещи достаточно общие. Но мне помогли. Может, помогут еще кому-нибудь. Удачи в поисках :)
Очень важно выбрать хорошую компанию с крутыми людьми. Многие выбирают для первого опыта говноконторки, после чего весь свой опыт могут перенести только в другую говноконторку, так и оставаясь крутиться в подобном кругу до конца карьеры.
Нужно учиться у лучших. Читать самых крутых авторов, которых только можно найти, ходить на самые шикарные конференции, которые только можно посетить.
Учиться постоянно, везде и всюду. Неважно, относится это к PHP или нет. Дизайн, психология, публичные выступления, командная работа — отовсюду можно взять что-то, что поможет дальше. Очень многие знания о реальной жизни можно применить в программировании.
Заканчивать дело до конца, стремиться делать лучше. Будет очень трудно. А выйдя за пределы джуниора станет еще труднее, на самом деле (при условии, что захочется развиваться, а не сидеть на месте). Но нужно терпеть и преодолевать препятствия.
Важно информировать своего наставника о своих намерениях. Честно и открыто. И стараться понимать, почему он принял то или иное решение, касающееся вас. Ну и идти на диалог, спрашивать, узнавать что-то новое.
Очень круто писать свои проекты и выкладывать их в открытый доступ. Даже если это очень простой проект на пару вечеров. Это может сильно помочь при трудоустройстве.
Нужно смотреть много чужого кода. Даже если он с первого раза непонятен. Очень важный навык для разработчика.
Изучая простые вещи, не забывать про сложные. Использовал jQuery — посмотри как это можно сделать без него. Можно даже целые скрипты пробовать переписывать без того же jQuery.
И еще. Учиться пользоваться инструментами. Клавиатура — инструмент. Я научился печатать вслепую латиницей — теперь набирание кода не вызывает у меня головную боль. Раньше это было просто кошмаром. Git — тоже инструмент. Очень важно освоить терминал.
Если бы я выбирал самый важный пункт, то назвал бы “искать движуху и крутиться в ней постоянно”. Именно поэтому я в своё время переехал из Красноярска в Москву, именно поэтому я каждый день читаю в Твиттере самых крутых западных разработчиков.
Всем начинающим разработчикам могу посоветовать курс cs50.net. Основы программирования (и много чего еще крутого) от Гарвардского университета.
Все эти вещи достаточно общие. Но мне помогли. Может, помогут еще кому-нибудь. Удачи в поисках :)
Мои 5-ть копеек в обсуждение ;)
Я начинал в РНР, когда он был действительно прост, версия 3, и постепенно понял, что мне в WEB интересно, а что нет.
Одно время мне было даже трудно найти работу, с моим 8-летнем опытом работы, так-как JS-CSS программист из меня ни какой, а большинству кокмпаний требуется универсал PHP-JS-HTML… А мне, было интересно чисто серверное программирование, в котором я позицианируюсь, как квалифицированный в области highload.
В настоящее время, я работаю в интересном проекте и занимаюсь тем, что мне интересно. Для меркальтильных скажу (хотя дело далеко не в деньгах), что зарабатываю не много, но в среднем выше, чем простой РНР-программист в нашем регионе. У меня были предложения на должности руководства проектом и зарплату в два раза больше, но я руководствуюсь принцепом Питера: каждый достигает своего уровня некомпетентности. Лучше быть хорошим разработчиком, чем плохим директором. В общем у каждого в жизни своя философия…
Тут есть два варианта:
— устроиться на любую работу, чтоб себя как-то кормить и точить мастерство.
— просто точить мастерство и искать то, что тебе интересно.
Вы правильно отметили, что каждое собеседование — это хороший шанс узнать свои белые пятна. Но тут, очень важно понять, что тебе интересно и куда лучше копать, потому-что, в современном WEB: НЕЛЬЗЯ ОБНЯТЬ НЕОБЪЯТНОЕ.
По этому, надо иметь хороший кругозор в этой области, но копать куда-то в одно направление, которое тебе лучше дается и интересно для тебя и позиционировать себя именно в этой области.
И надо еще понимать, что НР будут смотреть на employment history, и если они увидят, что в прошлом, ты продавал колготки, то у тебя остаётся все меньше и меньше шансов занять интересную позицию. В моей карьере был период, где я по разным причинам часто менял работу. Многие HR постоянно на это обращают внимание.
одни золотые слова, не помню из какой книжки по управлению проектами: «надо искать команду, где ты самый слабый игрок» далее твое мастерство растет… и ты снова ищешь более сильную команду…
Я начинал в РНР, когда он был действительно прост, версия 3, и постепенно понял, что мне в WEB интересно, а что нет.
Одно время мне было даже трудно найти работу, с моим 8-летнем опытом работы, так-как JS-CSS программист из меня ни какой, а большинству кокмпаний требуется универсал PHP-JS-HTML… А мне, было интересно чисто серверное программирование, в котором я позицианируюсь, как квалифицированный в области highload.
В настоящее время, я работаю в интересном проекте и занимаюсь тем, что мне интересно. Для меркальтильных скажу (хотя дело далеко не в деньгах), что зарабатываю не много, но в среднем выше, чем простой РНР-программист в нашем регионе. У меня были предложения на должности руководства проектом и зарплату в два раза больше, но я руководствуюсь принцепом Питера: каждый достигает своего уровня некомпетентности. Лучше быть хорошим разработчиком, чем плохим директором. В общем у каждого в жизни своя философия…
Тут есть два варианта:
— устроиться на любую работу, чтоб себя как-то кормить и точить мастерство.
— просто точить мастерство и искать то, что тебе интересно.
Вы правильно отметили, что каждое собеседование — это хороший шанс узнать свои белые пятна. Но тут, очень важно понять, что тебе интересно и куда лучше копать, потому-что, в современном WEB: НЕЛЬЗЯ ОБНЯТЬ НЕОБЪЯТНОЕ.
По этому, надо иметь хороший кругозор в этой области, но копать куда-то в одно направление, которое тебе лучше дается и интересно для тебя и позиционировать себя именно в этой области.
И надо еще понимать, что НР будут смотреть на employment history, и если они увидят, что в прошлом, ты продавал колготки, то у тебя остаётся все меньше и меньше шансов занять интересную позицию. В моей карьере был период, где я по разным причинам часто менял работу. Многие HR постоянно на это обращают внимание.
одни золотые слова, не помню из какой книжки по управлению проектами: «надо искать команду, где ты самый слабый игрок» далее твое мастерство растет… и ты снова ищешь более сильную команду…
По-моему 20 собеседований и 12+ тестовых заданий — перебор. Возможно, у вас в городе так много достойных на первый взгляд фирм, но как-то слишком… Я когда решил устроиться — выбрал около 3-5 фрим, куда стоит подать резюме, и после 2-ого собеседования устроился. Хотя у всех свои запросы и знания.
Здравствуйте, я, пожалуй, добавлю свои 5 копеек к остальным: я начал заниматься веб-разработкой в 16-17 лет, т.е. еще в то время, когда только набирал обороты и был хипстерной заменой перлу :) Так как мне было 16-17 лет, я не мог устроиться ни на какую работу(да и какая работа, выпускные экзамены же были), поэтому рассматривался только вариант удаленной работы, т.е. фриланса. Первые заказы я получил от товарищей, и это сразу же научило меня никогда не иметь финансовых отношений с друзьями. Потом всё пошло через сарафанное радио. Я не скажу, что заказов было много, буквально один в несколько месяцев, но мне, как школьнику, этого хватало. Первые ваши заказы — это опыт в чистом виде. Совершенно авантюрный, скорее всего почти бесплатный, но опыт. Вы получите сразу очень много новых навыков: научитесь общаться с заказчиком, понимать его, планировать свою работу, быстро у
чить смежные технологии, пользоваться чужими наработками и т.д. Дальше, как получится. У меня получилось так, что на втором курсе я нашел постоянку в одной частной конторе за 30 тыс. руб. Я как сейчас помню, как радовался тогда… Ну да ладно, не об этом. Дальше — больше. Разумеется, вам потребуется знать HTML+CSS, ибо джуниоров всегда рассматривают как разнорабочих. Компания нанимает ресурс для IT целей, а чем вы будете заниматься — от починки принтера до программирования на JS — это решать начальству(к сожалению, это кругом и рядом). Вы становитесь в оч. выгодном положении: у вас есть работа, на которой вам платят за то, что вы учитесь.
Если будет что-то интересно — пишите в личку, я с удовольствием поделюсь своим опытом :)
чить смежные технологии, пользоваться чужими наработками и т.д. Дальше, как получится. У меня получилось так, что на втором курсе я нашел постоянку в одной частной конторе за 30 тыс. руб. Я как сейчас помню, как радовался тогда… Ну да ладно, не об этом. Дальше — больше. Разумеется, вам потребуется знать HTML+CSS, ибо джуниоров всегда рассматривают как разнорабочих. Компания нанимает ресурс для IT целей, а чем вы будете заниматься — от починки принтера до программирования на JS — это решать начальству(к сожалению, это кругом и рядом). Вы становитесь в оч. выгодном положении: у вас есть работа, на которой вам платят за то, что вы учитесь.
Если будет что-то интересно — пишите в личку, я с удовольствием поделюсь своим опытом :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что должен знать «PHP Junior Developer без опыта работы»?