Hire talent, not five years with Java
gillesleblanc.wordpress.com
gillesleblanc.wordpress.com
40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply whining about it. Presumably, with tools that are 40+ years better that making it "easier" to program, such a system of the past would be reasonably replicable today, no? I've seen a few things pop up here and there - hungryacademy and such, but, by and large, this is the exception far more than the rule. Once upon a time, companies would hire and develop talent, investing years to develop the talent with years of rewards on the end for both sides of the deal. Now? Companies expect hires to come fully trained, ready to deliver from day one, at their own expense (and much debt to the banks). Employees have no loyalty (and for good reason).
With CS, it seems like every company's looking for young, energetic undergrads fresh out of college who know the latest technologies, in many cases to replace the older people. It's always seemed a little too short-sighted to me... not sure how my generation of CS majors is going to do in the long term.
The way to bet is "very badly", and if you're a conventional salaried employee have your exit strategy well in place by the time you hit 35. Expect to be conventionally unemployable at 40, unless you can hide your age.
29. I don't expect "conventional employment", as defined by VC-istan or the corporate megaliths, in 11 years. Those will exist, but I don't think they'll be where the exciting action is.
But yes, if you're applying for subordinate positions that any idiot can fill, and you're 40+, you did something wrong. You don't need to be a manager by 40, but you need to be at a level of skill where it's obvious that you don't need traditional "here's work, go do it" management.
This sort of working environment has no slack, no capability to operate effectively in apprenticeship mode, and little leeway to allow long ramp up times. And as a result it has become more difficult to positively advance the state of the industry or the average skill toolset of coders.
It's the classic problem, when you spend all your time in emergency mode fighting fires you don't have the cycles to be able to make improvements to systems or to other coders as well.
> (...) death march should be the norm. Meaning, 20-somethings should be working 80 hour weeks on a regular basis and projects should be shipped at the soonest possible moment it's even remotely feasible to do so.
has got me puzzled: in my (limited) experience and from what I've read, a death march is exactly the opposite of shipping early. The usual story goes: a deadline looms, or a milestone slips, a middle manager decides to whip up his team instead of reporting it. Overworked team members can't meet another deadline, the client and/or upper management is kept in the dark about the problem, no extension of deadlines for sake of good metrics, rinse and repeat.
``It is done when it is done'' and shipping early is a panacea, not a cause of the problem.
And yes, it's not a good way to work. Nor is it even a fast way to work. It's a an equilibrium point that is reached when certain initial conditions in regard to the value that is placed on the appearance of work and dedication are higher than craftsmanship et al is valued.
For people who are immersed in that world view it seems perfectly logical that adding more hours worked will make everything better. But the paradox is that it doesn't, it often makes things worse, for a whole laundry list of reasons. People become physically and emotionally exhausted by the pace, there's no room for higher level improvements which are often the only way to achieve orders of magnitude gains in efficiency, productivity, and quality.
There are a handful of companies that do things right and at those companies employees tend to stick around for not just a few years but decades and the products they make tend to have an outsized impact on the industry (valve, blizzard, 37signals, pixar, etc.) But it's still so hard to fight against the conventional wisdom.
The apprenticeship makes sense in the lawful-good guild culture; tough culture is chaotic evil. (Typical corporate rank cultures, where subordination is key but you can get away with pretty much anything-- even doing nothing for years-- so long as your boss likes you, are lawful evil; Valve's bossless, self-executive mode is chaotic good.) So the tough culture of startups is the exact opposite of the progressive (but usually incapable of immediate scaling) guild culture.
I think this mentality affects all aspects of our lives and society. How do you disrupt this shortsightedness?
VC-istan is based on a get-big-or-die mentality. These companies end up with tight deadlines because they're forced to hire so fast. That makes them panicky and stupid when it comes to operational concerns... and it's bad for culture, but no one cares about "culture" in something that exists to be bought by Yahoo in 3 years.
The future isn't going to be built by VC-istan, but by a fleet of ~50,000 small-to-medium businesses formerly called "lifestyle" companies, and the whole ecosystem that grows up to support these "yeoman capitalists". It's going to be built by people that, right now, no one will fund.
The problem is that no one will fund these companies now. Bank loans are good for dry cleaners and restaurants that are unlikely to go to total failure. (Half will be closed in 5 years, but most because their owner-managers could do better elsewhere-- opportunity cost.) VC works for a 5% shot at being a billion-dollar concern. Who funds the 30% chance at becoming a 20-person lifestyle company that, while it never makes a billion, pushes technology forward in a major way? No one, yet. There are "moral hazard"/principal-agent problems to be solved, but they aren't that hard.
I'm actually addressing that in my 17th part of the Gervais / MacLeod series. I'm between jobs (I have offers, but I'm not working right now) and I've had time to really attack this problem. It'll probably be out around 3:00 today.
Right and, maybe, this partly why a growing number of people do not stay at a company for too long. (I think you mentioned this idea (that, basically, human labor is an easily trade-able commodity) in one of your Gervais / MacLeod posts.)
The problem is that many technology companies have natural economies of scale. It is not realistic to have a world where you have 1,000 mom and pop search engines instead of 1 Google. One search engine becomes a little better, so more people start to use it, it can make more money, invest in more technology, become even better, get even more users, and eventually the top dog becomes a run away success. Since the entire idea of technology is that you research the novel technique once, and then can use the technology over an entire user base at a low marginal cost, there is a natural economy of scale.
There is of course already a very large economy of "lifestyle" businesses. But these businesses are either b) not in the technology business (restaurants, retail, services, etc.) or b) in an extreme niche of technology where there are so few customers the company never grows that big.
I really do not see how you can break a Microsoft or Apple, much less a Google or Facebook, into 50,000 smaller businesses.
Web Search is a Big Problem and, as you said, it's a winner-take-all, red-ocean business. Google managed to come in when the state of the art was horrendous (few considered search to be an interesting problem; it was "solved" but shitty). Now Bing is almost as good as Google, and certainly far better than Google was when it established dominance of Search.
You say: I really do not see how you can break a Microsoft or Apple, much less a Google or Facebook, into 50,000 smaller businesses.
You don't. Big companies are not going to die out overnight. They'll still be there, they'll still be strong and important, they'll still provide utility and commodity services, but the Big Companies of the mid-21st century might have 3000 employees instead of 25,000. So where will those other 22,000 go? Smaller companies. They'll be more independent.
There are a lot of problems that can be solved by technology but require some "niche" competence. Take the emerging field of data science. Machine learning is very powerful, but domain knowledge is still key. There are thousands of domains that are going to be needing what's currently a very high level of data competence (not big data, but smart data for sure) in people who also understand their problems. That makes room for thousands of lifestyle businesses.
It's possible that market dynamics will change in a way that favors small businesses over large corporations. Is it likely? You have not convinced me.
Google needs thousands employees in order to run the infrastructure that maintains its current scale, and in order to develop the features needed to keep its competitive edge. Fifty employees is not going to cut it.
It is conceivable that it could be run with, say, 5000 employees instead of 50000. It is possible that the additional 45,000 employees are basically unprofitable, executing vanity projects to give shareholders the impression that Google is innovating in new directions. If that is the case, as programmers we should probably be thankful, because that money is going to bid up our salaries, rather than being paid back as dividends to wealthy shareholders.
In other words - even if businesses could be run much more efficiently - the beneficiaries would be the shareholders, not engineers. Only if the shareholders used their extra dividends to buy more software would it balance out to engineers. If Google suddenly became far more efficient, fired 90% of its workforce, and paid dividends to shareholders, that would not magically create a market opportunity for 1,000 new small businesses to pop up. The new jobs would be in whatever the shareholders getting the dividends choose to spend their money on.
This line really hepls me crack the code for me
They want engineers, programers, etc. with huge experience and paying a little. Just yesterday I saw a news article talking about the lack of car mechanics... and they say (like it is a great thing) that salaries go high as $450 bucks a month (40h per week)... they don't understand why nobody wants to be a mechanic :P
I haven't got any statistics to back it up, though, it's just a general impression.
While there were startups, there was not the froth of new ventures that there is today. Finding a job was very much word of mouth, newspaper classifieds, and head hunters, not the easy searching of Craigslist of today.
I don't like this phrase "shortage of engineers". What there is a shortage of is engineers who will work for the shit salaries these companies want to pay. Labor is a market like anything else. If there is more demand than supply....
There is one difference, though - the opportunity to learn programming (actually, to learn most things) has exploded in the past few decades. In 1969, I think you needed access to expensive technology (like a mainframe) to have the opportunity to learn. Now, a few hundred bucks and a web connection gets you started. So if someone wants to be hired into a programming position with no experience in 2013, that does say something about the candidate that it didn't say in 1969.
I don't blame the foreign workers, I blame the employers who undermine the value of our engineers to benefit their own bottom line.
In the UK this business mentality is rife. You're always seeing it plastered all over the news.
"Students unsuitably trained"
"No skilled workforce"
It's all down to greed and margins which are the two main problems with the "business leaders" as the news describes them as...
I agree it's better to hire for talent (or aptitude or intelligence) over experience, but sadly in the United States these days that is pretty much illegal. So how much of "hiring for experience" is HR departments not knowing any better, and how much is it their better knowledge of employment law and not wanting to be sued?
"One thing that's worked well for Stripe is bringing on people who didn’t have an immediately obvious role in the organization. If you can think of one thing this person can do, then there’s probably ten more you're not thinking of that he/she can do two months from now. Focusing on hiring to fill a role could make you more likely to sacrifice quality just to get someone with the right skill set."
http://firstround.com/article/How-Stripe-built-one-of-Silico...
The people who will understand this figured it out long before they were in a position to hire other people. It's just obvious and is repeated so much (don't hire for specific experience) that it is a cliche.
The people who don't get this will never get it, even if you paste stickers that say it on the windshield of their car and whisper it in their ear as they fall asleep each night.
So it's all great to repeat this for the 3 newbs who joined our community in the last 5 minutes and haven't heard this 80 times already this week, but it shouldn't be on HN's homepage.
https://news.ycombinator.com/item?id=5227923
and the tl;dr of the FAQ is "If you are hiring for any kind of job in the United States, prefer a work-sample test as your hiring procedure. If you are hiring in most other parts of the world, use a work-sample test in combination with a general mental ability test."
"Reasons for being selective when choosing personnel selection procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and Martin Kleinmann backs up this advice:
"Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure."
http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/prepri...
All the points made about years of service not equaling ability are absolutely proven, yet ignored by many - I'd rather work with someone who can break problems down, ask the right questions and think logically - as opposed to someone who can force a program to work because they know the syntax. Some of this is how candidates are interviewed too - technical screenings alone rarely find someone who is good at software development.
Writing a syntactically correct program quickly, is the not the same as writing a good piece of software.
It looks like I might finally get a job as a Django/Python developer after 3 years of unemployment. Encouraged by my local course for unemployed, I visited the company personally and handed them a dead tree CV and cover letter. I was mildly amused to find they seem to be just 3 guys in small dusty room. I ended up on a job interview of sorts I wasn't prepared for. It ended with a talk about games, Fallout and Counterstrike were mentioned. The best part for me, I got a homework assignment to test my skill.
A Polish co-worker from my former job in Cambridge went back to Poland, and now `tele-commutes' to Cambridge. He's doing Haskell.
Also maybe print it in an unusual size -- that way they can't file them away for "maybe later" as they won't fit and they are forced to have the CV on their mind. An unusual color might also prevent it from getting lost in the stack of resumes.
Even after working at the company for almost three years, I wasn't technically qualified for any of the job postings on the site. I had friends who didn't apply just because they didn't have all the skills in the "required" section of the job posting.
Luckily, the developers in charge of interviewing and hiring people seemed to understand that hiring someone smart was better than hiring someone with "experience" in random technologies.
Obviously, the best case scenario would be for companies to deduce who will have an affinity for certain technologies before they actually use them, but that's too complex and involves the type of decision-making to which HR departments are averse.
I spent some time about a year-and-a-half ago building up and managing a small internal development department at a mid-size corporation. I was involved in finding talent to fill development roles in the company twice. The first time, I sat in on an existing search and interviews for a role in a different department. The process could not have been more broken--the position had been open for roughly one year, and the interviews yielded no hirable candidate (as judged by the individuals making the hiring decision). The second time, I led a search for positions freshly opened for my department. The process could not have been more smooth--three strong candidates were hired within three weeks. The only significant difference between the two hiring pushes was the approach--the first was focused entirely on a candidate who had n years of experience on platform X; the second focused on candidates who showed the greatest talent and aptitude in previous professional and personal projects, and gave the greatest indications they were a great fit for the personality of the team.
After we completed our hirings, the VP of HR pulled me aside to mention she'd never seen anyone conduct interviews like we did (she sat in on a couple after hearing about how we'd done the first candidate interview), and was impressed by the way the candidates responded in the interviews. She could "feel" which candidates were going to be hired, even though she had no knowledge of software development. We discussed the differing approaches between hiring for talent and hiring for n years of X experience. She intuitively understood the difference, but had not ever seen it in practice as intentionally as we pulled off.
Programmers understand this. Small businesses who are predominantly programmer-driven or -dependent understand this, too. Even big businesses who are primarily technology-focused show signs of getting this as well (a recent round of interviewing with an Oracle company surprised me with how much they were focused on the right things).
The proverbial dragon to slay here is the HR departments, managers, students, and training programs lacking this advice as fundamental practice. Perhaps we need to see more process-oriented and manager-level technologists joining up with HR professionals to advance the point. Maybe HR departments and educational efforts could start creating Developer Advocates to assist in crafting better approaches and more finely tailored practices to support development/engineering talent. These might be the vanguard of producing better job descriptions and interview processes to hire talent that is more competent, productive, dependable, and retainable.
The most important lesson I learned when I worked with a formal HR department to hire new people is that they care. They really do. They don't want to hire terrible candidates who are going to be miserable, hate their jobs, and drag down a team. They want to empower people to improve professionally while taking care of a company's needs. We need to start working with and spreading this advice among the HR professionals who will increase their value to both companies and personnel by including it in their standard procedures.
[1]: https://news.ycombinator.com/item?id=5441337
[edit: forgot link & punctuation error]
I'm a computer programmer, but I also do recruiting for a company in Amsterdam and their approach is most definitely "talent". A typical question is "given two arrays, find all the elements in one array that are also in the second array".
Most people come up with the standard O(n*m) "two loops" solution the first time (for x in first, for y in second, if x == y ...). The company might let that slide as interview nervousness and ask if there's a way they can do it faster. They completely understand if your programming background is different and asking "trivia" questions about a given language or requiring you to check some tech boxes is silly. You just have to be competent.
Sadly, most programmers aren't competent. If they tell me they're comfortable with OO programming, I'll ask them to define OO programming for me and then I squirm as I listen to them. But then gems show up and I have a lively conversation with someone who really knows their stuff and we offer them a relocation package to Amsterdam.
Helping people live their dreams like that is really awesome, but I couldn't do it if I was forced to demand that programmers check off boxes on a form.
(Relevant side note: I've routinely worked for companies for which a knowledge of UML was "required". I've never used this in my professional life)
I'm wrapping up my thesis here in Singapore now, and i'll buzz you when i'm done: it would be an awesome experience to interview with shops that emphasize on core CS concepts rather than some arbitrary piece of tech:)
Everyone doing hiring thinks they are the smart exception and everyone else is stupid.
I apologize if I came off sounding like this. It certainly wasn't my intention. I just wanted to suggest partnering with and moving these types of discussion into the forums where they'd be helpful--those sources used by persons involved in and responsible for hiring decisions.
I didn't mean to imply this was HR-dept-specific, or that small startups did not have the problem. I was just using that as shorthand for 'professionals who are responsible for hiring'. Maybe there are enough of them reading HN, but I'd also bet they rely on mgmt/hiring advice from other channels, as well.
We say hire for talent as though talent is self explanatory. I don't think it is. Maybe we generally feel like we know talent when we see it but that's not satisfactory advice if what we aim for is to give advice to people who struggle to hire good people. If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition.
Absolutely true. A sibling comment[1] mentions an approach that is a bit closer to what I'm getting at. I personally hate trivia-ish questions when I've been interviewed and have attempted to eschew them when I've interviewed/hired. I try to focus more on questions that give me an insight into how a person thinks. So, I tend to refrain from asking definitional questions, and instead, opt for questions that can't be answered with a parroted statement of "X is like Y for Z."
> But could you define talent?
Heh. That's so subjective, isn't it?
I try to gauge talent in programmers by listening to how people reason through problems. Generally speaking, I look for the ability to confidently walk through how they'd approach identifying and resolving a bug in a software package they know nothing about (say, because they've just been brought into a product team with a 2-yr-old codebase), or how they'd tackle architecting a complicated data-heavy backend, or what kind of pitfalls they'd be mindful of in defining UI/X for a mobile application, etc.
I am wary of developers who start talking about programming languages and frameworks as solutions to higher-level, abstract concerns. That is, given the problem of integrating systems X and Y, hearing Ruby, Python, Django, or Lift as part of the solution before it's appropriate to discuss a stack. I'm also very circumspect when new developers join a team and advocate for technology/language/framework X to solve problem Y, when X is the thing they used for n years before joining the team.
I also try to tease out a person's decision-making abilities. This has been a much more difficult talent to assess. I've seen a lot of inability to assess a problem and summarily decide how to appropriately move forward--that is, the kind of person who gets too bogged down in talking through a problem, and is unable to make a decision on how to actually get started solving it. I've found a team is highly unproductive when there isn't at least one person who is able to codify the team's thoughts on a problem into a pragmatic approach to get work done--especially when they lack management figures who know enough to help make informed decisions.
> If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition.
Certainly. Which is why I suggested a better approach is to focus efforts on those who are in hiring positions (be they HR professionals or otherwise) who could use the help and input of someone who is able to confidently identify talent.
It may sound squishy, but it's really not. You can tell smart people pretty quickly from talking through logical problems with them. Dumb people will ask irrelevant questions and want you to hold their hand and walk them through it. Smart people will ask smart questions and deduce a path to the solution.
As it says in the article, 5 years of experience for one person might be the same as 1 year for another.
To solve the problem, we need to borrow an idea from RPGs: experience points.
Find me a child prodigy genius who didn't come from a well to-do family who paid for tons of tutoring. Find me one from a slum. (hint: you probably won't find one)
> Without a degree, he left college and continued to pursue independent research in mathematics. At this point in his life, he lived in extreme poverty and was often on the brink of starvation.
"Brahmin" are the elite hindu upper class.
I would credit you with contradicting me but you haven't.
However, that's a pretty interesting link. Thanks for sharing.
-- no formal training -- developed his own mathematical research in isolation.
We're talking talent here, upper class or no. Talent is talent ,even when it is not discovered. In this case ,it was
How much of an average developers time isn't CRUD? How do you get the experience to do other things[1] unless you needed them for that one off project?
1. Unless you are talking along the lines of specializing in something idk what these things might be.
My biggest issue is with confidence. It probably shows in interviews. I know that given the chance I can do just about any work (some might take more time but I am willing to put the effort in).
One of the other threads recently was about questions during interviews. I learned that there are a lot more things I should be asking about that I wasn't.
I have 6+ years experience now and am going for senior dev roles.
4 of those years are PHP and I feel company's and recruiters pidgin hole me as a "senior php dev".
I feel like I have to continue down the php stack + web dev path or take a pay cut even though I have non professional experience in mobile for example.
I understand where they are coming from but a little less narrow mindedness would be nice.
-gets ready for the 'no one other than a php shop wants to hire a dev with most their experience in php' jokes-
A trend these days is using interests as a predictor of talent. Most of my clients (recruiter of engineers) could see two identical levels of professional experience, but if one of those candidates is writing Haskell at night that is the one getting the interview. The intellectual curiosity and interest in complex subjects seems to be an indicator of ability and/or talent. This could be something easy to teach HR and recruiters, and I always ask candidates about tech hobbies or "What do you run at home?" to get some insight.
Most below average engineers are probably not assumed to be researching complex concepts in their spare time.
To think that companies or individuals will not continue to use experience numbers in evaluating talent is overly-optimistic, but I think judging based on interests is becoming a useful means.
Putting something too generic (e.g. intermediate programmer, mid-level, etc.), you tend to attract a lot of non-relevant, hello-world sort of people.
Putting a laundry list of language features? You are afraid you could unwittingly weed out people you want, let alone the first person to complain would be the recruiter in HR.
Most hiring managers, myself included, just use years of experience as a guidance so that the candidate can get a feel of the expectations. I did hire candidates with lesser experience but with good technical competencies. Therefore there is no harm to try if you are confident you are a good fit. In fact, I will be really impressed if someone can sell and market oneself intelligently. Surprise me!
If someone can sell me his/her story in the cover letter and resume, I follow up on that in a phone screen. I'm still looking for more proof of someone being "passionate" (overused term but often part of HR doctrine) and showing that they grow and grow and grow.
This has never made any sense to any recruiters I've worked with and has sometimes been a hard sell to others when I wasn't the hiring manager but I honestly don't know how else to screen for "has a lot of potential but maybe doesn't know our stack yet".
I'd love to hear how other people do this. I'd especially like to hear from someone who doesn't focus solely on what's in someone's Github repos.
What I do is to express a narrative in each job, showing how I did stuff that made a difference. I'm most proud of this ending to a sentence in my resume: "[my work] provided half of company revenues and enabled another quarter (out of $5 million for FY92)" (it did go along with some demanding work, technically, and human factor for GUI/workflow).
First of all, our tech stack looks like this:
Java/Spring(MVC)/MyBatis/Hibernate/etc
Ruby/Sinatra/ActiveRecord/etc
JavaScript/Angular/etc
A bit of SQL (MS)
We look for candidates of all skill levels who have experience with any "systems" programming language (Java/C/C++/C#) and any scripting language (Ruby/Python/JS).
Once we've found a candidate that has any level of experience with both a scripting and systems language, we send them a small coding project. The coding project is very easy. Any experienced programmer would be able to solve it in about an hour. We tell the candidates to solve the problem in any programming language and that the goal is to show off problem solving, testing and design skills.
Once we've received the code, we review it for the above stated qualities with an emphasis on clean, readable and well-tested code. We're not too hard on these code reviews, we just want to try to eliminate obviously poor fits. People who write no tests are immediately eliminated. Hugely over-architected solution? Eliminated. Code is bad enough the person might not actual be able to program? You get the idea.
Once the person has passed this stage, they come in for an in-person interview. They are asked to bring their laptop. When they arrive, the dev manager will show the candidate to the room where they will be interviewed, talk a bit and then come get two developers for a coding interview.
The coding interview is somewhat on a per-candidate basis, but fundamentally the two interviewers will review the code beforehand and find places for improvement. Improvements might be refactorings to make the code cleaner or new features if the code is particularly well-written. We first have the candidate give us a code walk-through and explain what's happening, thought processes, etc. Then one of the interviewers will pair with the candidate for a while and switch out with the other interviewer after a while.
The whole process thus far is an attempt to, as closely as possible, simulate what it would be like to work with this person on a real task. No writing quick sort on the white board. Writing code, at a computer, with an IDE as a pair. Google stuff, whatever your normal workflow is. We just want to know what it's like to work with you.
After the pairing part of the interview, we do a more informal group interview with the rest of the team. We're currently 7 people counting the development manager, a scrummaster/QA and a PM/QA. So the group isn't too big. This is an opportunity for more high-level and philosophical questions. "Why do you want to work here?", "Anything in particular you dislike about Java?". Maybe if they're more senior, I'll have them explain OOP to our designer to see how well they can mentor. At the end of this section, we open it up for questions from the candidate.
So far we've had particularly good success with 1) not wasting our time with people who can't code, can't test their code or are poor at designing the structure of their code; 2) finding good cultural fits - if someone doesn't like pair programming or TDD, we'll be able to figure that out as part of the interview; 3) not arbitrarily eliminating people because they didn't study their CS textbook ahead of time or aren't comfortable writing syntactically correct code on a whiteboard.
Our dev team is even smaller than yours, and we also spend a lot of time getting to know developer candidates, of course. We've found it helpful to assign a programming project, but usually one that takes around 20-30 hours to complete. We like to pay them market rate for this work because we are busy with our work and personal lives and know they probably are too, plus we often try to give them a module we've been meaning to get started on, so we actually plan to incorporate their work into our codebase. It seems to be a very unique experience for developers applying to our company, and so far it's been very successful.
For a code interview I can see myself over-engineering a solution even though my day-to-day coding style is all about flexibility and readability. In my mind being able to over-engineer shows an ability to code.
Huh, very mixed feelings here. My gut reaction is to reply that "it also shows poor judgement", but there is some truth to what you are saying. The middle ground would be where you can actually explain what you are trying to achieve with the over-engineered bits.
I once made the mistake of over-engineering a coding test by , among other things, writing and invoking C code from a Java web application. While I thought it would communicate enthusiasm by going above and beyond, it in fact horrified them and I never even heard back.
Lesson learned.
However, yes, the C code was more performant than its ruby counterpart - though within the context of the coding challenge it was fairly negligible.
The problem with this question is that many people won't answer it honestly. A lot people just want to get, say, a better salary, but instead will answer stuff like "I want to solve difficult problems" etc.
Why would you need dedicated test code for a project that can be completed in an hour? This is definitely TDD-specific and most programmers would not do it.
Writing the code in an "unusual" language, would net big bonus points, though. I get tired of seeing the same solutions in Java and Python.
Age and maturity. Most people didn't even finish high school and started work at about 15. "5 years of experience" meant you were getting a 20-year-old-- likely, for a working-class male before 1960, to have settled down and gotten married, and to either have a child or be planning to have one.
A better analogy would be tradesmen. Apprentices worked under journeymen or masters for five or seven years before themselves becoming journeymen. A tradesman or craftsman works on projects or repairs, each one different from the last.
The years of experience aren't all about banging a hammer against a chisel, or tightening nuts onto bolts. Those years of experience are about problem solving; functional problems and non-functional. Not only do I have to deliver the product requested with quality and budget and timing, but I have to solve all of the problems that have nothing to do with the product but everything to do with its delivery: What if it's really cold on one day and someone doesn't turn up for an important presentation? What if one of my tools breaks and I have to improvise? what if the product specification changes halfway and I have to figure out how to implement that (or reject the changes) without causing a fight? What if local regulations change mid-project? What if technology changes a year or two after I start, and I have to learn something new to keep up?
These are the things an apprentice learns in seven years (for the last couple of thousand years), whether a plumber or a mason or carpenter. The best person to solve a series of such disconnected problems is someone who's been in the trenches and dug their way out. You don't get that from a book or from your bedroom.
1. A degree. While degrees are nice and prove somebody is considerably "intelligent" and not a "complete waste of time", many talented programmers, especially the ones you want to hire; are fully capable of teaching themselves without a lecturer.
There are some developers who have already studied the dragon book and have a sophisticated understanding of how operating systems work because they hack on Linux.
A developer may make a very reasonable and logical decision not to go to college because they dont want to accumulate debt, for an education they already possess, and ultimately waste time not working on their software projects.
A degree doesnt mean they are a good programmer, and a lack of one doesnt mean they are a bad one either.
Im not saying college is a bad investment, rather recruiters should not turn away an applicant just because he passed on that, as they see it, inherently flawed "life experience".
2. Years of experience. Assuming the project is well documented... If it takes a developer longer than 2 weeks to figure out how to use a project's api, even if they have no prior understanding of the technology.
They are not a good programmer.
If you are looking for a developer to actually understand the internals of a project well enough to be able to commit, even linux shouldnt take 5 years of studying before a talented developer is able to visualize whats going on.
Real developers spend almost all of their time reading code and studying something they havent learned yet.
if they cant adapt quickly to your projects, while perhaps even teaching themselves the new technology along the way unbeknownst to you. (new programming language, library dependency api's, network protocol, etc)
They are not a good programmer.
3. Previous Work Experience [as {insert stupid job title here}]: First, there is nothing sillier than job titles for programming positions. The only valid titles that should ever exist for a programmer's job are Hacker, Bit Composer, Code Poet, Git Wizard (seriously, this is the only valid specialized hacker position)
Second, Just because Bob has 30 years of work experience as "Lead Programmer" at "FooBarly inc.", that doesnt mean he is a better engineer than 21 year old, no work experience, Alice.
While Dino Bob may be able to write optimized, neat, software. And although he might able to debug rather complicated bugs, and ultimately lead a team to write a program that does what its supposed to.
Alice may have been an exceptional, innovative, and disruptive programmer who could have not only written the software but innovated the concept into something beyond the scope of the original concept design.
There are some hackers out there who can see data structures and algorithms like a painter can see the scene painted on the canvas before they make the first stroke. Innovation requires an exceptional level of creativity and the ability to abstract an opaque idea into a deep, detailed conceptual model.
People cant be taught to think this way. Much like a professional musician, whom despite practicing each day for hours to perfect their art; will always lack the skill of a virtuoso mind like Mozart. Many people are great engineers, but could still lack in talent against someon who was just born with an exceptionally creative and brilliant analytic mind.
These are the kind of programmers that you cant afford to let your competition snatch up. Yet you just foolishly tossed Alice's resume in the trash because Grandpa Bob has credentials and she doesnt.
Interview Quiz: When given questions like, "given two arrays, find all the elements in one array that are also in the second array". in attempt to talent scout.
A good programmer will claim the real right answer is either the obviously simple choice or the theoretically most efficient, and well tested sort algorithm that can be found using google.
If comparing two arrays is seriously a performance bottleneck that requires optimization, you might as well skip the bs and go with the best. We arent solving problems if they no longer exist, and a programmer not solving problems is a programmer wasting time.
4. Portfolio A portfolio is the only valid option to consider when you want to be absolutely sure you hire the best developers.
If the person hiring cant identify what good code is, then your startup is screwed anyways. You dont need a degree to build a portfolio, and if somebody does choose to college they get to build their portfolio as part of the class projects.
If a developer doesnt have a portfolio or if the software in their portfolio doesnt actually do anything useful then you know they arent a real hacker.
Hiring a programmer should only ever be based on the quality of software they have authored.
Like Linus said, "Talk is cheap, show me the code".
If you don't mind me asking:
1. What proportion of the programmers without a degree you think fall into the "talented" category, compared to those with a degree?
2. Do you consider yourself to be in this group of talented programmers without a degree?
Previous projects, personal github experiments ... Most capable programmers will have something interesting to show.
Right?