- A Job offer is a beginning of a relationship. The relationship is with the hiring manager and the organization, not with the HR department. Starting a relationship by delegation is wrong.
- Money is not a “dirty” thing. Hiring managers should be able to negotiate and understand financial aspects of their work. On one position ,as a candidate, I got the final offer from a relatively junior HR associate. I felt uneasy negotiating with her as ”she did not have the power” and it was “unfair” to push her. A company is a for-profit organization.
- Hiring managers must be aware of equal opportunity, non discrimination laws and social benefits their employees are entitled to. These are important from ethics perspective and (in good companies) reflect the overall vision and culture of the company.
- A Job offer is a selling process. Selling and marketing are key managerial capabilities, in any role.The hiring manager has more credit as he describes his own professional and personal opinion, since he is “hands on”.
- This is a great,last opportunity, to set expectations before the commitment. The contract is a (good?) way to define minimum expectations in a legal document. But it is up to the manager to define his expectations for the specific role. “How many hours a day”, “How much travel?”, define “Work Hard”, define “Excellent”.
Archive for the ‘Recruting Interviews and Resumes’ Category
“Without Spam, we wouldn’t have been able to feed our army.”
Nikata Khrushchev, ‘Kruschev Remembers’ (1970)
“You are very fortunate to be assigned to duty at Fortress Monroe on Chesapeake Bay; it is just the season for soft-shelled crabs, and hog fish have just come in, and they are the most delicious panfish you ever ate.”
General Winfield Scott, May, 1861, speaking to General Benjamin Butler
I was surprised to see there isn’t enough research on the role of food in the software development process.
Here are some observations that might be expanded later, on demand.
- In California, lunch is sometimes sponsored by the company.
- In Israel, in Hi-Tech, lunch is sponsored by the company, takes about 60 minutes and is eaten in Restaurants outside the office. The “Official” lunch break is supposed to be 30 minutes.
- Is this tradition coming from the earlier socialist roots of Israel? Maybe it stems from the army background of many developers.
Personally, after 10 years of fried eggplants, eggplants in tomato sauce, eggplants in Tahini, eggplants with vegetables and eggplants macaroni, I was very happy to start eating proper lunch in top restaurants.
- I once had to fly to a development center in Minsk,Belarus and eat borscht, for the first time in my life. I had to make sure the food level was comparable to other sites. It was a beautiful city and the borscht was better than I expected
- In Israel , the employees eat lunch together and it is a great opportunity for team building. In California developers eat alone at their desks, which I always found a bit sad.
- In California, 30 minutes lunch breaks are mandatory. It is similar to Israel.
- Whenever we had to work on Fridays, I used to bring an extra nice breakfast for everyone . It helps make the atmosphere more causal and expresses this is special occasion and not taken lightly by “management”.
- In Belarus (2006) the cost of developers lunch was ,in some cases, almost 25% of their overall compensation.
- No free beer in Israel. But Diet Coke is a must have. A top-notch espresso machine is quite common, in Israel. In the states horrible coffee is the norm anyway
- The cynical view is the employers use food as cheap way to get employees motivated. The reality is that it is not so cheap. Assuming cost of 800 NIS per month it is 2.5%-8% of the compensation.
- A less cynical view claims that the 60 minutes lunch breaks are critical to get developers to work 12 hours a day. In reality, few employees work 12 hours a day, and there is little correlation to the ones who have the longest lunch breaks
- Food does touch people emotions and demonstrates diversity. For example, a top engineer who suffers from Coeliac was extremely happy when one of our restaurants helped him select relevant dishes. At the same time, we helped Muslim engineers who needed to eat their lunch later than usual during Ramadan.
- We are all quite fortunate to work in such great conditions. Our peers in Medical establishments have to live with Hospital food, if they even get enough time for lunch break.
A man walks down the street,
He says, Why am I soft in the middle now?
Why am I soft in the middle?
The rest of my life is so hard!Paul Simon, “You Can Call me Al”
On a previous post I described some “Contracting Nightmares“.
Today, the focus would be on the full half of the glass. The freelancers that killed a dragon for us.
The ground rules are:
- Hire a person you know well, and consider to be a top performer (“Shakel” in Hebrew). Don’t lower the bar for temps.
- Hire a trust worthy individual who shares your core values and understands your “language”.
- Hire him, or her, to work in their field of expertise.
- Hire “over qualified” contractors, for short-term assignments.
In my experience, only the following combinations work out well
- A Well defined, isolated project
For example “back-porting open source Japanese fonts library from 2.4 to 2.6″.We had to do it for our SSL-VPN products.It was an ugly job, but somebody has to do it. It was not really related to any domain expertise we had inside the company and it was a non trivial task. On the other hand, it was a pretty well-defined project so the contractor could scope it well.
- Hire a contractor for at least 6 months as an integrated team member
For our GUI team we needed an additional developers(see post) but could not find candidates that met our expectations.
We had three hiring experiments with outside help. The one that works well is outsourced from an external company, but has passed all our usual tests. He was not a “compromise” in any way. Moreover, he is an expert in .Net ,so training time was less than a month. Since he came from an external company we got a 12 months commitment.As a result the on-boarding costs are smaller, and we still have a lower financial commitment.
We also examined the company’s background, since in previous attempts we realized the “best” in some companies may not be productive enough in our environment. In other words – contracting is more expensive than in-house, therefore contractors should be just as good as full-time employees , if not better.
One drawback for this method is that the freelancer cannot become an owner of core functionality, since his future is always “at risk”.
The other drawback is that such contractor requires managerial attention,making it suitable to well established teams.
- A research and scoping project
In Cloudshare’s very early days (aka as IT Structures) we wanted to have our first paying customer ASAP. Our feeling was that real customer’s feedback is critical for our success. We only had two developers at the time, so we hired I.Z to help us with building a virtualized networking architecture.
IZ was an experienced team leader and architect that lead two complex networking projects in his previous roles. He was in between jobs, as he was considering his next career steps (being both a great singer + a talented coder).
We were considering which remote console protocol to use ( VNC\RDP\ICA) and needed objective results showing how well each worked over different latency and packet lost conditions. To our surprise, there was not updated research available.
IZ came out with objective and clear results in a new territory’s for us in which he had domain expertise. Till this day our remote access performance is one of our key advantages over other solutions in the market.
I trusted him, so we could work on time and materials base. He trusted us that we will not nickel-and-dime him. I always prefer to pay by the hour, as scoping is hard for complicated projects.Both sides feel wrong if the estimate is wrong for a fixed costs project.
To conclude – contracting can work well, but it is not a silver bullet. Chances for success improve if some basic rules are followed.
- 5 Red Flags You Shouldn’t Ignore When Hiring Remote Employees (businessinsider.com)
- Why I Don’t Like Time & Materials Gigs (T&M). (jarrodloidl.blogspot.com)
Contrary to what many programmers think, QA role is not to do the dirty work for them. QA’s role is to validate, independently, that the code actually works.
The reason I put the responsibility on the coder is simple. The coder is the one who writes the code, the one that understands it and the one that can change it. Why should anyone else be the owner ?
QA has a lot less options for proving the code works and reducing the risk than the developer, they can only test the functionality from a black box perspective.
The developer, on the other hand, has multiple options , beyond the ones already listed in part II.
- Rewrite the code in a more modular fashion so it is easier to have unit tests
- Move from c# to Python to make it easier to write mocks and do sub system testing
- Add logs, alerts and assertions so he knows that edge conditions are safely handled
- Refactor the code so User Interface validations and server validations use the same mechanism
- Add new code with a separate flag\object\screen so it has less chance to have regression on other functionality
- Shout at the product manager that the requirements are too complex and there is not way to implement them In SQL with proper testing
- Move from simple ASP.NET mode to MVC model so more parts of the UI can be tested separately
- Ask QA to help with extensive PRE-COMMIT manual testing as part of the development stage
- Ask QA to help with running the automatic testing on development branches
- Help the Automated QA team to make sure new features are tested during the development stage and not post deployment
The manager role is:
- Iterate over and over the concept of ownership, proof and responsibility
- Back the theory with resources – buy machines for testing, software for code checking etc
- For example, buying two servers for the clustering team so they can test their code actually runs on a cluster
- Help to manage trade-offs and real world considerations
- For example, which functionality is used a lot and which is hardly used
- Pay the “price” for making higher quality code
- For example, Pay $50,000 for a new automated testing project
- Avoid being dogmatic in the specific methodology
- For example, unit testing might not be effective in certain places and forcing everyone to do them will just create resentment
- Introduce and promote new technologies such as Virtualization and lab automation
- Help apply the right methods in the right context
To summarize, like any other professional, the developer is the one responsible for the quality of his or her work.Allowing them to push unproven code to customers is what gave us bad reputation as an industry.However, the best ones are able not just to code, but also to analyze the risk, check for validity ,rewrite and design to create bullet proof products.
And if you read so far, here is a reminder to a lovely 80′s song.
Continuing from the previous post let us check why would one pay a developer who can’t prove his code is working.
When I was in Check Point I used to have weekly pseudo-random interviews with employees. It is a great habit that I learned from Dorit Dor, my manager at the time.
When you manage 200+ employees it is one of the only ways to get direct feedback and stay in touch with what’s really going on, but it turns out to be a good idea even when there is only a single employee reporting to you.
One of my favorite questions to developers was :
How do you KNOW the code you produce really works ?
Amazingly, this pretty simple question had all of them surprised.
The university graduate, the PHD, the autodidact , the hacker, the PC kid and even the group manager. None were prepared for this question.
The common answers were :
- I don’t know it works, but I have a good feeling about it
- It works most of the time
- QA will test it and than I’ll know it works
- I tried it a bit and it looks fine
- I did a code review with my team leader and he approved it
- It is a small change and I’m confident in it
- There is no way to do it in the time I was given
As you can imagine, I was not very happy with most of these answers. Here are some of the best developers in the world, with five time the salary of a social worker with 30 years experience, and they can’t explain why their work is actually ,hmm, working.
My belief is that the Developer has to PROVE ,to a reasonable degree, that code he commits is working as planned and does not break other code.
If he can’t do it , he should not be committing the code to the general working branch.
How can the poor programmer achieve this goal:
- Running and writing unit tests for his code and running them
- Writing sub system tests for his code and running them
- Using code checking tools, looking for warning, errors and suggestions
- Asking peers for a code review
- Going through the design and requirement and validating actual code implements them
- Manually working with the system and going through all scenarios he claims to support
- Spending couple of hours trying to come up with all the extreme cases and special problems
- Going over the QA test design and making sure his code will pass the tests
And by the way, if all these methods are not available \ reliable or feasible it is also OK to commit the code if the developer EXPLICITLY lets everyone know the status before and gets the managers approval.
I want to commit the new screen, but I never tested it on FireFox and there for I assume it does not work on FireFox. Is it OK to commit ? I also didn’t test the sorting or the client side validation, but I think they might work because I didn’t touch this code and it is very solid
Obviously , developers are notoriously over optimistic so this should be kept as a last respot, but making them say it out loud is key to maintaing high level of professionalism and ownership. More on this in the next post.
The Tip: Write your achievements, not your whereabouts.
Reading thousands of resumes in the last eight years, I get very frustrated from the candidates inability to market themselves. While there are hundreds of on-line sites that give great tips, people seem to be ignoring them completely.
When I read a CV I expect it to answer the following questions:
- How can I know the candidate would succeed in his role?
- Why should I hire this specific candidate?
- What is his past record?
The simplest way for a resume to answer these questions is by describing previous achievements. Think about it as what you want to write on your professional gravestone, if the worst thing happens.
2000-2004: Software developer in Lucid Multimedia, part of the tools team, wrote in ASP.NET(C#) ,SQL Server, NHibernate.
2000-2004: Software developer in Lucid Multimedia ,owned the development of an ORM module between SQL Server and C# business logic.
2000-2004: Software developer in Lucid Multimedia, I lead the development of an ORM engine that reduced development time for new forms by 40%.
2000-2004: As a developer in Lucid Multimedia, I lead the development of an object relational mapping engine that reduced new forms development time by 40%. I developed the engine in 3 months, and I improved the performance of top queries from 5 minutes to 20 seconds.
Can you see the difference?
For top jobs, I do not care too much about the candidates’ set of skills. These should be mentioned, but can be described in a short paragraph in the end of the CV. It does not mean much that a candidate was a C++ programmer for five years. I know plenty of poor C++ programmers. Maybe he is just one of them?
Maybe during these five years he was reading TechCrunch and browsing Jdate in the search of a more promising future. Facts on achievements are much better. The candidate needs to briefly explain major achievements, show all signs of excellence and why his previous employer would miss him after he quits.
For some reason, I get a lot of objections when I try to help people improve their resumes. The most common ones is:
“My work cannot be measured in quantitative manner since I’m Psychologist\Software Team Leader\Business analyst \Milkman”
My belief is that in any subject matter there are ways to explain the achievements in a clear factual way, at least to readers who come from the same domain. The trick is to find the right angle.
- 2000-2003 I supervised the treatment of five children aged 3-4 with severe social skills difficulties. I managed and mentored a team of assistants, speech therapists, and art therapists in a highly demanding and intensive environment. All five kids are now studying in regular schools to their parent’s satisfaction.
- I coordinated $100,000,000 budgeting process in a multinational consumer company. Initialed a new process for budget preparation, across departments. As a result the budget was ready in November instead of December, allowing the management to have proper preparations.
- Internal Guru and the Go-To-Girl in building highly complex Excel planning modules. In 2 weeks I prepared a sales compensation plan which is used in 30 countries across the company.
- Three members of my team have become team leaders within two years.
- Improved the relationship with QA peers by conducting open weekly meeting. Product quality and atmosphere have greatly improved.
Remember – the facts don’t have to be numeric or printed on paper. Fact checking will be done later during the interviews and reference checking. At the resume stage, the reader trusts what he reads.
If it is hard to find measurable indexes of success, at least try to give more details on what you have been doing.
What was the size of the project? How many people did you manage? How much money was involved? How many customers were served? How does it compare to the situation before you started?
The best thing is if you can show samples of your work. I love it when people add a a link to web site they built or an open source project they lead. It makes it very easy to check their professionalism.
To summarize, don’t be shy about your achievements, you need to market yourself. The best way to do it in an honest fashion is to give the facts which highlight your contribution to your last employer.