The document discusses strategies for improving IT recruiting by focusing on hiring top talent, conducting effective interviews that assess skills rather than just academic knowledge, and providing career growth opportunities for engineers through senior technical roles rather than forcing them into management. It also provides advice for job seekers on creating strong resumes, preparing for coding interviews, and negotiating salaries effectively.

1. Interactive session: How to make IT
recruiting suck less?
Programming interviews & careers

2. Interactive session: How to make IT
recruiting suck less?
Overview: Tech-recruiting sphere
Hiring managers: How to hire engineers?
Job seeker: How to prepare and what to expect at
interviews?

3. starfighter.io
interviewing.io

4. workshape.io

5. triplebyte.com

6. Motivation
• Hiring is especially important for companies in
Europe.
• A Google recruiter once said to me:”At Google A-
players hire A or A+ players. But at normal
companies: B player hire B- or C players.”
• Important: Invest in recruiting as much as big
corporations but don’t copy their process.

7. “Prestige is just fossilized inspiration.
If you do anything well enough, you'll make it prestigious.”
- Paul Graham (Essay "How to do what you love")

8. Show what you have
• Cool tech-stack
• Great opportunity to contribute and grow
• Reply fast to inquiries of engineers

10. Programmer types
• Academic Programmer: Candidates have spent most of their career in academia, programming as part of
their Masters/PHD research. They have very high raw intellect and can use it to solve hard programming
problems.
• Experienced Rusty Programmer: Candidates have a lot of experience, and can talk in depth about
different technology stacks and databases, explaining their positives and negatives with fine detail. When
programming during an interview, they’re a little rusty. They usually get to the right place but it takes a while.
• Trial and Error Programmer: Candidates write code quickly and cleanly. Their approach seems to involve
a lot of trial and error, however. They dive straight into programming problems and seem a little ad hoc but
their speed enables them to ultimately solve the problems productively.
• Practical Programmer: Candidates solve practical programming problems with ease, even very abstract
programs. They aren’t comfortable with computer science terminology though (e.g. data structures,
algorithms) and don’t have a deep understanding of how computers work. They are not comfortable with
level languages like C.
• Child Prodigy Programmer: Candidates is very young (e.g. 19 years old) and decided to go straight into
work, skipping college. They’ve been programming since a very young age and are very impressive in their
ability to solve hard technical problems. They’ve also been prolific with side projects and are mature for their
age. It’s likely they’ll found a company in the future when they’re older.
• Product Programmer: Candidates perform well on technical interviews and will have the respect of other
engineers. They’re not motivated by solving technical problems, however. They want to think about the
product, talk to customers and have an input into how product decisions are made.
• Technical Programmer: Candidates are the inverse of the Product Programmer. They interview well and
communicate clearly. But they aren’t motivated to think about the user experience or product decisions.
They want to sink their teeth into hard technical problems.
Source: www.triplebyte.com

12. q
Source: www.triplebyte.com

13. Where to get engineers?
• Blog (https://medium.com/@iwaninzurich/eight-reasons-
why-i-moved-to-switzerland-to-work-in-it-c7ac18af4f90)
• Meetups
• Employee referrals
• Github

16. • Crack the right combination of automation and manual work.
• Right now, we’re recruiting *manually* for companies in Zurich (Munich is
starting).
• We use Python-based tools to connect IT-companies with software
engineers: We match text of job-ads to CVs, integrate Twilio to call people
etc.

17. Coding interviews
• Phone interview (either depth or breath)
• Homework
• Look at existing code
• Code something small onsite (algorithms / data
structure / practical)

18. As a candidate, what can you do?

19. Software engineering resume
• People read resumes on autopilot.
• Don’t list every project you’ve worked on (page
length 1-2)
• Contribution >> technology/frameworks.
• Explain in simple but detailed language.

20. 1. “Designed software application including: data modeling, software
architecture design, software- hardware integration, user interface
design, and database management“
2. “Created and launched a service that collects product opinions and
recommendations from Twitter. The service finds related tweets,
removes spam, analyzes sentiment and creates a structured database
of everything that was said about particular products [link to demo].
The service is exposed as a consumer website and as widgets that
can be embedded in online retail websites.“
3. “Developed [product name], using Python and Django, for marketing
and allowing end-users to experience [another product name]“
4. “Evaluated and identified [OS name] network stack performance
bottleneck in latency, per-packet processing overhead, and scalability
of different network IO models through various system measurement
and profiling techniques“
Good or bad?
http://blog.alinelerner.com/lessons-from-a-years-worth-of-hiring-data/

21. Avoid typos
http://blog.alinelerner.com/lessons-from-a-years-worth-of-hiring-data/

22. http://blog.alinelerner.com/lessons-from-a-years-worth-of-hiring-data/

23. Coding interview
Google interviews:
• “Cracking the Coding Interview“ et al.
• interviewcake.com
• interviewing.io
Regular companies:
• Learn to communicate what you did
• Ask companies how they will assess you and prepare
accordingly.

24. How to interview your interviewers: The Joel Test
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

25. How to interview your interviewers
• If possible, ask for the opportunity to view the source code.
• If possible, ask for the opportunity to go with the guys for a beer.
Bonus (if you feel comfortable):
• "What is the most costly technical decision made early on that the
company is living with now?"
• "Where do product / feature ideas generally come from?“
Generally:
• Don’t ask engineers about benefits/salary/vacations/process – you can
get those answers later from HR or whoever.

26. Salary negotiation - how to make 5000 EUR in 2 minutes
• Don’t disclose your current salary. This can be used as a benchmark against you.
• Postpone discussion about money to the end.
• If HR insists that you name a number, tell them that you feel uncomfortable talking
about this at that point because you want to find out how you can add value first
before you know how much to ask for.
• If HR still insists, tell them that the number should not be a benchmark for later
negotiation.
• If they suggest you a number …
• …shut the fuck up.
• Always ask for more: “How I negotiated for an additional $15,000 at
Yammer” (Link)
• It’s a business relationship. For them, you are a resource…

27. Long-term engineering career paths
• True “very senior” engineering roles exist at larger
corporations
• Other firms unfortunately allow growth only by
going into management

28. • We believe, we cracked the right combination of automation and manual
work.
• Right now, we operate in Zurich and Munich.
• We use Python-based tools to connect IT-companies with software
engineers.
E-Mail: sayhi@gitrecruit.io
Twitter: @iwangulenko