"Have the candidate come in to work with you for a day. "
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?
I don't know about you, but in my experience it takes a pretty long time for new hires to produce anything of much value.
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....
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 :)
If I were seeking a job, the primary motivator would be having peers/assignments from which I can learn, I will gladly invest a day of my time to ensure the place I am going to spend the next many months/years of my life, is actually an interesting place — even if the other party might (also) get something out of it.
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.
"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."
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.
Presumably we have different views of what was originally meant with “come in to work with you for a day”, seeing as this has now turned into “work for free for a day” ;)
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.
Maybe it's something that happens as you get older. The risk / reward trade-offs change. Taking a lower salary in return for a chance of big rewards starts looking less appealing than selling your accumulated skills and experience for the market rate. The breadth of skills and experience are themselves what will help select for interesting work; and if the new place doesn't work out, no big deal, it's easy to move on to somewhere else.
That's probably because you're making the erroneous assumption that just because money is your lowest priority, it's also the lowest priority for others.
"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.?"
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.
The disconnect probably stems from types of job. You say you can get the same experience from contributing to open source, so it sounds like the job you have in mind is pretty much just a consultant gig, i.e. “here is your assignment, write the code” — that is not exactly the type of job I had in mind when involving giving a day of my time to find out if the job is a good match (for both parties).
Is it just me or does the misuse of the label "Engineer" bother anybody else?
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...
Do people who work in software startups generally take Physics, Chemistry, Calc 1-4, Diff Eq, Statics, Dynamics and so on while at University?
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.
"Engineering is a thing you do. It is not the name of a course, a piece of paper, or a certification exam."
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.
"In every state in the United States you have licensed by the state to call yourself and engineer and sell engineering services."
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.
For a PE in KS, you complete an engineering curriculum. Take the FE test. Then you study under any PE for four years. (Not four different ones for one year, but I suppose that would work.) Finally, you have to pass another test. It's not really too much to ask for the guy signing the blueprint that says the power lines or building being put up won't kill anybody.
That's a step in the right direction, and many jurisdictions seem to be doing it lately. However it is still too much. They need more gradations, like how medicine has a spectrum from phlebotomists (people who draw blood) to board certified neurosurgeons. As it is, a handyman who uses Ohm's law to choose the size of a wire has committed illegal engineering.
Generally, Electricians can do things similar to that if they follow the local electric code. I've watched them work--they don't consult the building drawings or whatever, and they can make some pretty extensive changes.
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.
Read the actual laws. They generally require a licensed PE for any task that (1) requires engineering or technical knowledge to complete correctly, and (2) has an influence on life, health, or property, no matter how trivial. It's like requiring personal trainers to be board-certified cardiologists. Naturally everybody ignores this, and compliance consists of not drawing the attention of the state engineering board.
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.
Out of curiosity, what is your definition of a "real" engineer.
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.
In many engineering disciplines you're legally forbidden from self-applying the title of "engineer" -- you have to be licensed and take formal legal responsibility for the quality of your work. That level of discipline and rigor is what most people are referring to when they distinguish between "software engineers" and "real" engineers.
It's not nearly that strict. You can't use the title "Professional Engineer" without licensing, but non-licensed engineers can and usually do use the term "engineer", or derivatives like "chemical engineer" on their business cards and resumes. It's the norm in firms with a lot of engineers (like, say, Exxon) that most of the people whose job title includes the word "engineer" are not PEs. It doesn't even really give you any benefit to be a PE in the corporate context, because everything you're doing is on behalf of the corporation anyway; you're not an independent contractor providing services that you have to legally stand behind, but an employee doing work for hire.
edit: This is true for the U.S. anyway. I believe some other countries are more strict on who may call themselves an engineer.
So would you be ok with calling people software engineers if they had to take a test to get a license and then be responsible for failures of their code in the future?
The term "software engineer" has always been problematic to me for this reason, and a lot of real engineers agree, but among software people it's just become accepted. Whether you keep on arguing about it it mostly a matter of your own stubbornness. I'm stubborn enough about it to distinguish "software engineers" from real engineers, but I'm not stubborn enough to turn down a job just because the job title contains the term "software engineer".
I am also curious as to whether software engineers are exposed to as much ethics and consequences of their actions as the other engineering disciplines (ME,EE,CE).
Not religious about technology (or anything really). This is useful at any size company, but at a startup you really don't want to waste time debating the merits of Python versus Java.
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.
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.
"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.
do you think this attitude might have something to do with it?
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.
I don't think he's being particularly condescending. I know I'm not very bright, but I've walked away from recruiters simply because they were clueless and condescending.
You can pitch me to work for peanuts, but if you're a slimeball, it's probably not going to work.
He could be absolutely right, but whether or not he's right, statements like that are likely to be interpreted as being about attitude than circumstance.
This line of thinking is failure waiting to happen.
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.
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?