Traits Needed In Your First 5 Engineering Startup Hires
blog.eladgil.com
blog.eladgil.com
I'd only agree to this if I got paid for it. Interviewing is one thing, but actively contributing to a company's codebase is another. I don't think it's asking too much to get paid for what I do.
Plus, it would be difficult for me to shake the impression that such a company is cheap and is trying to get free labor. If they're not going to pay me a day's pay, how can I trust them to pay me a yearly salary or provide me the tools I need? How likely are they to be in business a year from now?
You think you will provide value which exceed the knowledge you might gain from learning about their systems and working/talking with their other employees, etc.?
It is a great chance to get to work with new people if the domain is exciting. I would welcome such opportunity w/o demanding money for my “services” which probably consists of asking a lot of questions :)
Though if I know in advance that the “trial day” will consist of me “donating work for free” then I doubt it is a place for me.
This might sound like a cliché, but money is the last thing on my mind when selecting a job or employee (I am presently an employer), and I am somewhat surprised by the point assignments given to the parent and grand parent comments.
It sounds like you and I actually agree for the most part. Both the hirer and the hiree have the same problem: hiring is almost like extracting War & Peace from a newspaper. Is it necessarily fair for me to turn somebody down for wanting me to do a "trial day"? Of course not. But I have to go on what I have to go on. Just like it's not fair for an employer to hire me using a cover letter, a resume, and a couple of hour-long interviews.
So if a company asks me to work for free for a day, should I draw the conclusion that they're really wanting to evaluate me well or that they're cheapskates who won't pay people for doing work? Just like you'd probably rather turn away a superstar than hire a dud, I'd rather turn down a kickass company than work for a crappy one. So I'm probably going to go with the latter.
Don't get me wrong, money isn't what I'm in this for either. But that doesn't mean I should let people take advantage of me.
Of course the intent was not to just get someone in to work for free, but more like when you take a first meeting with a new accountant or similar, you may ask him lots of questions related to your situation, and he will answer you based on his knowledge and experience. Most will not charge for the first meeting, presumably under the assumption that providing the client with useful information only increase the chance of having the client pay for future services.
Similarly if you come work with me for a day, and I am impressed with your abilities, you can be rather sure I will hire you. If I am not impressed by your abilities, I am almost certain that you will have learned something from the experience (either about your own skills or the tech. we work with), so for the client I would say this is win/win.
That's not the point. I program for money. Therefore, me writing code for someone else is a business transaction. If I want to get experience without compensation, I'll contribute to an open-source project. But I'm not donating my time to a for-profit organization unless they donate money to me.
If you're going in for a "trial day" at a place full of engineering neophytes who will look to you as a God for 8 hours, then you didn't do a good job of screening that company out as a potential place for you to work. (This is assuming "trial day" happens after an initial pass of the usual phone screens and whiteboard coding sessions.)
In our case we would explicitely tell the people who interviewed that we would throw away all their code at the end of the day. It was pretty unlikely anything they did would actually be valuable to us in such a short period, and giving the candidate something mission critical to work on was a no go.
In 1 case, we did have someone come in for a week (on the UX side) and we paid the person for their week of work. She actually was the one who suggested a full week with us, so she could really get to know the team and see if it was a fit (it wasn't, so it is good we tried it out)
It is not unusual to end up spending 5-8 or more hours interviewing with a company - you would not ask to get paid to come interview, and the code exercise was another form of interview.
Finally, this was a great opportunity for the candidate to get to know us as well - how did we collaborate on stuff? What process did we use? What was the team environment? This allowed a candidate to come in with "eyes wide open" (well, more open) regarding our workplace....
Do people who work in software startups generally take Physics, Chemistry, Calc 1-4, Diff Eq, Statics, Dynamics and so on while at University?
I was a little squeamish calling myself an engineer since I never took the certification exam to become a Professional Engineer after graduating with a BS in Aerospace Engineering...
As a Ph.D. in EE, who did indeed take all of these things before becoming a software engineer [1], I feel eminently qualified to say:
Engineering is a thing you do. It is not the name of a course, a piece of paper, or a certification exam. Don't let the maturity and professionalization of other forms of engineering blind you to the real meaning of the word. I believe there was a time, in the 18th and 19th centuries, when there were significant numbers of engineers who were "practical men" and didn't go to college. They were engineers, and so are we.
An engineer is someone who designs and builds machines that do work. [2] And software engineers design and build machines -- some of the most complex machines ever built by conscious mind. We count.
---
[1] I highly recommend studying all of these things, by the way. They are not just useful subjects, but very beautiful ones. Don't neglect biology, either.
[2] People who build machines that look pretty are artists. People who understand why the computing machines work are computer scientists. Nothing stops one from being all of these things at the same time -- indeed, many people, including myself, think that it helps a lot -- but neither art nor science are synonymous with engineering.
"Scientists discover what is, engineers create what never was. Think always about how things can be improved, or how new things can be created."
Actually it is a piece of paper. In every state in the United States you have licensed by the state to call yourself and engineer and sell engineering services. The same as doctors, nurses, lawyers, barbers, and whatever other professions states deem required to have licenses.
And those laws almost universally ignored.
The trouble is that the laws are so overbearing that they choked off the supply of new licensees. The first people to get licensed, because that was the entire industry at the time, were things like boiler and power engineers. Suppose you were a young engineer and you wanted your PE license to design metal detectors "properly". You'd have had to specialize in something like power systems, sign up with whoever had a PE on staff, spend 6-12 months sizing transformer windings and designing 50 kV relays (because most PEs worked at places like that). Then you have to jump ship to work with a different PE, because you need to accumulate an apprenticeship under four PEs before you can get a license. Only then can you get your license and go back to school to specialize in what you actually want to do. Finally, in your late 20s, with no job longer than a year, and just starting work on your passion, you can try to get a job in metal detection.
Most new engineers sensibly decided to just break the law. Even if the engineering board were certain to catch up with you, it would be easier to quietly move to another state in the middle of the night and start over. And the actual odds are more like one in 10,000.
P.S. IIRC Texas scrapped a lot of their silly PE laws.
The PE license gets you the ability to sign off on drawings, so if there isn't a drawing change involved, there isn't any engineering to sign off on.
Electricians follow a handbook rather than derive results from general knowledge, so the PE laws don't apply. As long as the electrical code handbook allows it, they can do it. Possibly at enormous expense, which is why you want a power engineer to plan your factory wiring.
I've always thought a phlebotomist is similar to a licensed electrician. (Assuming an MD is similar to a PE)
Or to put it another way, why isn't someone who writes software worthy of the title "Engineer"?
> Do people who work in software startups generally take Physics, Chemistry, Calc 1-4, Diff Eq, Statics, Dynamics and so on while at University?
That is kind of a broad question. But I can tell you that at Berkeley, everyone in the School of Engineering takes those classes, whether you are going to be a materials engineer or a software engineer.
Edit: I'll throw this out here too:
Definition of Engineering: The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.
I would posit that someone writing software uses scientific (debugging) and mathematical (algorithms) principles to practical ends.
edit: This is true for the U.S. anyway. I believe some other countries are more strict on who may call themselves an engineer.
The take-away should be that start-ups prioritize completeness over correctness. I think everyone agrees with that. Getting a feature out the door is more important than whether that feature was built in Python or Java.
The question is, how do you get tons of features out the door at a sustainable rate? I think the answer lies in finding passionate people-- hackers who some people might call "religious about technology."
The real traits needed in your first hires are all related to aligning peoples' passions:
1. Hire people who passionately believe in the product. Make sure they are well-aligned with the founder's vision. This reduces the chance of needing to argue about completeness vs correctness.
2. Hire a group of hackers who share the same vector of programming language and programming culture. For hacker-entrepreneurs, this is easy: hire hackers who share your values in technology choices. This reduces the chance of arguing over the definition of correctness.
In short, here's the article's main argument:
After you have narrowed the pool of applicants down to those with the skills, experience, and knowledge to do the job, ask each candidate one question:
What do you do in your spare time?
Would this conflict with point #7 (Do "just enough"), or can a passionate candidate be taught to accept less than perfect results? Regardless, I have trouble seeing how you can accurately measure a persons ability to accept "just enough" without input from a trusted third-party.
What most startups need is not another engineer. What most startups need is a business person who understands engineering. We can quantify value.
After attending the Hacker Fair 0 (Mtn View) . . . flying out there especially for it, having my demos ready and talking to way too many "recruiter" types who understand nothing about code, this really rang true. Technically-oriented business people are not recruiters any more than engineers are recruiters. Recruiters are people who read articles like this (parent) and manipulate people to work, solving a company's problems for free. They're usually the last ones a company must resort to to find talent.
I've yet to find a company intelligent enough to hire me.
Not to be rude, but do you think this attitude might have something to do with it? I'm asking this because sometimes us geeks really don't know when we come off as condescending.
Bear in mind that I say this as someone who has put my foot in my mouth and said more stupid things than I would admit to publicly.
You can pitch me to work for peanuts, but if you're a slimeball, it's probably not going to work.
No. I say this as a person who has been homeless because nobody would hire her. I'm not the most genius on the planet, but I'm also not an idiot. I've dealt with far too many people who, when bragging about being an "engineer", fail to understand the value of having somebody on the team who knows and talks business.
Can a business person who understands engineering build the site? Nope.
You're basically hiring a business person who would hire engineers. I believe the engineers in a company are good enough to hire engineers.
Sooner or later, a team of engineers needs to have the value of its time-consuming product quantified. If you hire somebody who is on your side, then the variable is certain to go up, and a business person will end up making everybody on the engineering team more money by adding a quantifiable value to the efforts of the collective. Business people are engineers' advocates. Failing to hire a business person means product will almost certainly get "ripped off" or valued less than its market value, at the detriment of every body on the team.
Do you really think startups should make it a priority to hire a business person over engineers in the early stages?
The article is about hiring the first 5 engineers but do not take is as do not hire a business person. Eventually, a startup would definitely need one but in the early stages, a startup can survive without a business person.
Can you name a startup that was founded without an engineer? I can name you numerous startups that were founded without a business person easily though.
That's not enough - you have to be able to produce value.