Разказвал ли съм ви как бях лектор на ISTACon 2019?
Говорейки за мерака да се “похваля” и с първата ми паник атака на сцена. Не всичко е цветя и рози, хихи и хохо все пак.
2018 г. ходих като посетител на ISTACon и съответно network-нах very hard, тоест успях да говоря със 150 човека, да разкажа около 800 вица и да си говорим за тестване, деплойване, все мръсни неща.
Та към края вече socially exhausted отивам да си взема веченезнамкоекафезаденя и се срещам с Христо Гергов, с който си поговорихме и той накрая ми каза – “А ти защо не се пуснеш да участваш на ISTA 2019?” и си тръгна. Аз бях – naaaaah, това е мега конференцията как там ще загрозявам само картинката с моята красива физиономия”.
But the damage has been done. Христо явно добре познава човека като такъв и явно разбра как да ме агитира с едно изречение. Просто аз го осъзнах половин година по-късно. Та пуснах си кандидатурата за лекция и те взеха, че я одобриха. Същата година говорих на QAChallengeAccepted за Security testing и се пред DEV.BG за подобна тема та реших защо да не това да ми е темата на годината. Пуснах се с гръмкото “Security testing from wizard to lizard in 40 minutes”. Всичко добре, обаче аз си ходя на работа, конференции, карам колело, всякакви неща и се оказва, че може и да съм подготвен за лекцията, но психически май бях далеч.
И го казвам с ясното съзнание, че не ми прави услуга това, но както казах по-горе – не всичко е цветя и рози, фън енд геймс.
Дойде ред на ISTA (аз бях в края на втория ден) и започват да идват някакви ми ти CEO-та/CTO-та, някакви грамадни имена, Янчо от Мусала в това число, говорят за някакви извънземни неща, кой копал с години в някаква ниша, кой направил ебахти и постижението и … аз. Който ще говори за сигурност. Още си спомням колко смачкан се чувствах.
Вечерта дойде и направихме едно събиране на лекторите и няма да ви излъжа – беше страхотно (плюс, че е възможно да съм попрекалил и ходих да си търся метрото до Красна Поляна, но това друга тема).
За малко да забравя – на първия ден ни казаха, че лекциите задължително ще бъдат на английски. Това ме хвана неподготвен. Буфера от репетираната лекция заминава за това как да мисля думи и съчетания, да спазвам времена и да звуча адекватно. Фак.
Та идва ден две и ей го Недко. Сцената е страхотно оборудвана, светлините са 6 точки, фонове, а, у. Закачам лаптопа и Убунту ми каза – “Фак оф, аз full screen няма да ти пусна”. Микро инфаркт. Реших да не си го слагам толкова.
Всичко сетъпнато, излизам и … получих първата си паник атака на сцена. Богу това беше най-гадното нещо, което ми се е случвало до тогава.
Ако помните преди няколко години как Майкъл Бей (филмов директор, известен с филми като Bad Boys, Armageddon, Pearl Harbor, Transformers series и т.н.) получи паник атака на сцената на CES 2014? Е, явно никой не е застрахован.
В крайна сметка преодолях донякъде паник атаката си, но тия 20-тина минути ми се сториха буквално като час. Исках просто да си тръгна и повече никога да не изляза сред хора.
От 2019 г. до сега се изредиха много конференции, като съм говорил на много, включително и последното ми включване на QAChallengeAccepted като бяхме около 700 човека в залата (плюс няколкостотин гледайки стрийма) и не ми се случи пак.
Защо го пиша целия този ферман ще се зачудите? Защото всички сме хора, всички имаме потресаващо еднакви слабости, всеки иска да е перфектен (или близо до перфектното). Но се случват неща, които ни отдалечават от това да сме наистина добри в нещо (например аз в говоренето пред хора), но желанието и нуждата от себеразвитие ни бута напред. Ако бях решил да престана да говоря пред хора никога нямаше да говоря пред препълнената зала на dev.bg или пред онези 700 човека. И пред много други.
Та това, което можете да си вземете от моят опит е просто да си гоните вътрешното дете в себе си и по детски да се мятате в неща, които може да са мааааалко по-трудни от ежедневните ви неща (или много по-трудни). Ако успеете обаче ви обещавам, че чувството е ве-ли-ко-леп-но.
Ако усещате, че вече нямате нужда от себеразвитие и не ви се заниамва си дайте малко почивка – работата ни е натоварваща, трудна и ни взима много. За това и трябва да имаме време да дишаме и да си вземем нуждата от това да си кажем – “Абе … колко пък да е трудно”.
Еми таковата … по едно време бях си казал, че спирам с публичните изяви (освен клипчета в ютуб как свирим пияни заляни по фото студията), но желанието ми да споделям опит (и не – не е клише, което използвам по конференции/интервюта за работа, а наистина ме е грижа) явно е по-силно.
Ще е забавен септември предвид, че началото на Октомври чакаме бебенце номер две, а то може и да подрани по негово си желание, ще имам лекция, аз вече ще съм нагазил в много дълбокото в AWS, има шанс и да пътуваме… Burnout – добре дошъл :D
Тези дни ще запиша един епизод с повече детайли относно лекцията, но teaser-а е, че ще говоря повече за идеи отколкото за инструментариум, ще говорим и за кариера и какво следва след QA и общо взето смятам, че ще е полезна на доста хора.
И последно, че пак ще стане дълъг пост – когато си писах CV-то преди някакво време минах през секцията с лекции, които съм водил и учудващо за мен, но ми изплуваха някакви спомени за всички от 2016 насам и повечето – забавни. То нямаше една, която да кажа, че ми е било скучно :D Та ми се иска да направя един епизод за това, защото хората, които (искат да ) говорят предполагам ще им е полезно.
Миналата неделя бях поканен да споделя част от опита си със завършващите курса на https://kiber-one.bg с възрастова група от 6 до 14 и да раздам дипломите на най-малките. Реших да говоря за това как съм започнал аз, как любопитството ме е тласнало напред, как сме играли игри на черно-зелени екрани от дискети, как сме си писали сами игрите на BASIC и сме чели документация от хартиен носител, какво правя сега, сегментирането на сектора (често споменавам като говоря пред ученици това, че IT не е само програмиране, да им покажа част от спектъра включвайки дизайн, QA, програмиране, PM и т.н. и т.н.) съответно с опит това да звучи колкото се може по-близко до наруталния език.
Отивам в юнашкия дом във Варна и ме посрещат 50-тина деца, които си стоят по столовете и чакат, родителите бяха на втория етаж и все пак нямаше нито едно дърпане на коси, сбиване или лигавня. Повечето деца бяха в границата между 6 и 9 годишна възраст.
Започна събитието и имаше демо на 5 проекта на деца от 7 г. до 9 г. С огромен интерес наблюдавах какво правят децата и след второто демо си зачеркнах половината ключови думи по които щях да говоря. Нямаше да им кажа нищо ново. Демата бяха на Scratch и Tynker и след като едно момиченце на 7 години показа демо пред 100+ човека на имплементация на Flappy Bird в която си имаше своите условия, sprites, различни екрани и т.н. аз бях – “Чакай, чакай”, дойде друго дете, показа 3D модел на Tynker на слънчевата система с акуратни размери на планетите, орбитите и скоростта на движението им, показа кода, обясни го. Бях супер приятно изненадан.
Това, което видях са деца, които:
Правят неща, които им харесват
Могат да работят в екип
Имат логическо мислене
Разбират основите на програмирането
Имат презентационни умения и не изпадат в паника като говорят пред хора (за разлика от мен)
Разбират англисйки на ниво, което им върши работа
Ето, че има надежда, просто трябва да знаем накъде да гледаме.
Edit – Забравих да добавя, че след края на цялото нещо излизам от залата и едно момченце (7-8 да речем) се отдели от родителите си, дойде при мен и каза – “Господине, много хубава реч, хареса ми.” Прибрах се нахилен като пача. Явно е имало смисъл.
Мина, мина, мина! Чаках този момент от няколко месеца вече и като мина се образува стандартния вакуум който си се появява след като сляза от сцената.
Този път публиката беше разделена на три основни части – в залата, отвън и online. Общо организаотирте казаха, че са били долу-горе колкото миналата година – малко над 700 човека (без тези, които после са гледали видеата).
Подготовката ми започна началото на годината и когато COVID-19 отложи конференцията за Септември бях се поотпуснал, но като стана Септември пак беше драма. Но този път контролирана драма. Този път научих токова много по темата, че смятам да направя първите 2-3 епизода на подкаста по темата с говорене пред публика. Смятам да говоря освен за нормалните неща като подготовка, soft & hard skills и за неща за които рядко се говори – какво е да стъпиш наистина на сцената, какво може да се счупи там (например аз чувах гласа си с около половин секунда закъснение и това ме счупи много).
Този път Златина беше с мен, беше първата ми big-scale conference с нея и това помогна доста. Дори после преживях доста по-лесно цялата комуникация с хората и видях красивото в неща, които не бях забелязвал.
Да, освен това имам разни новини за споделяне, които бавих, защото не измислих как да ги представя по интересен начин тук, защото този телеграфния не ми харесва изобщо.
Те така де, друго интересно е какъв импакт може да има и LinkedIn. Споделих преди няколко дни пост за конференцията и събра общо над 4600 views, 70-тина лайка и огромен брой читатели, които не са HR (което всъщност ме учуди най-много).
Те така де, очаквайте скоро по-подреден и panic-free епизод с основните точки от talk-а ми. Даже се замислям дали няма да е удачно да го изнеса (без техническите детайли) на TedX. Вие какво мислите?
O shit, o shit, o shit. Вайкам се из апартамента докато Златина и котката Иво ме гледат като човек, който е изгубил разсъдака си (което не е далеч от истината по принцип).
Та да – бях одобрен да говоря на една от най-голямите конференции в България и на темата сигурност (но с повече мемета, обещавам!) – “Security testing – from lizard to wizard in 40 minutes”.
Освен нещата, които вече казах на QA: Challenge Accepted мисля да добавя малко по-advanced техники или да направя изцяло нова лекция. Вие какво мислите по въпроса? Какво ви е интересно?
Сега repo-то на DVWA заедно с апаче, база данни, PHP и една кофа неща са при вас. За да ги направите достъпни, трябва просто да стартирате контейнера:
docker run --rm -it -p 80:80 vulnerables/web-dvwa
1. SQL Injection
SQL Injection най-общо казано е възможност за изпълняване на нерегламентирани SQL statements като SELECT, UNION и т.н., които не са предвидени в текущата функционалност на приложението. С други думи ако параметризирате без подходяща валидация и/или санитизация някой параметър, може да има драма. Пример за драма: GET request:
http://nedko.info/sql_injection/inj.php?drama=1
Кода, който работи отдолу:
$drama = $_GET[‘drama’]; $getDrama = “SELECT * FROM vulnerabilities WHERE type = ‘$id’;”;
Ако въведете валидни данни всичко ще е супер, ноо (второто О е за допълнителна драма) ако счупите заявката ще стане любопитно.
Най-елементарния и емблематичен пример е Светия Апостроф. Ако набием един ‘ след параметъра ?drama=1’ ще строшим SQL заявката.
Пример в DVWA с класически SQL injection (линк към локалния DVWA – http://localhost/vulnerabilities/sqli/):
DVWA – SQL Injection, level 1
Но понеже живота на penetration tester-а (или на смъртния човек, който е решил да се занимава с това) не винаги е лесен (никога не е) и може вече някой програмист далновидно да е решил да направи валидация и да избегне този балъшки тест.
Тогава идва ред за нашето последно късче надежда или т.нар. Blind SQL Injection (или както след лекцията някой каза – Орхан Мурад SQL injection), който можете да намерите в менюто на DVWA – SQL Injection (Blind). По самото си същество това е същата уязвимост, но не получаваме веднага потвърждение от типа на бял екран или експлозия на еднорози. Но лесно можем да проверим какво става като отворим inspector-а на Chrome (естествено става и с всички други модерни браузъри, дори и с Онова, което никой не нарича браузър) и влезем в таб Network. Там ще минат всички request-и (POST/GET ни интересуват най-много, но ще видите и images, JS, CSS files и всичко от което има нужда ресурса, който сте отворили).
Сега като набиете един ‘ в полето “User ID” наблюдавайте какво ще се случи в Network Tab-а:
За да продължим към екшъна ще ни трябват и кукитата на скрипта, защото все пак, за да достигнем тази функционалност минахме през логин. Cookies можете мега лесно да намерите на същия екран, но в подтаб (има ли такава дума?) “Cookies”:
До момента използвахме само браузъра за нашите дребни шегички с администраторите. Сега е ред да използваме нещо по-могъщо – sqlmap.
Note – чудите се къде са SQL break characters, къде ви е cheatsheet-а с който можете с copy/paste да трошите сайтове? Понеже на лекцията имах само 25 минути нямаше време за това, няма да го покажа и тук (освен ако някой наистина иска да види какво става отдолу, тогава на драго сърце бих дописал статията с малко теория). За наше щастие sqlmap прави всичко за нас. Ние само трябва да му дадем параметъра, който смятаме за уязвим и cookie-тата, за да може инструмента да се “логне”. Туй то, както казваме в Добричко/Варненския край.
sqlmap – our secret weapon
За да подкарате sqlmap, трябва да имате първо Python. Инсталацията му е лесна и няма да имате грижи.
По ред на information gathering процеса ще запиша тук всичките стъпки, през които трябва да минем:
available databases [2]: [*] dvwa [*] information_schema
И ето, че намерихме базата, която използва DVWA. Сега ще ровим още, за да получим имената на таблиците на същата база (ако новите и старите богове нямат нищо против):
-D dvwa – казваме, че целта на нашата задача е база с име dvwa
–tables – покажи всички таблици от базата дефинирана по-горе.
Database: dvwa [2 tables] guestbook users
И ето, че без много зор стигнахме до таблиците на база, за която нямаме никакви credentials. И понеже чичо Недко е нагляр по природа продължаваме да видим докъде можем да стигнем:
Както забелязвате няма нужда да въвеждаме името на базата и таблицата тук, защото sqlmap си ги пази. Това значи, че ако решите да си reproduce-нете целия сценарии отново, трябва да минете през горните точки също.
И ето, че с последната команда направихме все едно един select user, password from users, взехме хешовете и направихме dictionary attack в който съпоставихме хешовете с тези в dictionary файла. Естествено за демото паролите не бяха t@snipi4ki!, а тривиални, за да може да не използваме +10GB файлове и часове чакане, а покажем как работи sqlmap-а.
Малко тъпо заглавие, но друго не измислих. Идеята е, че ще направим малък трик, с който ще успеем да качим PHP файл, който ще представим за PNG и в последстиве ще преименуваме директно на сървъра с command injection, за да изпълним зловредния си код (зъл смях).
Преди време имах трудни периоди с един програмист, който пишеше upload форми като казахтстански опълченец – без никакви валидации освен разширението на файла. След десетки спорове стигнахме до консенсуса да ползваме getimagesize в PHP. Хитринката е, че освен размера на image-а функцията проверява и дали файла е от тип image или някой хитряга се опитва да върти номера. Тогава при моите си опити да кача нещо друго освен image, не увенчах успех. Но днес ще ви покажа как да прескочим и това.
Преди това обаче свръх малко теория – подобни функции изчитат сигнатурата на файла, която е в началото му и ако срещнат съвпадащи такива с типа, за който се представя файла, го приемат за чиста монета. До момента, в който някой не реши да смени тази сигнатура (laugh in Spanish).
За да редактираме сигнатурата на файл, ни трябва HEX редактор и PHP кода от по-горе запазен във файл с разширение PNG (в моя случай е hack.png). На по-старите кучета, които са живели във времето, в което това беше актуално, няма да обяснявам какво е, а за по-новите кучета – също. Просто си изтеглете WinHEX или който и да е друг подобен инструмент, отворете hack.png и от страницата File Signatures Table намерете PNG и го копирайте в началото на файла:
При paste изберете в диалоговия прозорец “ASCII Hex”.
И ето, че имаме handcrafted файл, който можем да си използваме да си тестваме upload формите.
Нека сега опитаме да качим файла през upload формата на DVWA:
И ето, че имаме качен успешно файла в две директории нагоре /hackable/uploads. Ако сега го достъпим, браузъра ще се опита да отвори файла като image, но ще покаже някаква простотия. Пътя до файла е http://localhost/hackable/uploads/hack.png
Понеже сега не можем да изпълним PHP-то, идва ред на третата и последна атака, която ще направим днес:
Command Injection
Целта на тази атака е да намерим функционалност, която извиква директно команда от системата и да слепим с нея втора, която ние да си изберем. В конкретния случай ще преименуваме hack.png в hack.php.
Като цяло извикването на команда директно си е за бой, но ако извикате команда през PHP без да имате нужните валидации, сте за хвърляне зад Вала. Както повечето атаки и тази разчита на липса на валидации за специфични кейсове. Атаката се осъществява мега лесно със знак за конкатенация. Пример за такива знаци има в кода на DVWA (ниво на трудност High):
Нашата нищожна атака ще е супер проста. Както виждате от примера по-горе на трети ред след| има интервал (демонстриращ, че човешката грешка също е важен показател). Тоест с | ще можем да слепим втора команда след валидно подадена такава (като не забравяме, че не трябва да има интервал след знака, за да не мине валицадията). Ето и пример с това как можем да видим системен файл директно от WEB чрез command injection:
localhost|cat /etc/passwd
И както виждате можем да видим съдържанието на системен файл без проблем, за това ще опитаме да преименуваме файла hack.png в hack.php и да го изпълним. Командата е: localhost|mv ../../hackable/uploads/hack.png ../../hackable/uploads/hack.php
Не очаквайте винаги да има някакъв output от командите, които (се опитвате да) изпълнявате.
Изпълнението на зловещия план
След като създадохме файл, който специално обработихме, качихме и преименувахме, е време да го изпълним и да видим дали всичката тази играчка ще сработи. Ще се опитаме да видим съдържанието на конфигурационния файл на DVWA:
И ето, че с тези елементарни похвати успяхме да извлечем потребителските имена и пароли от базата на DVWA, да му прескочим upload формата и да изпълним произволна команда.
Линк с презентацията можете да намерите мааалко по-долу. Публикувам я as it is макар, че малко се счупи при импорта от PowerPoint към Google Slides. #Yolo (или както Исуската казва – #YOLT (you only live twice).
Заключение
На всички ни е ясно, че новите ORM frameworks например се грижат за SQL injection още на много ниско ниво, че command injections могат да се разрешат лесно с използването на почти произволен framework и правилна конфигурация, но всеки трябва да се замисли поне малко за сигурността, докато пише проложения, за да може тези, които го тестват да кимнат одобрително с глава и като го пуснат в production, да са поне една идея по-спокойни.
P.S. Ако ви е интересно мога да разпиша повече по темата с DVWA като XSS, CSRF, чупене на хешове с John the Ripper, сигурност в WordPress (скенери, атаки, как да се предпазим, а, у) и т.н.
P.S.S. Преди време говорих на WordPress meetup-а във Варна за сигурност, ако ви е интересно – има повечко системни неща, има и dictionary attack-а и подобни:
Този формат е най-трудното нещо, което правя последните 2 години – приемам го доста насериозно и предния път ми отне немалко време и енергия да се подготвя.
Тази година темата ми ще е “Security Testing – Fast Forward” и ще продължи само 25 минути. Кандидатствах с две лекции – едната беше по-интересна и дълга (40 минути) и носеше по-епичното заглавие – “From lizard to wizard”.
И така – ще се срещнем с вас на 13 Април в София Тех Парк.
P.S. Ако на някой му е интересно нещо по темата нека пише тук и ако мога бих го включил в лекцията.
P.S. По време на лекцията ще има и малка изненада тук в блога.
Добро утро. Винаги е приятно да влезеш в зала с десетки хора, които говорят за Agile, код и тестване.
Всичко започна с лекцията на Mathias Verraes – “Design Heuristics”
Това, бога ми, беше първия keynote speech без презентация, който гледам. Чувството е като онези push-up bras. Всичко беше ок, но нещо липсваше.
Аз лично се изгубих напълно още в началото.
Hindsight lessons about API testing Viktor Slavchev
Да слушаш тестинг трола винаги е удоволствие. Дали е заради лекотата с която засажда идеи в главите ни или за интересните теми или заради братата, не знам, но при мен се получава.
И да не звуча тенденциозно мога да го хейтна (без хейт не може!1!!) – тази брада трябва да расте, по вързможност до колената! Край на хейта.
Сега, сериозно.
Лекцията му започна с препрепълнена зала и хора седящи по земята.
Първо да уточним думата hindsight. Това е “умението” да разбираме някакво събитие или ситуация само след като то се е случило. И един много подходящ пример “With hindsight, we would recommend exactly the opposite.”
Виктор каза нещо познато, което трябва да се казва много по-често и да се използва – “Tools don’t make software (tools are not a solution). You’re the one who solve the problem”.
Преди да влезем в контекста на API тестинга трябва да обясним какво е web service и Виктор го обясни по интересен начин:
Web service-а е като комуникацията със сервитьор*:
Правите поръчка (request);
Получавате отговор (от типа да/не) (status code);
Получавате това, което сте поръчали (data, result)
Извън контекста на презентацията на Виктор – примера със сервитьора може да се използва и при security testing-а като му поръчаш да ти сервира ‘, *, NULL, 0 OR 1=1, шкембе с крутони и т.н. И после следим резултатите.
Относно точката за status code-а – понеже статус кодовете наистина са много и е хубаво да знаем поне основните най-лесния начин за това е да видите http status cat. От там аз научих повечето :D
Няколко неща преди да започнем с API тестовете:
Документацията не е винаги е пълно описание на продукта. Особено автоматично генерираната, outdated или зле написаната документация. За това трябва да мислим, да идентифицираме да намерим нашия testing oracle (дефиницията си я намерете в блога на Виктор), да задаваме въпроси;
Настройката ви при писане на тестове – не пишете тестове, които минават, светят в зелено и еднорози скачат по репорта, а тестове, които тестват функционалност (понеже тук може да се говори много можете да пишете коментар в този блогпост или в поста на Виктор в неговия блог);
При API тестинга често забравяме да тестваме истински сценарии, а не само кой call какви отговори връща;
Кои тестове си струва да автоматизираме
Всички тестове, които връщат грешен response code (status code checks);
Всички тестове, които връщат грешни данни (structure checks);
Всички тестове, които не връщат никакви данни;
В добавка – освен единични, изолирани тестове е нужно да правим тестове по цели сценарии, знаете, но да кажа.
Status code checks – плюсове и минуси:
Плюсове:
Пишат се бързо и лесно;
Много дефинитивни;
Работят като sanity/smoke тестове.
Минуси:
Много повърхностни;
Трудно получаваме някаква полезна информация ако използваме GET методи (получаваме само status code без никакъв контент);
Status code checks сами по себе си не дефинират сериозни проблеми;
Structure checks – плюсове и минуси:
Плюсове:
С тях лесно може да проверим данните, които получаваме (no shit, Sherlock);
Тестовете могат да са много конкретнил
Ако използвате Codecept, например, можете да използвате regex.
Минуси:
Тези тестове са използваеми само за тестване на съдържание;
Трудни са при тестове на променливи данни;
Не са лесни когато имате deep nesting/дълги респонси.
Scenario checks – плюсове и минуси:
Плюсове:
Много близки до потребителското изживяване;
Използваеми при намирането на integration problems;
Могат да бъдат изпозлвани като леки regression suits;
Когато пишете scenario checks приемайте API-то като приложение (не ме целете с домати, но помислете за това). Много по-лесно е да измислите някакъв flow и да работите по него..
Минуси:
Бавни за писане/изпънение;
Изискват добра абстракция;
Трудно е да се каже кога са достатъчни
Както е писано неведнъж – при писане на тестовете използвайте ААА метода – arrange, act, assert. Това е достатъчно. Ако обаче се оплетете в морето от arrange/act-ове драмата ще е по-голяма от тия в индийските сериали.
Сега като си препрочетох описанието с тази кирилско/английска плетка не ми звучи толкова добре колко я чух, може би трябваше да я опиша на английски. В блога на Виктор има голяма част от това, което каза на лекцията така, че смятам ще ви е интересно.
Sales Skillz for IT People Iancho Dimitrov, VP Innovation, Strategic Clients & Business Development, Musala Soft
Доста извън моя интерес реших да участвам в лекцията на Янчо Димитров, който беше представен като легенда. Сигурно е.
Разакза ни малко за продажбите като имаше две интересни попадения:
“Sales are not bad thing if done right”;
“People don’t want a quarter-inch drill, they want a quarter-inch hole” Ted Levitt.
Why Teams and Culture Matter: Leadership lessons – Vasil Popovski
Преди години слушах за пръв път Васил Поповски на едно от първите издания на ISTA. Тогава той работеше за VMWare и тогава и сега разказваше супер интересните неща. И понеже този път няма да мина през превеждането на термини и презентация ще е на английски.
Google have quite interesting project called project Google Aristotle. With that in mind Vasil gives us couple of vision about what’s the most important thing in team:
5) Impact – team members think their work matters and creates change;
4) Meaningful work – is personally important to team members;
3) Structure and clarity – team members have clear roles, plans and goals;
2) Dependability – team members get things done on time and meet Google’s high bar for excellence;
1) Psychological safety – team members feel safe to take risks and be vulnerable in front of each other.
How to build a great team:
Team is not family – family is structure that is inherited, you cannot make changes there;
Lead the team, do not manage it – lead people, manage projects. Manager says “Go”, leader say’s “Let’s go”;
Foster a culture – culture is the shared core values, practices and beliefs of the team members.
Integrity is what you do when no one is watching
Hiring:
Hire for cultural fit;
Prefer skills over knowledge (skill is to know how to apply knowledge);
How many interviews you do as company – Google make a survey (how much interviews to hire someone) – fourth interviews was enough to predict a new hire’s performance with 86% confidence. After the fourth interview the accuracy of the mean score increases by less than one percent. More info can be found here
In Leanplum for example one backend developer goes trough next interviews:
Algorithmic
Coding/OOP
Design
Cultural fit
For Leadership skills
Performance management:
A single negative employee or bad performer can cause a 30%-40% drop in a team’s performance.
Automated page speed optimizations for fast site performance
