2. whoami
• Software engineer by trade (Munich kid, studied
at TUM)
• Interested in making tech-recruiting suck less
• Use traditional sources
• Github - tool to automate candidate search via
Github.
4. Overview: Tech-recruiting sphere
Hiring managers: How to hire frontend engineers?
Job seeker: How to prepare and what to expect at
interviews?
How to hire fronted engineers?
6. Show what you have
• Cool tech-stack
• Great opportunity to contribute and grow
• Reply fast to inquiries of engineers
7. 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
13. 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.
16. 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
dashboard 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 React and Redux, for marketing
and allowing end-users to experience [another product name]“
4. “Evaluated and identified rendering issues in high performance
vector and matrix math in WebGL and glMatrix through various
system measurement and profiling techniques“
Good or bad?
http://blog.alinelerner.com/lessons-from-a-years-worth-of-hiring-data/
17. 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?
18. 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.
19. 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…
20. Coding interview
Google interviews:
• “Cracking the Coding Interview“ et al.
• interviewcake.com
• interviewing.io
With regular companies:
• Learn to communicate what you did
• Ask companies how they will assess you and prepare
accordingly.
21. 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
22. 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
jQuery
React /
Angular
React /
Angular
24. • Crack the right combination of automation and manual work.
• Right now, we’re recruiting *manually* for companies in Zurich (Munich is
starting).
• We use web-based tools to connect tech companies with software
engineers: We match text of job-ads to CVs, integrate Twilio to call people
etc.
Building a recruiting bot
25. • Recruiting fees are second highest expenditures after salaries. Why is it
still like that? With so much AI and ML, can’t we just replace human
recruiters?
• Human recruiters:
- Do not understand needs
- Struggle to find right fit
- CV overload, mostly irrelevant (internal incentives)
- Expensive
Building a recruiting bot
