Saboteur

Поиграйте в нетоповые игрушки даже в том же вконтакте, посмотрите на неучей-кор-гейм-девелоперов.

Или вы думаете в веб-разработке нет аналога игрушек ААА-класса?

Если ты не смог осилить вуз, если ты не смог осилить две книжки по питону, почему ты считаешь, что у тебя есть шансы в ИТ?

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

Чем больше ты пытаешься узнать что нужно НЕ УЧИТЬ, тем меньше у тебя шансов.

Есть определенные требования к альфа, бета и полному релизу.
Если требования к альфа выполнены, и альфа запланировано, то ее нужно выводить.

А потом, наверно, надо будет выпустить еще одну версию, устранив и перекроив часть проблем. А потом еще. Какой-то подход "лишь бы не сидеть сложа руки".

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

Потому что хорошая продумка в течение нескольких человеко-суток позволит наперед продумать и обсудить все моменты. То, что никто это не умеет, это просто человеческая тупость. Надо больше развивать такое качество, как перфекционизм - оно принципиально не позволит что-то переделывать, потому что от переделок остаются следы, а это уже не идеал. Разве это не сэкономит больше ресурсов, чем потратит?

Если ты такой умный, почему ты работаешь в этом проекте, а не являешься его владельцем или хотя бы тимлидом команды, которая будет слушать именно тебя, как все надо сделать?
Или может быть твой "перфекционизм" заключается в понимании небольшой части работы, которую выполняешь именно ты, а обо всем остальном, что еще происходит в проекте, у тебя очень мало понимания?

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

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

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

обычного кода превращают код в ассемблер

Обычный код это практически и есть ассемблер.
Процесс называется декомпиляция.
Умеет практически любой отладчик.

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

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

Ты задаешь уже шестой не очень умный вопрос, на который ЛЕГКО найти готовый ответ, если воспользоваться поиском. Но тебе видимо лень. Именно это и показатель, что у тебя вряд ли что-то получится. Слишком ленивый для обучения.

Мой главный герой - фронтенд-разработчик, а компания, в которой он работает (крупная и ведущая в стране) - занимается аутсорсингом и консалтингом в сфере IT.

По идее, герой работает в команде, где есть ещё один фронтенд, один бэкенд, двое тестировщиков, серверщик (сисадмин), иногда к ним подключаются iOS и Android разработчики и аналитик. У команды есть руководитель (или тимлид, или менеджер - как правильней?)

Крупная компания - это 1000 человек минимум. А лучше 3-5к людей.
Проект, в котором всего 2-3 разработчика это просто ни о чем. В аутсорсинге такие мелкие проекты - это нонсенс, нет смысла искать заказчика и заключать с ним договор, выделяя всего 3-5 человек. Разве что это мелкие под-проекты внутри одного большого заказчика.
И если герой - единственный главный разработчик то он и будет тимлид, потому что тимлид - ведущий разработчик, иногда совмещающий системного архитектора.

1. Правильно ли подобран состав команды для крупной компании? Может, стоит кого-то исключить/добавить?

Либо сделать ГГ тимлидом, либо добавить еще человек 10-15 минимум в проект.

2. Какого рода проекты обычно поручают команде? Сайты, ПО, приложения? Поскольку главный герой - фронтенд, и сама команда талантами не блистает, нужно что-то не слишком обременительное.

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

3. Роль руководителя (тимлида). Как он обьясняет своей команде то, что хочет заказчик? Как часто он появляется в офисе и контролирует ли процесс работы? Как общается с подчиненными - в роли злого начальника или на равных?

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

4. Дедлайны разных проектов (например, сколько по времени делается один сайт и во сколько этапов?)

Если вы кроме сайтов не знаете о софте, то не пишите о крупном аутсорсе. Напишите о маленькой но гордой "рога и копыта". Проект может длиться годы, десятки лет. Не так уж много крупных компаний, которые существуют всего несколько месяцев.

