The document provides guidance on hiring developers based on Joel Spolsky's book "The Ultimate Developer Recruiting Guide". It summarizes the key steps in Spolsky's hiring process: conducting interviews that last at least an hour and involve both technical exercises and allowing candidates to interview the hiring manager; focusing on finding candidates that are both smart and able to get things done; and emphasizing the importance of treating candidates and employees well to attract and retain top talent.
When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.
Can software architecture affect the culture and emotions in the workplace? In this talk I look to some ways architectural choices shape collaboration and survivability in the workplace.
EventStorming was born as a massively in-person workshop to discover and model complex businesses and design event-driven software. But the old ways are no longer viable. After one year of experiments and discoveries in a forced-remote setting we know a lot more about what is still working and what is not.
We’re all doing Agile nowadays, aren’t we? We’ll all delivering software in an Agile way. But what does that mean? Does it mean sprints and stand-ups? Kanban even? But what about Extreme Programming? If as a development team we’re not using pair programming, test driven development, continuous integration, and other XP practices, then we’re not really doing Agile software development and we may be on a march to frustration, or even failure.
I’m going to look at why the current trend of companies and projects adopting Scrum, calling themselves Agile, but not transitioning their development to XP, is a recipe for disaster. I’d like to cover the main practices of XP as well as other good practices that can really help a team deliver quality software, whether they’re doing two-week sprints, Kanban, or even Waterfall.
https://www.youtube.com/watch?v=aZgnY9fAHOA
Play to Learn: Agile Games with Cards and DiceMike Clement
Play is a powerful method to learn! Come and play some simple agile games that use playing cards, index cards and dice to explore the different values that are at the foundation of Agile and Lean development practices. In addition to your own insights, you may be able to take these game back to work to share with your co-workers.
This is a hands-on session so come prepared to have some fun!
There is no "right" answer to what you're "supposed to" learn from a game, so come ready to discover your own insights into software development processes and teamwork.
When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.
Can software architecture affect the culture and emotions in the workplace? In this talk I look to some ways architectural choices shape collaboration and survivability in the workplace.
EventStorming was born as a massively in-person workshop to discover and model complex businesses and design event-driven software. But the old ways are no longer viable. After one year of experiments and discoveries in a forced-remote setting we know a lot more about what is still working and what is not.
We’re all doing Agile nowadays, aren’t we? We’ll all delivering software in an Agile way. But what does that mean? Does it mean sprints and stand-ups? Kanban even? But what about Extreme Programming? If as a development team we’re not using pair programming, test driven development, continuous integration, and other XP practices, then we’re not really doing Agile software development and we may be on a march to frustration, or even failure.
I’m going to look at why the current trend of companies and projects adopting Scrum, calling themselves Agile, but not transitioning their development to XP, is a recipe for disaster. I’d like to cover the main practices of XP as well as other good practices that can really help a team deliver quality software, whether they’re doing two-week sprints, Kanban, or even Waterfall.
https://www.youtube.com/watch?v=aZgnY9fAHOA
Play to Learn: Agile Games with Cards and DiceMike Clement
Play is a powerful method to learn! Come and play some simple agile games that use playing cards, index cards and dice to explore the different values that are at the foundation of Agile and Lean development practices. In addition to your own insights, you may be able to take these game back to work to share with your co-workers.
This is a hands-on session so come prepared to have some fun!
There is no "right" answer to what you're "supposed to" learn from a game, so come ready to discover your own insights into software development processes and teamwork.
Software Developer Career Unplugged - GeeCon 2013Wojciech Seliga
This is my quite subjective take on various less technical aspects of a software developer career. I delivered this presentation and GeeCon 2013 (video hopefully coming soon) and quite compressed/abridged version at InfoSHARE.
Short history of Spartez and information whom we want to hire and why.
Extra bonus: my aspirational thinking about how juniors differ to senior and principal developers.
This slidedeck was presented by me during Spartez Open Day on March 13th 2015.
There are some recurring themes in Domain-Driven Design applications, and distant domains show more similarities that differences, especially when you start taking into account peculiarities of specific Bounded Contexts. This is where a different type of design could happen.
What happens when you have the luxury of leading software projects without trade-offs and you're a Domain-Driven Design fanatic? You start stretching DDD concepts until it hurts and make experiments un uncharted territory.
In this talk, we'll see a few unconventional approached to Context Mapping and what happens when you fully embrace CQRS and Small Aggregates as a modeling paradigm.
Ten lessons I painfully learnt while moving from software developer to entrep...Wojciech Seliga
My presentation from Devoxx Poland 2016 conference - the newest, slightly revised version.
For many years I was a software developer. I would concentrate on the code, software projects and the interactions with my closes team and the users. I was sure that Agile solves all world’s problems. I would laugh over Scott Adam’s Dilbert comics with his Point Hair Boss. Life was simple, life was good. Now for 8+ years I have been running a software company, not a small one anymore. I became myself a full-time boss who only codes sometimes at home or during hackathons.
This session is about sharing with you those critical lessons which I painfully learnt when trying to grow into this new role - transitioning from being a software engineer into being an entrepreneur and top manager. Wheres not all of the lessons may or will (if you dream about your own startup) apply to your case, being aware of them may save you tons of time, energy, money or even help you to avoid the total disaster - burying your own company or dreams. And after all, sharing war stories from the past is fun … when these stories are the past.
Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme.
In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.
This presentation is an introduction to the field of technical writing based on my personal journey and philosophy of documentation, and was presented to the first meeting of Write The Docs Nigeria on February 20, 2021.
Confitura 2013 Software Developer Career UnpluggedWojciech Seliga
My take of our challenging life of a software developer, typical misconceptions, myths and also great things, those which are important. I shared it (in Polish) in Warsaw at Confitura 2013.
Ten lessons I painfully learnt while moving from software developer to entrep...Wojciech Seliga
My presentation from InfoShare 2016 conference.
For many years I was a software developer. I would concentrate on the code, software projects and the interactions with my closes team and the users. I was sure that Agile solves all world’s problems. I would laugh over Scott Adam’s Dilbert comics with his Point Hair Boss. Life was simple, life was good. Now for 8+ years I have been running a software company, not a small one anymore. I became myself a full-time boss who only codes sometimes at home or during hackathons.
This session is about sharing with you those critical lessons which I painfully learnt when trying to grow into this new role - transitioning from being a software engineer into being an entrepreneur and top manager. Wheres not all of the lessons may or will (if you dream about your own startup) apply to your case, being aware of them may save you tons of time, energy, money or even help you to avoid the total disaster - burying your own company or dreams. And after all, sharing war stories from the past is fun … when these stories are the past.
10 bezcennych lekcji dla software developera stającego się szefem firmyWojciech Seliga
[Originally Polish lecture with English slides - with a few exceptions]
Przez wiele lat byłem software developerem. Koncentrowałem się na kodzie, projektach software'owych oraz interakcjach w moim zespole i z klientami. Byłem pewny, że Agile rozwiązuje wszystkie problemy tego świata. Śmiałem się z komiksów Scotta Adamsa i stworzonej przez niego karykatury szefa (PHB). Życie było proste i piękne...
Teraz od ponad 8 lat prowadzę firmę software'ową, którą przy blisko 90 osobach trudno już nazwać maleństwem. Sam stałem się "szefem" na pełen etat.
Podczas prezentacji podzielę się z Wami różnymi doświadczeniami oraz naukami (nieraz bolesnymi) jakie wyniosłem w ostatnich latach podczas mojej stopniowej przemiany z developera/inżyniera w przedsiębiorcę i szefa firmy. O ile zapewne nie wszystkie sytuacje i wnioski mają lub mogą mieć (o ile marzysz o własnym startupie czy zespole) zastosowanie w Twoim życiu, same sobie ich uświadomienie może oszczędzić Ci w przyszłości straty mnóstwa czasu, energii i pieniędzy oraz uniknąć przykrych rozczarowań.
Can we write successful enterprise software without challenging assumptions? Agile doesn't happen in a vacuum. Here's what I discovered using EventStorming as a blade to cut through business, software and organisation dysfunctions. From XP2017 Cologne.
Software development is not one size fits all. Domain-Driven Design is significant where there's high complexity and high value. In these areas different tools might be needed. EventStorming is the best way I know to gather requirements in a complex environment, and also maps with CQRS/ES architecture perfectly.
@bibakis goes through the secrets of landing a great job on the development or sysadmin sector. Learn why CVs are "a platform for lying" and how to create the perfect cover letter.
Software Developer Career Unplugged - GeeCon 2013Wojciech Seliga
This is my quite subjective take on various less technical aspects of a software developer career. I delivered this presentation and GeeCon 2013 (video hopefully coming soon) and quite compressed/abridged version at InfoSHARE.
Short history of Spartez and information whom we want to hire and why.
Extra bonus: my aspirational thinking about how juniors differ to senior and principal developers.
This slidedeck was presented by me during Spartez Open Day on March 13th 2015.
There are some recurring themes in Domain-Driven Design applications, and distant domains show more similarities that differences, especially when you start taking into account peculiarities of specific Bounded Contexts. This is where a different type of design could happen.
What happens when you have the luxury of leading software projects without trade-offs and you're a Domain-Driven Design fanatic? You start stretching DDD concepts until it hurts and make experiments un uncharted territory.
In this talk, we'll see a few unconventional approached to Context Mapping and what happens when you fully embrace CQRS and Small Aggregates as a modeling paradigm.
Ten lessons I painfully learnt while moving from software developer to entrep...Wojciech Seliga
My presentation from Devoxx Poland 2016 conference - the newest, slightly revised version.
For many years I was a software developer. I would concentrate on the code, software projects and the interactions with my closes team and the users. I was sure that Agile solves all world’s problems. I would laugh over Scott Adam’s Dilbert comics with his Point Hair Boss. Life was simple, life was good. Now for 8+ years I have been running a software company, not a small one anymore. I became myself a full-time boss who only codes sometimes at home or during hackathons.
This session is about sharing with you those critical lessons which I painfully learnt when trying to grow into this new role - transitioning from being a software engineer into being an entrepreneur and top manager. Wheres not all of the lessons may or will (if you dream about your own startup) apply to your case, being aware of them may save you tons of time, energy, money or even help you to avoid the total disaster - burying your own company or dreams. And after all, sharing war stories from the past is fun … when these stories are the past.
Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme.
In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.
This presentation is an introduction to the field of technical writing based on my personal journey and philosophy of documentation, and was presented to the first meeting of Write The Docs Nigeria on February 20, 2021.
Confitura 2013 Software Developer Career UnpluggedWojciech Seliga
My take of our challenging life of a software developer, typical misconceptions, myths and also great things, those which are important. I shared it (in Polish) in Warsaw at Confitura 2013.
Ten lessons I painfully learnt while moving from software developer to entrep...Wojciech Seliga
My presentation from InfoShare 2016 conference.
For many years I was a software developer. I would concentrate on the code, software projects and the interactions with my closes team and the users. I was sure that Agile solves all world’s problems. I would laugh over Scott Adam’s Dilbert comics with his Point Hair Boss. Life was simple, life was good. Now for 8+ years I have been running a software company, not a small one anymore. I became myself a full-time boss who only codes sometimes at home or during hackathons.
This session is about sharing with you those critical lessons which I painfully learnt when trying to grow into this new role - transitioning from being a software engineer into being an entrepreneur and top manager. Wheres not all of the lessons may or will (if you dream about your own startup) apply to your case, being aware of them may save you tons of time, energy, money or even help you to avoid the total disaster - burying your own company or dreams. And after all, sharing war stories from the past is fun … when these stories are the past.
10 bezcennych lekcji dla software developera stającego się szefem firmyWojciech Seliga
[Originally Polish lecture with English slides - with a few exceptions]
Przez wiele lat byłem software developerem. Koncentrowałem się na kodzie, projektach software'owych oraz interakcjach w moim zespole i z klientami. Byłem pewny, że Agile rozwiązuje wszystkie problemy tego świata. Śmiałem się z komiksów Scotta Adamsa i stworzonej przez niego karykatury szefa (PHB). Życie było proste i piękne...
Teraz od ponad 8 lat prowadzę firmę software'ową, którą przy blisko 90 osobach trudno już nazwać maleństwem. Sam stałem się "szefem" na pełen etat.
Podczas prezentacji podzielę się z Wami różnymi doświadczeniami oraz naukami (nieraz bolesnymi) jakie wyniosłem w ostatnich latach podczas mojej stopniowej przemiany z developera/inżyniera w przedsiębiorcę i szefa firmy. O ile zapewne nie wszystkie sytuacje i wnioski mają lub mogą mieć (o ile marzysz o własnym startupie czy zespole) zastosowanie w Twoim życiu, same sobie ich uświadomienie może oszczędzić Ci w przyszłości straty mnóstwa czasu, energii i pieniędzy oraz uniknąć przykrych rozczarowań.
Can we write successful enterprise software without challenging assumptions? Agile doesn't happen in a vacuum. Here's what I discovered using EventStorming as a blade to cut through business, software and organisation dysfunctions. From XP2017 Cologne.
Software development is not one size fits all. Domain-Driven Design is significant where there's high complexity and high value. In these areas different tools might be needed. EventStorming is the best way I know to gather requirements in a complex environment, and also maps with CQRS/ES architecture perfectly.
@bibakis goes through the secrets of landing a great job on the development or sysadmin sector. Learn why CVs are "a platform for lying" and how to create the perfect cover letter.
Client Vs Good design - strategies for avoiding conflict (brought to you fresh from the field)
At some point it’s inevitable: you will be working on a great project when you are asked for changes which can potentially turn a great project into an OK one. Being a good UX’er or designer makes you care about the design outcome, so this kind of situation might present some challenges.
In this talk I present some strategies for keeping designs good, techniques for conflict avoidance, and why your “soft skills” and not just your design skills matter.
Tips for technical communication job seekers. Tips and best practices on resumes and interviewing for technical communication job seekers, from the perspective of a veteran hiring manager.
Top 10 Things To Do If You Want To Get Fired Over A WordPress ProjectWilliam Bergmann
A rundown of 10 of the most common ways to wreck a WordPress project, along with tips to avoid them for Project Managers on both the Client and Agency side.
Resume and job hunting secrets that might surpise youJack Molisani
Have you ever submitted a resume for a position but weren't called for an interview? You probably made one (or more) mistakes that scuttled your chance of landing an interview. After seeing candidate after candidate skipped over because what they had (or didn’t have) in their resumes, best selling author and recruiter Jack Molisani has compiled little-known facts about how employers view and reject candidates based solely on their resumes.
Extreme HR - A new way of hiring and working 100% remotelyAris Samad
We describe the hiring and HR process we use to easily maintain a virtual workforce of 25 people.
We combine ROWE (results-only work environment), remote work and fractional employment.
Learn why you should do internships, how to choose, and of course, how to get them!
This was originally presented on 2nd September 2016 during Friday Hacks #116 hosted by NUS Hackers.
Watch a video of the presentation here: https://engineers.sg/video/friday-hacks-116-internships-and-why-you-should-do-them-nus-hackers--1105
This presentation talks about how to do outsourcing the right way. It needs a proper time investment and commitment, but can really help the small business owner.
Water scarcity is the lack of fresh water resources to meet the standard water demand. There are two type of water scarcity. One is physical. The other is economic water scarcity.
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
CFD Simulation of By-pass Flow in a HRSG module by R&R Consult.pptxR&R Consult
CFD analysis is incredibly effective at solving mysteries and improving the performance of complex systems!
Here's a great example: At a large natural gas-fired power plant, where they use waste heat to generate steam and energy, they were puzzled that their boiler wasn't producing as much steam as expected.
R&R and Tetra Engineering Group Inc. were asked to solve the issue with reduced steam production.
An inspection had shown that a significant amount of hot flue gas was bypassing the boiler tubes, where the heat was supposed to be transferred.
R&R Consult conducted a CFD analysis, which revealed that 6.3% of the flue gas was bypassing the boiler tubes without transferring heat. The analysis also showed that the flue gas was instead being directed along the sides of the boiler and between the modules that were supposed to capture the heat. This was the cause of the reduced performance.
Based on our results, Tetra Engineering installed covering plates to reduce the bypass flow. This improved the boiler's performance and increased electricity production.
It is always satisfying when we can help solve complex challenges like this. Do your systems also need a check-up or optimization? Give us a call!
Work done in cooperation with James Malloy and David Moelling from Tetra Engineering.
More examples of our work https://www.r-r-consult.dk/en/cases-en/
Final project report on grocery store management system..pdfKamal Acharya
In today’s fast-changing business environment, it’s extremely important to be able to respond to client needs in the most effective and timely manner. If your customers wish to see your business online and have instant access to your products or services.
Online Grocery Store is an e-commerce website, which retails various grocery products. This project allows viewing various products available enables registered users to purchase desired products instantly using Paytm, UPI payment processor (Instant Pay) and also can place order by using Cash on Delivery (Pay Later) option. This project provides an easy access to Administrators and Managers to view orders placed using Pay Later and Instant Pay options.
In order to develop an e-commerce website, a number of Technologies must be studied and understood. These include multi-tiered architecture, server and client-side scripting techniques, implementation technologies, programming language (such as PHP, HTML, CSS, JavaScript) and MySQL relational databases. This is a project with the objective to develop a basic website where a consumer is provided with a shopping cart website and also to know about the technologies used to develop such a website.
This document will discuss each of the underlying technologies to create and implement an e- commerce website.
Industrial Training at Shahjalal Fertilizer Company Limited (SFCL)MdTanvirMahtab2
This presentation is about the working procedure of Shahjalal Fertilizer Company Limited (SFCL). A Govt. owned Company of Bangladesh Chemical Industries Corporation under Ministry of Industries.
Saudi Arabia stands as a titan in the global energy landscape, renowned for its abundant oil and gas resources. It's the largest exporter of petroleum and holds some of the world's most significant reserves. Let's delve into the top 10 oil and gas projects shaping Saudi Arabia's energy future in 2024.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
2. Foreword
• Some part of this talk are specific to the French
situation of mid-2014
• Having been on both sides, I am biased in all
cases
• No name will be quoted (companies,
recruiters…) but all data come from true
examples
5. Recruiting = match making
Need Person
Need Competences
Hiring Person Candidate
6. !
Start-up context
• Money issue can change from one day to
another: Ship a product or build a team? Short
term need versus long term people.
• All VCs say they look after the team. Fashion
sentence or reality ? When raising money they
may enforce some hiring “you get this amount
when you get a CTO”
• Timing can be difficult. A possible answer is “do
job interviews all the time”. One, it gives
practice, second it creates a network, third it
helps you keeping a view on your needs
7. Parameters for a search
• How to search : direct, word of mouth, recruiter,
interns and students?
• Type to search: Contractor or employee?
• Who to search: junior or senior?
8. How to?
• Words of mouth and “personal contact” is IMHO
the best. But be careful of “clans” and “biases”
• Using recruiters implies more cost, but with the
hope of less time
• The recruiter problem: how to reduce the signal
to noise ratio? Do not forget, they have people to
be hired. But if the SN ratio gets higher they may
become precious allies.
9. Students hiring
!
• Starts usually with internship. Requires a certain
level of dedication. Do not hold yourself!
• Doing it well may imply that so much confidence
is taken bt the intern/student that she/he leaves
for a better place. See it as a success, really it
is.
• Have no mercy if it does not work. This can be
tough but hiring is also about making decisions
10. The “plumber” effect
• Apply to plumbers, but also electricians,
software engineers, car dealers, lawyers…
• More dangerous for contractors than employees
• “All was badly done. I have to redo a good
chunk of it before I can do my job”
• Ask for “english spoken” precisions, and what
would be the next steps or do not hire
11. Contractor/Employee
• When hiring a contractor especially senior, be
clear on the expectation “I pay you not only to
do a task but possibly to lay down foundations”
• Confidentiality and discretion with employees is
required. Stay in your role, on both sides.
• Plan the conditions of contract ending from the
start
• Be prepared to end fast
12. !
Contractor/Employee
• Think about building a team. Refer to the
Dreyfus model of skill acquisition.
• Decide what should be your team level. Never
forget: simple arithmetic counts. The “level” of
your team may not be the “level” of the “best”
employee.
• Employees talk (wages, opinion on decisions):
be fair all the time and explain it
13. !
WYPIWYG
• What you pay is what you get
• We are supposed to have a lack of engineers.
Basic market law applies. Good ones are
expensive… and may not on the market
• Let’s switch to the side of the one to be hired
14. Contractor
Price
Pay for Insurance
Pay for standard engineers
Pay for code writers
Pay for arms
(Paris 2014)
1200 €/day
800 €/day
200 €/day
Pay for software product doers
450 €/day
15. Contractor
• It’s like buying a pair of shoes. Buying bad ones only
make you pay twice. Buying a trademark depends
on the current shoe-CEO (consulting companies)
• Exception exists but those are exceptions! If you find
a real good contractor for a cheap price, think he
knows it and does you a favor for reason X
• In the Bay area multiply by > 1.5 (in dollars)
• Mistakes happens, those are the rules of the market.
Try many.
16. Employee
• Example of a junior engineer
Junior startup Paris 38/45K€
Junior Consulting/Big Company
Paris or East Europe startup
(Germany, Switzerland neighbors)
42K€/50K€+ Bonus
Junior Well known Startup SFO 90k/100K+stock
Junior Gross Boite SFO 100K-115K+stock
17. Employee
• Good senior in Paris can easily be > 70K and
way higher.
• Replacing money with equity has to be thought
In my opinion, it is a source of problem
• A fair market is the one where what is found for
the value corresponds to what it means. But it is
easy to become unfair; did you say Bay Area
sometimes?
• People know they can move. Play the game of
“trial period” (especially in France). Price are
likely to rise again
19. Preamb
• I have no connection to the author, Mr Joel Spolsky
• I hope he does not sue me for quoting his book!
• This book is the only one that should be read before
hiring developers. All is here!
• It can be read in a couple of hours, so re-read it
regularly
21. Without quoting all books
• Now I will quotes a few excerpts and discuss them
• This talk is already influenced by this book
• Book is more on long term employee hiring
• Really you should buy it (did I say it already :-))
22. Philosophy
• In principle, it’s simple. You’re looking for people
who are
1.Smart
2.Get things done
• The real goal for software companies should be
converting capitals into software that works
Best working conditions -> Best programmers ->
Best software -> Profit
23. What you pay ?
And in fact, the conventional wisdom in the world of
copycat business journalists and large companies
who relies on overpaid management consultants to
think for them, chew their food, etc., seems to be
that the most important thing is reducing the cost of
programmers
…..
Essentially design adds values faster than it add
cost.
Or roughly speaking, if you try to skimp on
programmers, you’ll make crappy software and you
won’t even save that much money
24. Measurement
…
There’s nothing to see here and that’s the point. The
quality of the work and the amount of time spent are
simply uncorrelated.
25. Interviewing
• I can also tell you from extensive experience that if
you spend less than one hour on an interview,
you’re not going able to make a decision
• The third and final part of the interview is to let the
candidate interview me.
• Even though only about one in three applicants who
make it to the in-person interview stage passes all
our interviews, it’s really important that the ones who
do pass have a positive experience.
26. Developers
• On thing programmers pay close attention to in the
day of interviewing is the people they meet. Are they
nice? More importantly: are they smart?
• (Programmers) don’t care about money actually,
unless you’re screwing up on the other things. If you
start to hear complaints about salaries where you
never heard them before, that’s usually a sign that
people aren’t really loving their job
…
That doesn’t mean you can underpay people,
because they do care about justice
28. Create a fixed frame
• Have more than one person interview the
candidates.
• I prefer when the first is the team leader/manager.
(but some prefer differently).
• Avoid overlapping exercices. Prepare with your
team
• Do not wait to provide feedback, especially in case
of rejection. Be honest with the candidate
29. Resume screening
• Difficult to get an idea of what the person is able/
worth. Look instead for hints : number of years
versus number of known technologies, words used
to describe and experience…
• In case of doubt, keep or do phone interview.
Personally I often send a technical short
questionnaire (some disagree with this practice)
• Read a lot of them!
31. A scenario
• 10 minutes: introducing the company and myself.
Explaining the interview process and what is the
goal :”we will see if it can match”
• 10 minutes: let the candidate give “his vocal version
of his resume”. Could be also something like “tell
me about your last project”
• 30 minutes: exercices (2 to 3)
• 10 minutes : let the candidate ask yourself
questions. If she/he has none ask “what did you
think of this interview”
• 5 minutes: debrief. If this is “No hire”, say it now
32. Exercices
• 2 to 3 of them, each one has a goal. Explain to the
candidate what are those goals
• Simple computer exercice. See if it is done fast and
with all attention. If a simple exercice is getting into
a nightmare, this is the only case where I would say
“OK this will not work”
• Then more something “do you have a complete
view of how something works” that goes into “Can
we talk about a technical problem”
• Finally maybe one of those “logical/invent” stuff.
More also to see what discussion is possible
33. End of the interview
• Simple decision hire or not hire (We’ll see later in
case of real real real doubt). If simple doubt no hire.
• Some interviewers may have a veto right.
• Direct rejection must be explained directly. It is rude
to send someone home and then send one of those
impersonal rejection email
• If multiple interviewers, say “we’ll debrief and get
back to you ASAP” … and do it.
34. The real real real doubt
• Usually at the beginning of a startup. Not enough
people to interview the candidate and still some
uncertainty of what will be done
• This is not to “give a second chance” when
someone has failed. More about “I am not sure
about what role I need in priority”
• I usually ask them to do an exercice and write some
code. Personally I find this useful.
• Other may think differently and reject directly
35. Post hire check list
• Do 1-1 meetings (More US than European). This
avoids isolation
• If this is not working : fire is usually the only option.
All others are about loosing time.
• Never think a situation is eternal (trial period in
France). It can take a few months to really
understand someone, but make sure you do not let
a situation go bad because of refusal to deal with it.