Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Europython how to make it recruiting suck less?

142 views

Published on

Europython how to make it recruiting suck less?

Published in: Technology
  • Be the first to comment

Europython how to make it recruiting suck less?

  1. 1. Interactive session: How to make IT recruiting suck less? Programming interviews & careers
  2. 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. 3. starfighter.io interviewing.io
  4. 4. workshape.io
  5. 5. triplebyte.com
  6. 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. 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. 8. Show what you have • Cool tech-stack • Great opportunity to contribute and grow • Reply fast to inquiries of engineers
  9. 9. 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
  10. 10. q Source: www.triplebyte.com
  11. 11. 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
  12. 12. • 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.
  13. 13. Coding interviews • Phone interview (either depth or breath) • Homework • Look at existing code • Code something small onsite (algorithms / data structure / practical)
  14. 14. As a candidate, what can you do?
  15. 15. 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. 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 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/
  17. 17. Avoid typos http://blog.alinelerner.com/lessons-from-a-years-worth-of-hiring-data/
  18. 18. http://blog.alinelerner.com/lessons-from-a-years-worth-of-hiring-data/
  19. 19. 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.
  20. 20. 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?
  21. 21. 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.
  22. 22. 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…
  23. 23. Long-term engineering career paths • True “very senior” engineering roles exist at larger corporations • Other firms unfortunately allow growth only by going into management
  24. 24. • 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

×