Comments 68
Решение может звучать просто, выберите что Вам больше по душе и вперёд!
Но лично для меня вот эта вот проблема выбора всегда была самой сложной.
Например Frontend или Backend. Особенно если интересно и то и другое.
Честно говоря пока так до конца и не научился эту проблему решать, всегда много беспокойства и волнения о правильности принятого решения.
И это не только в работе…
И мне всегда было интересно насколько эта проблема актуальна для других.
Буду рад если кто-нибудь поделиться своим опытом))
Но лично для меня вот эта вот проблема выбора всегда была самой сложной.
Например Frontend или Backend. Особенно если интересно и то и другое.
Честно говоря пока так до конца и не научился эту проблему решать, всегда много беспокойства и волнения о правильности принятого решения.
И это не только в работе…
И мне всегда было интересно насколько эта проблема актуальна для других.
Буду рад если кто-нибудь поделиться своим опытом))
Дело в том, что Ваня очень любит программирование, но если он окажется перед выбором Frontend или Backend, то выбор будет за последним. Но, к сожалению для Вани, руководителям компании в которой он работает «нужен» программист, пишущий буквально на всем.
Я бы ушел в другую компанию. Да после института это, совсем не вопрос :)
О ну если Ваня для себя уже точно знает ответ то здорово.
Подумав — решайся, а решившись — не думай!
Руководитель компании может ещё захотеть чтобы Ваня карбюраторы умел настраивать, и много чего другого.
Тут уж Ваня сам должен решать, идти к своим целям или к тому чего хочет руководитель.
Принимать ответственность за свою жизнь, и не попадать в позицию жертвы (руководитель хочет и т.д.) для Вани главное чего хочет Ваня.
Если это не то же самое чего хочет руководитель то им не по пути и тут вопрос только в том как много времени уйдёт у Вани на то чтобы это понять.
И так будет лучше для обоих, руководитель найдёт себе работника который хочет писать на всём (да и такие люди бывают) а Ваня найдёт себе работу где он будет заниматься тем что ему интересно. И все будут счастливы!
Подумав — решайся, а решившись — не думай!
Руководитель компании может ещё захотеть чтобы Ваня карбюраторы умел настраивать, и много чего другого.
Тут уж Ваня сам должен решать, идти к своим целям или к тому чего хочет руководитель.
Принимать ответственность за свою жизнь, и не попадать в позицию жертвы (руководитель хочет и т.д.) для Вани главное чего хочет Ваня.
Если это не то же самое чего хочет руководитель то им не по пути и тут вопрос только в том как много времени уйдёт у Вани на то чтобы это понять.
И так будет лучше для обоих, руководитель найдёт себе работника который хочет писать на всём (да и такие люди бывают) а Ваня найдёт себе работу где он будет заниматься тем что ему интересно. И все будут счастливы!
UFO just landed and posted this here
Уметь использовать несколько языков программирования и фреймворков, это хорошо, но, необходимо не распыляться, и для начала стать профессионалом в чем то одном
У Вани было мало опыта программирования вообще. При его наличии можно разобраться с любым направлением на джуниорском уровне (не считая специфичных знаний для прикладной области) за реалистичные сроки. Конечно, карьерный рост это тормозит, но при необходимости горизонтальной миграции — вполне реально. Как иначе
Более того: широкий кругозор здорово помогает в работе.
Искусственные ограничения — это быстрый путь к выгоранию.
Мне кажется, Ване надо определиться с конечной целью. Программер чего хочет быть? Прикладного софта, либо специализированного какого-то. А уже исходя из конечной цели определить круг языков для горизонтальной миграции перед вертикальным взлетом. Из моей практики — познал тонкости и особенности конструкторов во фреймворке 2.0, прежде чем допер их же во фреймворке 1.0
Может этому Ване стоило найти подходяющую вакансию на C#, но не на сеньёра, а хотя бы мидла или джуниора? так зато точно он будет уверенно себя чувствовать. Если действительно знает и умеет многое, то и повысят его до того же сеньёра
Да, вроде и не писалось, что позиция на сеньёра. Я не в курсе по C#, но на Java у нас постоянно людей ищут, то есть позиций открыто десятки по городу. Так что если есть какой-никакой опыт, то начать работать можно легко — было бы желание.
Он ходил на интервью на позицию Middle C# Developer. Возможно, из-за того, что в его практике не было надобности писать закрытые классы (sealed), а также точно знать, что классы, объявленные без модификатора, по умолчанию имеют доступ internal (а такие вопросы были в тесте) и т.д. Почему? Потому-что Ваня один в ИТ-отделе, кто пишет код. Никто другой не будет расширять или редактировать его программу.
А, ну этого то я не знал. Я так решил по строчке:
"Senior C# Developer'ом"
Пробелы в знаниях по этим вопросам, а это — типичные вопросы на собеседовании C# разработчика любого уровня, говорят о поверхностном знании языка. Следовательно, его просто надо подучить, если хочется дальше идти в этом направлении.
Я, в своё время, просто усиленно изучал язык параллельно с работой, с которой собирался уходить по той же причине, что и Иван. Ну и специально готовился к интервью — материалов специально для этого навалом.
Так же можно, хотя это очень не просто, поискать опытного разработчика, кто мог бы поделать код-ревью Ваниным проектам, может даже за плату. Потому что если Ваня сейчас в конторе один кодит, у него там может быть страшный ужас в исходниках, а на это опытные интервьюеры обращают внимание.
Проблема в том, что Ваня знает язык на практике. Когда нужно было что-то написать — он брал и писал так, чтобы работало. Нужно уделить больше внимания теории. Возможно, стоит устроиться на позицию джуниора, чтобы понять чего не хватает.
Нужно понимать, что Middle подразумевает под собой наличие серьёзного набора навыков и возможность выполнять большинство задач по разработке «с ходу». В моём городе Middle developer получает больше 2 средних зарплат и разработчик на данной позиции должен приносить соответствующий доход компании. Незнание таких элементарных вещей, как области видимости и основы наследования, не допустимо. Думаю, про SOLID Ваня даже и не слышал, хотя это ближе к требованиям Middle, чем основы языка.
Как человек, прошедший похожий путь могу сказать, что нужно перестать обманывать себя, завышая свой уровень навыков. Стоит прочитать пару книг по C#, изучить git, начать использовать dependency injection. Нужно уделять больше внимания актуальным технологиям: не нужно тратить время на Web Forms, Windows Forms, Silverlight, LinqToSql, ADO.NET и т.п. Можно попробовать посмотреть в сторону ASP.NET Core. Обязательно нужно научиться хорошо использовать Linq — это требуется везде. Для позиции Web-разработчика нужно знать HTTP-протокол и понимать что происходит на сервере от получения запроса до отправки ответа. Примеров можно привести очень много, так что «учиться, учиться и ещё раз учиться».
Нужно понимать, что Middle подразумевает под собой наличие серьёзного набора навыков и возможность выполнять большинство задач по разработке «с ходу». В моём городе Middle developer получает больше 2 средних зарплат и разработчик на данной позиции должен приносить соответствующий доход компании. Незнание таких элементарных вещей, как области видимости и основы наследования, не допустимо. Думаю, про SOLID Ваня даже и не слышал, хотя это ближе к требованиям Middle, чем основы языка.
Как человек, прошедший похожий путь могу сказать, что нужно перестать обманывать себя, завышая свой уровень навыков. Стоит прочитать пару книг по C#, изучить git, начать использовать dependency injection. Нужно уделять больше внимания актуальным технологиям: не нужно тратить время на Web Forms, Windows Forms, Silverlight, LinqToSql, ADO.NET и т.п. Можно попробовать посмотреть в сторону ASP.NET Core. Обязательно нужно научиться хорошо использовать Linq — это требуется везде. Для позиции Web-разработчика нужно знать HTTP-протокол и понимать что происходит на сервере от получения запроса до отправки ответа. Примеров можно привести очень много, так что «учиться, учиться и ещё раз учиться».
Нужно уделять больше внимания актуальным технологиям: не нужно тратить время на… ADO.NET и т.п.
Такие фундаментальные вещи знать как раз стоит.
Кому сейчас нужен голый ADO.NET, когда есть, как минимум, Dapper? Конечно есть смысл почитать про connected layer, т.к. там, скорее всего, будет написано про SQL-инъекции и как с ними бороться.
На практике же connected layer почти никогда не видел, disconnected layer — тем более.
Эти советы больше были нацелены на то, что обычно требуется знать на собеседовании.
На практике же connected layer почти никогда не видел, disconnected layer — тем более.
Эти советы больше были нацелены на то, что обычно требуется знать на собеседовании.
Тому, кто хочет понять, как работают технологии, вроде того же Dapper, очевидно.
Из этого не следует, что никому эти знания не пригодятся.
На собесах некоторые как раз любят спрашивать оторванную от жизни теорию. И высшее образование, которое «пустая трата времени», спрашивают в каждой первой достаточно матёрой конторе.
Но почему фокус мотивации именно на «пройти собеседование», вместо «понять технологию»?
На практике же connected layer почти никогда не видел, disconnected layer — тем более.
Из этого не следует, что никому эти знания не пригодятся.
Эти советы больше были нацелены на то, что обычно требуется знать на собеседовании.
На собесах некоторые как раз любят спрашивать оторванную от жизни теорию. И высшее образование, которое «пустая трата времени», спрашивают в каждой первой достаточно матёрой конторе.
Но почему фокус мотивации именно на «пройти собеседование», вместо «понять технологию»?
Но почему фокус мотивации именно на «пройти собеседование», вместо «понять технологию»?
Потому что это и есть изначальная задача Вани, из-за невыполнения которой он так сильно расстраивается. Я не говорю, что такой путь — верный.
Если смотреть как работает Dapper, то там и ILGenerator используется. Вы же не будете советовать изучать такие специфические вещи.
вместо «понять технологию»
Потому то часто технологию бессмысленно изучать до тонкостей — всё меняется очень быстро. Возьмём OpenGL. Вот скажите, зачем в 2000-м я его изучал в версии 1, когда сейчас уже версия 4 со совершенно иными принципами? А кому нужен сейчас MFC и Win32API? Но я потратил несколько лет на них. Ради чего?
Потому то часто технологию бессмысленно изучать до тонкостей — всё меняется очень быстро.
Базовые технологии меняются достаточно медленно. Тот же ADO.NET не спешит это делать.
в 2000-м я его изучал в версии 1, когда сейчас уже версия 4 со совершенно иными принципами?
0_о
За эти годы человек мог бы успеть родиться и научиться разрабатывать под OpenGL актуальной версии.
А кому нужен сейчас MFC и Win32API?
MFC — это не базовая технология, а достаточно тонкая обертка над системным API + немного магии виззардов.
WinAPI никуда не делся и все так же используется любыми библиотеками, которые строятся поверх него. Как вообще можно познать винды, проигнорировав системные интерфейсы?
За эти годы человек мог бы успеть родиться и научиться разрабатывать под OpenGL актуальной версии.
Чтобы досконально с технологией разобраться, требуется довольно много лет и часто море напряжённого труда. И да, человек кроме OpenGL, наверное, тоже чем-то занят. Скажем, разбирается с другими вещами, проектирует и изучает. И ресурсы на постоянное изучение меняющихся стандартов тоже нужны. Разберётесь вы с версией 2, а уже 3 готова. Вы с 3, а уже 4. Вам не надоест за ними бегать? В чём был плюс OpenGL — в долговременности стандарта. Он десятилетие не менялся. А тут за 18 лет раз и сразу три раза обновился. Изучать постоянно меняющийся стандарт та ещё морока.
MFC — это не базовая технология, а достаточно тонкая обертка над системным API + немного магии виззардов.
Местами она нифига не тонкая, например, во всяких документ-видах. И таки это технология и достаточно базовая, чтобы можно было написать вполне рабочее приложение, не связываясь с Win32API. И «магия», которую вы упомянули, это и есть то, что составляет тонкости реализации MFC. Попробуйте написать без wizard'а — вам понравится, ручаюсь. Все эти declare_dyncreate выучите. :) И заодно море нюансов отыщите в работе MFC, получив множество раз Segmentation Fault.
WinAPI никуда не делся и все так же используется любыми библиотеками, которые строятся поверх него. Как вообще можно познать винды, проигнорировав системные интерфейсы?
Речь не о библиотеках — вы их вряд ли будете писать сами. Речь о том, требуется ли это вообще в вашей работе. Скажем, на C#. (Сразу говорю, я с C# не знаком).
Чтобы досконально с технологией разобраться...
Доскональность редко бывает нужна, но общие представление наверняка необходимо.
Попробуйте написать без wizard'а — вам понравится, ручаюсь.
Отсутствие гибкости MFC и погубило. Но это не базовая технология, повторюсь.
Речь не о библиотеках — вы их вряд ли будете писать сами.
Этого достаточно, чтобы не возводить личные впечатления в абсолют.
Скажем, на C#
У сишарпа другой круг задач. Послушать веб-фронтендеров — так и .NET Framework окажется не нужен (=
Доскональность редко бывает нужна, но общие представление наверняка необходимо.
А общих представлений, окажется, мало. В общих-то чертах много чего можно знать, но вот дойдёт до реализации и будет швах. В любом случае, есть очень много вещей, на которые вы потратите силы и время, но они быстро устареют/их скроют библиотеки/фреймворки и не понадобятся.
Но это не базовая технология, повторюсь.
А что для вас базовая технология?
В общих-то чертах много чего можно знать, но вот дойдёт до реализации и будет швах.
Вы меня увели в те степи, с которыми я мало знаком, поэтому буду теоретизировать (=
Если речь идет про использование библиотек поверх OpenGL (Glut или что там выше и актуальнее?), то вряд ли нужно знать досконально сам OpenGL. Однако, вряд ли будет лишним знать о его каких-то особенностях.
А что для вас базовая технология?
То, на чем основываются другие, специфические технологии с более коротким циклом жизни.
Glut или что там выше и актуальнее?
Не знаю, как сейчас, но раньше в версии 1, glut просто дополняла opengl рядом своих специфических функций и никак не отменяла необходимости работы с командами opengl.
То, на чем основываются другие, специфические технологии с более коротким циклом жизни.
Ну, тогда у нас с вами разная терминология. Я под базовой полагаю то, что позволяет на основе данной технологии решать некую задачу (скажем, работать с базой данных, отображать GUI и так далее).
А кстати, вы GUI-приложения под Windows на Си++ на чём делаете, если не секрет (если делаете)?
тогда у нас с вами разная терминология. Я под базовой полагаю то, что позволяет на основе данной технологии решать некую задачу
Я хотел показать пример текущих абстракций, но вряд ли смогу сейчас успеть что-то убедительное нагуглить про графику, но не буду, дабы не смешить)
вы GUI-приложения под Windows на Си++ на чём делаете, если не секрет (если делаете)?
Специфично под Windows я десктопные приложения не разрабатываю, но при необходимости я бы выбрал Qt Widgets.
Но ведь GUI Windows API не ограничивается.
Я хотел показать пример текущих абстракций,
Так речь всё равно не о графике, а о том, что бессмысленно сейчас глубоко изучать технологию, если она всё равно быстро устареет или просто будет экранирована очередным фреймворком. Забавно, в 2006 в вакансиях просили COM, CORBA, OLE, ActiveX и ATL. А я всего этого не знал, комплексовал и по этой причине не ходил на собеседования, но накупил книжек (но тот же ATL забыл сразу после попытки прочтения — это очень тяжко, пытаться понимать концепции всего этого и разбираться с синтаксисом и порядком действий). И пошёл в подобную контору (в НИИ), что и у Вани из статьи. Только разрабатывать нужно под QNX и под Windows и MS-DOS. И с тех пор там и работаю.
Сейчас в вакансиях такого уже не упоминается. Видно, никто напрямую с ними давно не работает. И это хорошо. :)
Qt Widgets
Я бы тоже его бы выбрал, но он тоже меняется. Неприятно. Не успеваешь книжки покупать и прочесть. :)
Но ведь GUI Windows API не ограничивается.
Конечно, нет. Но у меня из насущного вопрос, на чём сейчас пишут GUI для Windows на Си++.
бессмысленно сейчас глубоко изучать технологию, если она всё равно быстро устареет или просто будет экранирована очередным фреймворком
Кмк, значит копали недостаточно глубоко) На своей практике почти не встречал такого, чтобы что-то такое основное и монументальное переставало быть актуальным в течении короткого времени. Даже в том же «стремительном» вебе базовые технологии (HTTP, Ajax, WebSockets, WebWorkers, ES/JS) появляются и мутируют оооочень медленно, несмотря на еженедельно сменяющие друг друга фреймворки и библиотеки сверху.
чтобы что-то такое основное и монументальное переставало быть актуальным в течении короткого времени.
Тут больше вопрос, какой срок вы считаете коротким. Для меня это лет 10, не меньше. Что касается WEB, то всё ещё часто используют CSS? :)
Что касается WEB, то всё ещё часто используют CSS? :)
Простите, а как можно его не использовать?
Для меня важно, чтобы технология поддерживала обратную совместимость (хотя бы идеологическую), чтобы ее можно было выучить не отвлекаясь на новые «модные штучки, которые изменят всё!». Часто это можно делать даже по старым книжкам (тот же олдовый Страуструп по С++03 все еще торт или Шилдт по C# 4.0).
CSS можно не использовать, но знать/понимать необходимо. Ибо на нем базируются препроцессоры, а в рантайме от них толку мало.
С ES5 похожая ситуация (сейчас IE11 для меня референс «нижней планки»).
CSS можно не использовать, но знать/понимать необходимо. Ибо на нем базируются препроцессоры, а в рантайме от них толку мало.
С ES5 похожая ситуация (сейчас IE11 для меня референс «нижней планки»).
Вот! Обратная совместимость. Вот только частенько слышно «выкиньте это легаси нафиг»! Тут вот, недавно, писали, что Apple тот же OpenGL объявила устаревшим. По факту, это значит, очередное изучение нового для разработчиков под их технику. Честно, это очень утомляет со временем. Старое ещё в совершенстве не изучено, а тут новое уже надо учить. Ручаюсь, это только в юности кажется увлекательным, но с возрастом приходит утомляемость и информационная перегруженность, и единственная реакция будет «шо?! опять?!». :)
Да как сказать… По моим данным, подход к проектированию всё же изменился — теперь в ходу семантика перемещения, лямбды и прочие чудеса нового стандарта. :) То есть, Си++ вы, конечно, узнаете из этой книжки — эта часть не устарела. Но несколько поменялись подходы к разработке, и теперь тот старый Си как старый конь и борозда (не портит, но и новой не вспашет).
тот же олдовый Страуструп по С++03 все еще торт
Да как сказать… По моим данным, подход к проектированию всё же изменился — теперь в ходу семантика перемещения, лямбды и прочие чудеса нового стандарта. :) То есть, Си++ вы, конечно, узнаете из этой книжки — эта часть не устарела. Но несколько поменялись подходы к разработке, и теперь тот старый Си как старый конь и борозда (не портит, но и новой не вспашет).
По факту, это значит, очередное изучение нового для разработчиков под их технику.
У них почему-то такая стратегия) Что языки, что фреймворки. Возможно, они считают, что набрали достаточную критическую массу, чтобы такой жестью перетянуть разработчиков и часть рынка на себя. Но у меня такое подозрение, что политики здесь действительно больше, чем технологии. Это родственная черта объединяющая Apple и Microsoft.
Да как сказать… По моим данным, подход к проектированию всё же изменился
Тут согласен отчасти, подходы изменились. Но та книжка тоже строится по восходящей: от модульности на си-подмножестве к ООП. Переход к move-семантике и умным указателям будет выглядеть такой же эволюцией.
Ване необходимо вернуться к истокам, а точнее, к моменту понимания
Надо понять что именно тогда его зацепило в ИТ — скорее всего понимание этого вернет его на правильные рельсы, с которых он ушел, прыгая между проектами. И тогда он уже сможет выбирать не только между компаниями S и N, а еще и между геймстудиями, открытием собственной ИТ-компании, созданием искусственного интеллекта и т.д.
что нет в жизни лучше профессии чем профессия программиста
Надо понять что именно тогда его зацепило в ИТ — скорее всего понимание этого вернет его на правильные рельсы, с которых он ушел, прыгая между проектами. И тогда он уже сможет выбирать не только между компаниями S и N, а еще и между геймстудиями, открытием собственной ИТ-компании, созданием искусственного интеллекта и т.д.
Программирования было много. Изучали C#, R, немного Java, PHP, JavaScript, HTML, CSS, и несколько фреймворков.
А надо было изучать Python, алгоритмы, С, С#/Java и архитектуру. А не пхп с фреймворками.
Алгоритмы в большинстве случаев ни к чему. Вполне достаточно того, что изучали в универе.
Это как раз и происходило в ВУЗе. "Алгоритмы ни к чему" слышу довольно часто. Скажу только своё мнение — нет, к чему. Предлагаю не флеймить на эту тему.
Слишком громкое высказывание. В наш век гигагерцев в большинстве случаев тормозят именно алгоритмы (и абстракции), а не железо.
Для каких задач? Двигать блоки в двух измерениях — возможно, физические движки разрабатывать — вряд ли.
Вполне достаточно того, что изучали в универе.
Для каких задач? Двигать блоки в двух измерениях — возможно, физические движки разрабатывать — вряд ли.
Далеко не все разрабатывают физические движки. Типичная задача среднестатистического .NET разработчика — отображение данных из БД на клиенте через веб-сервис. Если Ване в вузе рассказывали, например, про алгоритмы поиска пути, то, при необходимости, он прочитает про нужный алгоритм ещё раз и без труда его реализует.
Типичная задача среднестатистического .NET разработчика
А откуда берутся «нетипичные» разработчики?) Зачем себя ограничивать сразу?
Тем более дотнет — штука инфраструктурная для интерпрайза, здесь никогда нет лишней производительности, как на клиентских приложениях. Если на нем кто-то хреначит лендинги без бизнес-логики, то это печально)
Проблема работы в таких компаниях это поверхностность. Человек из ИТ отдела воспринимается как мастер на все руки — и платежку в 1С сделать и принтер починить и веб-сайт обновить. При такой работе нарабатывается большой объем практических навыков, НО без глубокого понимания технологий и, что тоже важно, без опыта работы по процессам, так как в таких компаниях их попросту нет. Тесты и технические интервью в софтверных компаниях направлены как раз на измерение глубины понимания технологий, как это работает «под капотом», это не про «как прикрутить авторизацию к сайту», а про «какие критерии выбора между struct и class при проектировании системы и какие сущности вы бы сделали struct, а какие class и почему». Я нанимаю людей регулярно, сколько собеседований провел не реально сосчитать, и я кандидатов из таких мест вижу сразу. Именно среди таких кандидатов можно услышать ответ — я загуглю, ибо это именно то, как они разрабатывают. В итоге они действительно много умеют, но смотреть на их код страшно и без слез не получается — он суть каша из надерганных отовсюду кусков, без особой структуры и последовательности проектирования. Поддерживать такие приложение боль. И конечно такое в профильных компаниях никто видеть не хочет. Также у людей слабое представление о работе в команде и о процессах. Часто потом это боль тимлида как-то убедить человека, что делать из кода кашу это плохо и что процессы не для того, что бы менеджерам было чем заняться.
Совет здесь один — если хочется стать именно профессиональным разрабом, то надо идти в софтверную компанию — там будет правильная среда, у кого поучиться и перенять знания и опыт, там будет возможность увидеть красивый код и понять в чем же там суть. И чем раньше идти, тем лучше. Чем дольше сидите в компании в роли ИТ-специалиста-на-все-руки, тем сложнее потом научиться делать вещи правильно. Когда я учился играть на барабане мне мой препод сказал тоже самое — самое сложное переучивать самоучек, у них уже наработана неправильная моторика.
Из практических советов — готовьтесь к интервью. Никогда не приходите на техническое интервью, полагаясь лишь на личный практический опыт — 100% будут копать там, где опыта нету. Перед интервью прочитайте или хотя бы пролистайте если уже читали год-два назад нормальную книгу по теме.
И выводы Вани в целом верные — хочется быть разрабом, надо работать в окружении разрабов, а не админов.
Совет здесь один — если хочется стать именно профессиональным разрабом, то надо идти в софтверную компанию — там будет правильная среда, у кого поучиться и перенять знания и опыт, там будет возможность увидеть красивый код и понять в чем же там суть. И чем раньше идти, тем лучше. Чем дольше сидите в компании в роли ИТ-специалиста-на-все-руки, тем сложнее потом научиться делать вещи правильно. Когда я учился играть на барабане мне мой препод сказал тоже самое — самое сложное переучивать самоучек, у них уже наработана неправильная моторика.
Из практических советов — готовьтесь к интервью. Никогда не приходите на техническое интервью, полагаясь лишь на личный практический опыт — 100% будут копать там, где опыта нету. Перед интервью прочитайте или хотя бы пролистайте если уже читали год-два назад нормальную книгу по теме.
И выводы Вани в целом верные — хочется быть разрабом, надо работать в окружении разрабов, а не админов.
«какие сущности вы бы сделали struct, а какие class и почему»
Забавно… первая реакция была — ну так это же разные вещи… а потом понял, что внятно объяснить я не могу. В зависимости от ситуации и так и так можно/нужно. Нужен уточняющий вопрос — а какие сущности есть — огласите весь список, пожалуйста! )))
Забавно… первая реакция была — ну так это же разные вещи… а потом понял, что внятно объяснить я не могу. В зависимости от ситуации и так и так можно/нужно. Нужен уточняющий вопрос — а какие сущности есть — огласите весь список, пожалуйста! )))
В этом вся суть вопроса :) Именно что в зависимости от ситуации и собственно цель — посмотреть как человек размышляет, какие примеры-ситуации может привести или из личного опыта или просто придумать. Это разные вещи, но в то же время столько общего — и у тех и других есть свойства и методы, даже конструкторы есть. Но есть важные отличия, которые в определенных задачах дают четкий ответ — вот это я делаю структурами. И часто люди на собеседовании не могут привести ни одного практического примера, когда бы они при проектировании объектной модели выбрали бы структуру, а не класс. То есть они в принципе не понимают отличий и для чего в языке есть обе конструкции и не имели опыта проектирования систем, где бы такое отличие играло роль. И если опыт дело наживное, то не понимание отличий просто говорит о поверхностности знаний. Они все делают классами no matter what :)
Кстати, вы ведь про C# говорите? Ну, его я не знаю и ничего сказать не могу, а вот в обычном Си++, как по-вашему, когда стоит использовать struct, а не class? Они там абсолютно одинаковы, за исключением доступа по-умолчанию и при наследовании. И получается, что struct стоит писать только чтобы показать, что это просто собранные вместе данные и методов иметь они не будут по замыслу разработчика, а class те же данные, но с методами обработки внутри. Но это уже условности — можно и в struct засунуть методы (хотя исторически в Си их там быть не может вовсе).
Да, я говорю про C#, в нем структуры являются value-type, тогда как классы — reference-type. Что создает серъезные отличия в способе работы с памятью.
В С++ отличия действительно больше в области философии программирования.
В С++ отличия действительно больше в области философии программирования.
За счет разного написания class и struct и связанных с этим ассоциаций можно увеличивать читабельность кода. Например, мне лично нравится, когда struct — это «тупые» классы, которые просто хранят данные для какой-то обработки и ничего особо с ними не делают (почти всегда — POD, но не любой POD). А class — это уже что-то более сложное, с поведением, может, даже наследованием.
В целом, я бы ответил «Старался бы повысить читабельность кода, поэтому делал бы как принято в проекте. Если в проекте нет консенсуса, предложил бы вариант, описанный выше».
В целом, я бы ответил «Старался бы повысить читабельность кода, поэтому делал бы как принято в проекте. Если в проекте нет консенсуса, предложил бы вариант, описанный выше».
Именно среди таких кандидатов можно услышать ответ — я загуглю, ибо это именно то, как они разрабатывают.
…
он суть каша из надерганных отовсюду кусков, без особой структуры и последовательности проектирования.
Ну, вообще говоря, не всегда. Я, например, тоже самоучка — не было у меня курса Си++ никогда (да и любого другого тоже не было — был, правда, бейсик на БК-0010 в школе, но я к тому моменту знал бейсик по спектруму). Приходилось разбираться по книгам, по собственным находкам, по советам и ответам на вопросы. А как же иначе? И, конечно, пробелы в знаниях будут — чтобы получить ответ, надо ведь знать, что спросить. И, конечно, в моих программах нет никаких кусков, которые писал не я и которых я не понимаю, за исключением ряда очень специфических вещей (а я пишу много под QNX 6.3, и ряд вещей, действительно, лучше скопировать из примеров (у неё очень хорошая встроенная справочная система) без особого понимания тонкой сути происходящего в системе и что все эти функции означают).
Также у людей слабое представление о работе в команде и о процессах.
А вот это абсолютно верно. Я до сих пор не представляю, как команда осуществляет взаимодействие. Потому что в своём ПО я и архитектор и исполнитель. По этой же причине я так и не смог разобраться с Unit-тестами: банально не понимаю, как мне их применять в реальном приложении под ту же QNX.
самое сложное переучивать самоучек, у них уже наработана неправильная моторика.
Это тоже верно. Откуда бы эти самоучки узнали бы, как нужно делать? Я вот сейчас с применением замыканий разбираюсь и никак не могу понять, что мне они дают на практике при разработке GUI и как в том же MFC вообще можно вызывать, например, функции реакции на кнопки с передачей контекста, если MFC работает через карту сообщений.
Вот и я, всю жизнь в бюджетных компаниях, писал все подряд, а теперь годков то много, опыт тоже есть. Но так получилось, что в теории полный дятел, вот и работу искать страшно. :-)
Нет ничего неисправимого :) Пара месяцев чтения правильных книг и подготовки к интервью делают чудеса. По собственному опыту могу сказать, что здорово помогает сертификация. Сертификация систематизирует знания и дает хороший стартовый набор понятий. Сам же сертификат выделяет кандидата из толпы и как минимум гарантирует первое интервью, то есть прохождение через сито отбора по резюме. Что уже немало.
У Майкрософт очень широкий набор сертификационных программ и они доступны по деньгам даже для студента.
К сожалению начать вероятно придется со стартовых ролей. Это тоже проблема для людей полжизни проработавших «на подхвате» в ИТ отделах непрофильных кампаний — уже возраст и некий значимый практический опыт, но отсутствие теоретического фундамента и опыта работы в команде по процессам скорее всего будут означать старт с начальных ролей.
У Майкрософт очень широкий набор сертификационных программ и они доступны по деньгам даже для студента.
К сожалению начать вероятно придется со стартовых ролей. Это тоже проблема для людей полжизни проработавших «на подхвате» в ИТ отделах непрофильных кампаний — уже возраст и некий значимый практический опыт, но отсутствие теоретического фундамента и опыта работы в команде по процессам скорее всего будут означать старт с начальных ролей.
Я думаю, что пока Ваня не станет брать на себя ответственность за свои решения и пока не закончит прикрываться вымышленными персонажами, карьеру ему не построить.
Для начала стоит четко сформулировать вопрос и задать его на Тостере, а не писать псевдо-рассказ на Хабре. А пока, выводы у Вани так себе.
Для начала стоит четко сформулировать вопрос и задать его на Тостере, а не писать псевдо-рассказ на Хабре. А пока, выводы у Вани так себе.
После интервью, дали тест из 50 вопросов. Результаты данного теста пришлись ему не по душе, т.к. только на половину он дал правильные ответы, и как следствие — оффер Ване не дал
Перед собеседованием очень желательно поглядеть список стандартных вопросов для данной должности+данного языка. Это очень помогает справится с тестами, потому что зачастую вопросы в тесте с жизнью имеют не всегда много общего.
Два года пролетели
За два года не каждый и из джуна до миддла доростет.
Рано делать столь далеко идущие выводы, что в статье.
Ване не надо вешать нос.
Пусть ищет дальше.
На первой работе деньги не важны, важен опыт.
Не прислушивайся к людям от которых исходит только негатив, иди к своей цели.
Ване нужно прочитать хотя бы одну книгу по C#, например — C# для профессионалов. Тонкости программирования. Или зайти на сайт метанит, и провести там часов 100-150.
C# это в большинстве случаев — web, так что HTML,CSS,JS тоже лишними не станут.
Тут уже поможет — html5book.ru/osnovy-javascript
И видео курс Техностим Web-технологии. (про Diango там мало, пропускаем).
Пусть ищет дальше.
На первой работе деньги не важны, важен опыт.
Не прислушивайся к людям от которых исходит только негатив, иди к своей цели.
Ване нужно прочитать хотя бы одну книгу по C#, например — C# для профессионалов. Тонкости программирования. Или зайти на сайт метанит, и провести там часов 100-150.
C# это в большинстве случаев — web, так что HTML,CSS,JS тоже лишними не станут.
Тут уже поможет — html5book.ru/osnovy-javascript
И видео курс Техностим Web-технологии. (про Diango там мало, пропускаем).
Был Ваней, нужно просто как можно больше рассылать первичных резюме, своя вакансия найдется. Пришел в первую компанию с достаточно плохим уровнем в C#, все постигал в процессе работы, сложно, но если приложить усилия все получится. Сейчас достаточно сносно пишу на C# основные направления это Wpf и Asp.Net, но работа на компанию уже не интересна, потому ушел во фриланс.
Могу посоветовать для чтения
C# Notes for Professionals book
C# Smorgasbord
и конечно же
Рихтера или
Скита
В принципе этого хватит для любого собеседования. и даст достаточно знаний:)
А у меня другой вопрос, я понял что слишком зациклен на .Net стеке, я использую для мелких задач Python и Go, но все-таки хочется попробовать себя в другом стеке основательно, потому такой вопрос, как вы переходите в другой стек, и какой стек было бы интереснее выбрать как дополнительный?
Могу посоветовать для чтения
C# Notes for Professionals book
C# Smorgasbord
и конечно же
Рихтера или
Скита
В принципе этого хватит для любого собеседования. и даст достаточно знаний:)
А у меня другой вопрос, я понял что слишком зациклен на .Net стеке, я использую для мелких задач Python и Go, но все-таки хочется попробовать себя в другом стеке основательно, потому такой вопрос, как вы переходите в другой стек, и какой стек было бы интереснее выбрать как дополнительный?
Вот, собственно, Ваня и постигает (пытается постигать) язык в процессе работы) Я надеюсь, что мотив следующей статьи будет уже более позитивный. Ваши советы если и не открывают глаза — ведь Ваня и так знает, что ему просто необходимо изучить больше теории, то по крайней мере дают понять, что он не ошибся.
По-моему одного отказа на собеседовании не достаточно чтобы писать такие статьи и тем более расстраиваться. Это следует делать после 5-10 отказов подряд, ведь проходить собеседования надо уметь, это немного другой навык, чем умение программировать, как ни странно. Тем более тесты не очень показательный инструмент для проверки знаний.
Еще хотелось бы поделиться немного своим опытом первых собеседований, так как ситуация немного похожая.
После выпуска из института и 10 месяцев практики Java программистом в маленьком банке решил найти серьезную работу, и на одном из первых собеседований в SaaS компанию, один на один с тех лидом, он меня попросил написать итератор, чего я, конечно, не сделал — помнил, что есть 2 метода, а как они работают, да и зачем этот итератор нужен не смог ответить, хотя вопрос достаточно простой. Конечно расстроился и завалил все последующие вопросы. В конце собеседования мне посоветовали подучить все основы, так как "работу вряд ли я найду с моими знаниями". Следующее собеседовании я прошел на отлично и получил офер (вопросов про итератор там не было, но надо было разобраться в коде по распечатке — зачем нужен javadoc, что делает каждый метод, где какие паттерны используются, и т.д. ), а еще через несколько месяцев прошел собеседование в иностранную компанию, где потом проработал несколько лет. Так что делать выводы из одного-двух собеседование совсем не стоит.
Проблема выбора при прочих равных решается просто. Идти надо туда, где больше платят и меньше конкуренция. Для простого анализа достаточно зайти на hh.
Когда выбор сделан, то определенно стоит подучить теорию, посмотреть лучшие практики и понять особенности технологии/языка для того, чтобы не заваливаться на тестах из 50 вопросов.
Когда выбор сделан, то определенно стоит подучить теорию, посмотреть лучшие практики и понять особенности технологии/языка для того, чтобы не заваливаться на тестах из 50 вопросов.
О, похожая проблема у меня, только ещё хуже. В нашей регионе (Дальний восток, Амурская область) вообще как таковых IT-компаний нету, да и вакансиями в сфере IT можно по пальцам двух рук пересчитать. При этом требуются программисты с опытом (не менее два года) и с специфичными знаниями (у местных веб-студий, которые по сути единственные IT-работодатели (ещё 1С программисты в различные компании) в городе Благовещенск, в почёте 1С-Битрикс и больше ничего (React, VueJS, Angular даже в вакансиях не увидите, хотя и зачем это мелким веб-студиям). Плюс зарплата не сильно отличается от средних по городу, что был сделан в своё время выбор в пользу родного села (!) за ту же ЗП, у себя дома, но с очень плохим графиком работы (это когда уходишь в 8 и возвращаешься в 21, а ещё и в выходные приходится ходить) и задержкой этой ЗП. Такой график сказался на самообразовании (вечером тупо хочется упасть и уснуть, о каких книгах/статьях на Хабре/лекциях на Youtube может быть речь), моральном и физическом состояниях, самомотивации (всё тлен в этом мире; всё, что делают люди — бессмысленные вещи), личных связях (когда дом, работа, дом и так по кругу, ни о какой личной жизни и встречи с друзьями можно забыть). В ближайшее время это место работы я покину точно (урок, конечно, на всю жизнь хороший дался), но вот возвращаться ли в IT (область аграрная по сути, поэтому текущее место работы связано с сельским хозяйством)? Кроме как сменить область проживания выхода нету, либо уйти опять же в другую сферу деятельности, где здесь будут платить, что окупит аренду жилья и минимальные потребности. И получается везде придется опять начать сначала. Грустно всё это, когда начинаешь понимать, что уже и на подходе C# 8, везде внедряется PHP 7, JavaScript ES8/2017, а ты от всего этого отстал и руки сразу опускаются.
У меня не было опыта работы, не профильное образование.
Вечерами смотрел видео курсы на youtube, читал книги/статьи, проходил бесплатные курсы на intuit.ru и т.п.
Потом я приехал в новый для себя город с небольшим количеством $, которых хватало на 3-4 месяца снятия одного из самого дешевого жилья и поиска работы.
Сейчас вспоминаю это как свой личный подвиг, который сильно повлиял на мою жизнь. Теперь за 1 месяц получается больше $, чем накопленные для переезда средства пару лет назад.
C# 8 или 10, не важно. Изучи C# 5, остальное уже не так важно для старта.
И да, каждый вечер гулять и заниматься ерундой не получится, времени не хватит.
Вечерами смотрел видео курсы на youtube, читал книги/статьи, проходил бесплатные курсы на intuit.ru и т.п.
Потом я приехал в новый для себя город с небольшим количеством $, которых хватало на 3-4 месяца снятия одного из самого дешевого жилья и поиска работы.
Сейчас вспоминаю это как свой личный подвиг, который сильно повлиял на мою жизнь. Теперь за 1 месяц получается больше $, чем накопленные для переезда средства пару лет назад.
C# 8 или 10, не важно. Изучи C# 5, остальное уже не так важно для старта.
И да, каждый вечер гулять и заниматься ерундой не получится, времени не хватит.
Пришло в голову, напишу.
Изучить ЯП, скажем C# и строить простые аппы, это всегда позиция джуниор.
Аналогия — это азбука, человек выучил алфавит и научился строить небольшие предложения. Это самое простое что можно сделать, на этом этапе проблем меньше всего.
С таким багажом вас берут джуном и учат строить правильные предложения, не больше.
Через N времени, вам дают/вы получаете задания строить целые блоки, небольшие абзацы. Далее это целые главы, как в книгах. У каждой главы есть четкое вступление, основная часть и заключение. Это позиция мидл.
Еще через N времени вы учитесь строить целые книги, с набором глав, в каждой из которой много блоков, в которых много предложений, в которых много слов. И все это дело гармонично сочетается между собой и имеет смысл. Главы разбиты правильно и идут друг за другом, не выводя ИТОГО по середине книги. Вы раздаете задания мидлам, разделяя между ними главы, а джунам небольшие части в них.
И вот это самое сложное, место где развитие бесконечное и не имеет границ. Алфавит знают многие, простые предложения построить могут многие. Но составить из этого красивый рассказ уже искусство.
Изучить ЯП, скажем C# и строить простые аппы, это всегда позиция джуниор.
Аналогия — это азбука, человек выучил алфавит и научился строить небольшие предложения. Это самое простое что можно сделать, на этом этапе проблем меньше всего.
С таким багажом вас берут джуном и учат строить правильные предложения, не больше.
Через N времени, вам дают/вы получаете задания строить целые блоки, небольшие абзацы. Далее это целые главы, как в книгах. У каждой главы есть четкое вступление, основная часть и заключение. Это позиция мидл.
Еще через N времени вы учитесь строить целые книги, с набором глав, в каждой из которой много блоков, в которых много предложений, в которых много слов. И все это дело гармонично сочетается между собой и имеет смысл. Главы разбиты правильно и идут друг за другом, не выводя ИТОГО по середине книги. Вы раздаете задания мидлам, разделяя между ними главы, а джунам небольшие части в них.
И вот это самое сложное, место где развитие бесконечное и не имеет границ. Алфавит знают многие, простые предложения построить могут многие. Но составить из этого красивый рассказ уже искусство.
UFO just landed and posted this here
Уметь использовать несколько языков программирования и фреймворков, это хорошо, но, необходимо не распыляться, и для начала стать профессионалом в чем то одном, C#, PHP, Java, и т.д.На мой взгляд, это неправильный вывод.
Не раз и не два после диалога на собеседовании «А как у тебя с языком Х?» — «Слышал, но никогда не видел» — «А мы все только на нем и пишем» я получал оффер, принимал его и вполне нормально работал в новой компании. А ведь еще есть компании, где вообще вопросов по языку на собеседованиях нет — ни на junior, ни на middle, ни вообще. И, по моему опыту, вакансии в таких компаниях самые вкусные — и по деньгам, и по профессиональному росту.
Ване стоит подучить алгоритмы и структуры данных. Потому что рассказав на собеседовании про задачу о рюкзаке (подробно, с доказательствами, асимптотикой, объяснением, когда один или другой алгоритм лучше и тд), что вообще-то является прямо самой базовой базой в алгоритмах, можно получить оффер на 100+ тысяч на миддла в том же C#, ответив на 40% вопросов теста по языку (и еще непонятно, сколько из них правильно). Ну, в Москве, по крайней мере.
Опять же, если за рубеж соберетесь, вас будут спрашивать про алгоритмы и архитектуру, а не про языки.
Sign up to leave a comment.
Возможные неопределенности в карьере программиста