5. Может ли заказчик советовать вносить правки, если его не устраивает результат? Перед работой вообще заключаются какие-то договора и кто за это ответственен?

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

6. Процесс работы фронтенд-разработчика. С чего он начинает свою работу первым делом? В чем состоит самая сложная часть его работы и как он взаимодействует с другими членами команд? Есть ли там какие-то моменты, когда фронтенд и бэкенд должны что-либо сделать вместе? И есть ли другие случаи, когда фронтенд должен технически взаимодействовать с другими профессионалами?

Есть системный архитектор, есть UML и другие слова. Может вам действительно найти дружелюбного разработчика из крупной компании, который будет регулярно консултировать? Потому что иначе получится не рассказ о разработчике, а рассказ о выдуманном мире с выдуманными технологиями и процессами.

7. Сисадмин. Он в одном офисе со всеми работает или в другом месте где-то? Как выглядит его рабочее место? Нужен ещё процесс его работы. Если можно, опишите простыми словами.

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

8. Тестировщики. Они, вроде, тестируют почти в самом конце, когда все готово. Но, наверное, и в начале проекта они что-то делают?

Тестировщики бывают разные. Бывает даже tdd, когда сперва пишут тесты, потом приложение. Тестировать можно сразу, потом, или писать автотесты и постоянно их обновлять.

9. Разработчики для ios и android. Если требуется сделать мобильное приложение, то как эти разработчики взаимодействуют с остальными членами команды?

Также как и все.

10. Аналитик. Он точно нужен, или его роль может играть и тимлид?

Чтобы написать сайтик - не нужен. Чтобы написать бизнес-приложение нужен.

11. Состав команды, в целом, может меняться, в зависимости от проекта? Куда в таком случае отправляют «ненужных» работников? В другую команду?

12. Миттапы, совещания, летучки. Как часто проходят, кто участвует и что там обсуждают?

Зависит от того, какой agile настроен. Вдобавок они могут быть между конкретными командами или даже между конкретными людьми.

13. Рабочая атмосфера. Как общаются между собой программисты в перерыв? У них есть какие-то особые темы для обсуждений или они могут как и обычные люди, разговаривать о всяком постороннем? Есть «свои фишки» в общении?

У них есть какие-то особые темы для обсуждений или они могут как и обычные люди

они могут как и обычные люди

Нет, мы Марсиане.

14. Организация офиса. Он выглядит как самый обычный офис, только на столах - компьютеры? Есть специальные (служебные) помещения, например, для серверов?

Могут быть специальные служебные помещения. Например туалет, кухня, ресепшн. Может быть и серверная.

15. Есть какие-то особо важные нюансы, которые непременно стоит ещё упомянуть при описании работы?

Да. Не пишите книгу про ИТ, если не работали в ИТ сами. Либо найдите знакомого айтишника, который работает, и напишите книгу про его работу.

Простите, но ваши вопросы вызывают такой диссонанс, что это капец.

В текущей папке
tar cvfz file.tar ./.[^.]*

в нужной папке
tar cvfz file.tar /home/user/.[^.]*

telnet server встроен в виндовс.

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

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

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

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

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

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

Ну вот поотвечайте на вопросы в теге питон на этом сайте.

Напишите простенький морской бой с возможностью игры в локальной сети.

Хочу стать frontend-разработчиком . Достаточно ли обучение в колледже

Естественно нет

или стоит в вуз поступать?

Непонятно почему ИЛИ.
Нужно и то и другое, и учиться фронтенд разработке парралельно с колледжом и вузом.

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

Если хочешь научиться ездить на велосипеде, надо сперва учить как рулить рулем, или как крутить педалями? Или как держать равновесие? Или как тормозить?

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

Чисто гит не проблема поднять на своем корпоративном сервере или у себя дома.

Гитхаб это не только система контроля версий типа git, но и система код-ревью, с пулл реквестами, настройками доступа. Таких тоже полно - Bitucket, Gitlab, Gerrit, и их тоже можно ставить у себя на своих серверах.