I'm going through the interview process this week at two different companies. One of the companies I found through an ad on Stack Overflow whereby they publish two programming "exercises/puzzles" with the opportunity to earn $100 for a correct answer to each puzzle ($200 total for two correct answers). While I spent more than eight hours on both puzzles, I found them to be thought provoking and I learned stuff in the process so I don't feel like I wasted any time and I got a check in the mail for $200. My code was reviewed by their dev staff so they had immediate feedback on my programming ability and high confidence to bring me in for an on-site interview. I like this process and consider it worthwhile.
What these companies have successfully done is weed out all the great devs who value their time very much. Those who are desperate for a job will spend the 8hrs it takes on these silly tests and make it thru the process. Good developers who can take their choice of jobs will just ignore these companies who think they are being clever to require a test, and just move to some other company what is not showing signs that they will be a pain in the ass to work for. IMO, the more difficult the interview process, the more of a pain in the ass the company is going to be once you're hired. If an interviewer is not capable of determining my knowledge level by a normal interview that tells me right away something up, and I probably don't want to work with them because they aren't too smart themselves.
So you basically dismissed all of Google, Microsoft, Facebook, Amazon - all of them. Because, guess what, they all want you coding, sometimes on a computer, sometimes on a white board.
And no, they can't determine how awesome you are based on a normal interview process. Nobody can.
I've interviewed people with "20+ years of industry experience" who will swear up and down they can hack the Linux kernel but then can't reverse a string in place or write a function that determines if a word is a palindrome or not.
Having someone write some code, any code is meant to weed out those muppets. Just show me you can actually write a loop. With an 'if' statement somewhere. Please. That's all I ask. You have 15 years+ experience with SQL server? How about a simple JOIN statement? Please?
Now, companies like Google take that too far and I'm 99% positive that the day-to-day job for more than 19/20 people who work there does not involve suffix trees or reverse-printing a linked list through recursion or implementing a stack with two queues, but those are meant to shrink the pool of potential hires from the thousands to the dozens. Nobody wants to sit through a normal interview with thousands of people, better to stump most of them with idiotic, useless quiz questions and interview only a few dozen in person. I get it.
I think interviewing for software jobs is horrible everywhere, period. We just have no way to determine if someone is good or not - you can put anything on your resume and it's hard to verify and compare/contrast with other candidates.
I believe the solution is to hire someone temporarily for a few months on reduced salary/benefits (which would still be considered an amazing deal for 85% of the work force in the US) and see how they work out - can they actually produce? If so - full time, if not - bye.
"What these companies have successfully done is weed out all the great devs who value their time very much."
That's a feature. They get the good, undervalued talent early.
"If an interviewer is not capable of determining my knowledge level by a normal interview that tells me right away something up, and I probably don't want to work with them because they aren't too smart themselves."
News flash, all companies are horrible at determining knowledge level by a "normal" interview. The only ones that have a hope are those that use some sort of test or have existing work to review.
"If an interviewer is not capable of determining my knowledge level by a normal interview" -> So it turns out that mostly, no, you really can't, even though you think you can.
Ah, yes, loyalty to a company. Because a modern-day public company would never stab its employees in the back or lay them off if Wall Street was unhappy, right?
What these companies have successfully done is weed out all the great devs who value their time very much
I'm not sure I understand this. A dev who valued their time very much would already be working at a job they liked enough not to be looking. As job satisfaction declines, time opens up to work on whatever you want to call this, a technical feeler, perhaps. A dev who values their time wouldn't get snowed under by a ton of these because they wouldn't be applying willy-nilly, only to those places they want to work.
Not for those of us who have experienced the pain of terrible management and burnout caused by this. The last search I did I was also working 50 hours a week under very poor project management. I had to rule out any prospects that involved meeting with recruiters or these screens. I got a job I liked.
Not actually all that hard to understand: yes, lots of talented devs who hate wasting time have a job they like. However, N is a big number here, so your assertion on that fails.
Also, your assertion that "as job satisfaction declines, time opens up" also does not follow. Plenty of very talented people are both unsatisfied and snowed under with crap.
Finally, saying that a Dev wouldn't be snowed under because they wouldn't be applying willy-nilly would hold iff hiring practices at firms where even remotely efficient and fair.
There is a selection bias here as others have noted, the exam is likely biased in favor of younger, unmarried workers, especially those without children who have 2-8+ hours to spend on top of their other commitments.
I applaud their decision to pay for correct answers, as it balances the "cost" bourne by the applicant and employer. Employers who send out tests en masse have an asymmetric advantage -- they can force many candidates to incur a cost without incurring much or any cost of their side. This causes bad behaviours.
Traditionally in interviews, companies "paid" with their time, but online exams skewed that. Paying something per correct answer at least makes them think twice before inviting hundreds to the exam that they have no real intention of ever interviewing.
To be fair, younger workers will usually have less of a professional network; older workers will usually have more of a network, and are more likely to have open source code that's reviewable.
It's all just ways to filter. If I can filter you through our mutual network, I'll do that - if I can't, open source code; if I can't, coding test.
The flip side of this is that not everyone has the luxury of that much free time to focus on puzzle-type exercises just to get a foot in the door. This process seems to select for single people with a good amount of free time, which, depending on who you ask, is possibly what they want (if e.g. frequently greater than 40hr work weeks are expected).
Edit: thinking more about this, it's good to see that it's a paid puzzle, so even if you don't get an interview, you are still compensated for your time.
I understand your concern but you are actually talking from a privileged position. Its not really that hard to take a bit of time out of your evening or weekend to do some online programming exercise - IF that is the only thing that companies want. Anecdotally speaking I had to do these types of things while working full time to pay the bills.
Having a broader perspective - its maybe only in programming that the hiring process is so much easier. For almost any other job you need the right technical skills, years of expensive schooling, unpaid internships and have done a lot of networking ( cough nepotism cough ) - its only in programming that raw skills can get you anywhere.
> its only in programming that raw skills can get you anywhere
Simply not true. Maybe there's a few exceptions, but in general, most companies (especially in tech - just check out our great diversity :|), filter based on arbitrary things like 'school', 'specific # years of technical experience', and other flavours of the day.
Example: I had an interview with Mozilla many years ago, where the first question was, I kid you not, "Are you a Javascript rockstar?". I said no (being truthful - I was naive back then), to which the reply was an immediate "Sorry - bye".
> its only in programming that raw skills can get you anywhere.
The skill of programming is more like carpentry, mechanic, heavy machinery operation, or machining. I'm not going to higher a carpenter that can't tell the difference between a hammer and a saw, and I won't find a machinist useful if they can't run a lathe.
We need to start thinking of programming as a journeyman tradecraft career.
But that is exactly the strategy of the company. They want to select applicants that are young and have enough spare time to solve these puzzles. The fact that the puzzle is paid also makes sure that the small amount of cash is enticing for the applicants (i.e., young developers).
I don't believe that to be their strategy at all. It's a small company with a few devs who don't want to waste their time on junior/mid-level candidates. It's a prescreening process on both sides (me and the employer). I'm early thirties with a wife and two kids so it's not like I have dozens of hours to dedicate to that task.
A couple of months ago I did a 'homework' assignment for an interview (it involved writing a simple REST service in go, even though I have at least one personal project demonstrating exactly this skill -- to an even greater degree -- in my github profile). During the phone-discussion after turning in the project, the mid 20-something lead developer couldn't find anything to nitpick (I could have) and even told me he thought I was a better programmer than him. The conversation went very well and I felt confident I would receive an offer.
Now, what do you suppose happened next? I never heard from them again and all of my attempts at communication were ignored. I'm starting to think my age is becoming a factor (mid 30s) -- and also these kids have no sense of respect and professional courtesy. I'd like to say this was an isolated incident, but that would be a lie.
Stupid me just spent his Saturday doing another such project, though at least this one presented a more interesting problem. I swear, if I find out I had my time wasted again I'm going into consulting. Or maybe I'll go to truck driving school. Or open a cafe. Screw this "employee" stuff.
The fact that so many employers treat candidates like this tells me that the whole "it's hard to find good developers" line is a lie.
> The fact that so many employers treat candidates like this
Don't give up. Most established companies aren't run by 20-somethings. If the seniors are already in their mid-20s and lack professionalism, then most likely there are other issues going on at this company. You may have dodged the proverbial bullet.
Wish I could upvote this twice! Every rejection I've ever received came with an information-rich sideband that told me more about the prospective employer than an acceptance would have. In at least half of such cases I said to myself: "phew, that was a bullet I was lucky to dodge... imagine how it might feel to work with these people!"
Often the "information sideband" is the very fact that the company decided to cut off all communication as a way to convey rejection. If they treat random people that way, how do you think they treat people who are obligated to be on their worksite every day?
Companies: DON'T DO THIS! I, for one, actively discourage smart friends from interviewing at places that treat candidates like shit.
I had nightmare of a interview experience with AirBnb in 2012. They asked me take 2 days off from work and fly all the way to SFO after I wasted couple of hours doing their coding homework. The first interviewer started with "your degree is not from a good school" like the very first sentence right to my face. He then asked me a string matching question, and insisted that I code up his brute force solution (with terrible insert complexity) and second interviewer asked me to code up a binary search tree and . After which the recruiter walked in asked me to leave the building saying the interview was not going well and walked me out of the office.
I felt so humiliated, worthless and traumatized that I stopped interviewing for atleast 3 years after that. I now have (irrational) fear of interviews.
This experience has dissuaded many of my friends from applying there.
> This experience has dissuaded many of my friends from applying there.
This should be the lesson for employers: an interview candidate who feels good about their interviewing experience, even if they aren't hired, can refer their qualified friends to your company. The alternative is that they might discourage good candidates from interviewing with your company by warning people on Hacker News about its hiring practices. Also, the candidate might be a good fit for a different position in the future.
Nowadays, at least for their engineering internships, they have a pre-filled list of top schools to choose from followed by an "other" option (at least when I tried applying a couple years ago).
That told me exactly what I needed to know. I'd be instantly rejected because of not going to a "good school".
I'd love to say "don't worry, you'll get a chance to prove yourself", but I can verify the instant rejection.
Sample size of one, but I dropped out of a top public school, immediately started working full-time x 1.5, and ended up with a resume that my now-graduating colleagues are blown away by. A few top companies (Google and Yelp! included) have flat out refused to screen me based on no other conversation than "Oh, I never finished school because _____". Hell, I interned for a large bank and received a great job offer which was promptly rescinded after the right manager found out what everybody else already knew.
It's one thing if I fail the interview process. I get that. I know I have a lot to learn. But the way some of these companies act is just messed up. FWIW, none of my independent clients care.
Hell, I interned for a large bank and received a great job offer which was promptly rescinded after the right manager found out what everybody else already knew.
Yeah, banks (and many big companies) are like that.
I hope this comment doesn't discourage others. I went to a school not known outside of the southeast (and even sometimes not then) and received interviews with many of the top companies (Google, Microsoft, Intel, Amazon, etc), even when I had to check the "other" option for schools.
Curious. What schools are on the list? Would a CS degree from Georgia Tech do? Also curious about VT and NC State. I think all three of those are 'good technical schools'.
"This applicant went to some cow-tipper school called the University of Illinois at Chicago. Claims he had as a thesis supervisor some guy named Daniel Bernstein for his cryptography project... eh, put him in the 'Other' pile. And when he turns in his 8-hour take-home, make sure it's perfect."
FWIW, someone else in this comment thread said they had interviews at top companies without going to a top school.
So don't necessarily count yourself out immediately. Take what I said with a grain of salt.
However, since they do have lists like that (they being unicorn-type companies, I think) they quite likely do use it as a metric- maybe not necessarily a requirement.
I studied Computer Science at NC State. Your experience will depend entirely on what you hope to get out of a CS education:
At some schools, the CS curriculum is focused on "pure" computer science. These curricula are packed full of theoretical CS and rigorous mathematical courses, and are great for people who hope to go into CS research or academia.
At other schools, the "CS" curriculum would be better called "software engineering." These curricula focus on programming and applied CS, giving more "practical" skills for people planning to proceed straight to industry.
At NC State, the undergraduate CS curriculum was a pretty good balance between both. You'll get a mix of both theoretical and applied CS, the downside being that you won't get very deep coverage of either. However, I feel that I was well-prepared to enter industry after graduation, and I've been pretty successful in my line of work.
Here's a small subset of what I studied as an undergrad at NC State:
Theoretical | Applied
-------------------------------------------------------------
Discrete mathematics | Java
Automata theory | C
Computability & complexity | x86 assembly language
Linear algebra | Software engineering
and some courses that offered a healthy mix of both:
Mix
----------------------------
Data structures & algorithms
Operating systems
Computer graphics
Artificial intelligence
Database management systems
Multimedia systems
Human-computer interaction
Of course, there are a lot more courses offered than just these, but this is a subset of the ones I took, along with how I would categorize them. Using your restricted and free electives, it's definitely possible to plan a degree that leans one way or the other: more theoretical or more applied, but the way the required courses are laid out, your foundation will always be a bit of both. There's also a "Senior Design" capstone project, where you're put into a small team (~4 students) and given a project from a local sponsor company. You'll work closely with some contacts at that company on a real-world software project. I formed lasting bonds with my team mates, and we still keep in touch to this day. Two of us were also offered full-time positions at EMC (our team's sponsor company), where I worked for about 2 years before leaving for greener pastures.
Another benefit of NC State is that it's in the NC Research Triangle area, and the Research Triangle Park is only about 10 minutes down I-40 from campus. RTP is home to a TON of tech companies, so there are plenty of opportunities for relevant employment, both for students (internships, co-ops) and for recent graduates (full-time work).
Raleigh is also a great place to live and work. Plenty to do, great job availability, low cost of living, and traffic is never too bad. The only downside is that the public transportation story isn't nearly as good as, say, D.C.'s (the bus system isn't terrible, though -- I generally found that I could get where I wanted to go in a reasonable amount of time, and there are connecting buses that will take you to nearby Durham (Duke) and Chapel Hill (UNC)).
I very much enjoyed my time at NC State, and if I could go back and choose a university again, knowing what I know now, I'd choose NC State again.
I hope this helps! Feel free to ask me questions :)
It might be that the list includes schools where they have visited and presented, etc. Thus they can measure the effectiveness of their intern pipeline development program. I know that is something my company does.
Might be smarter to have a "Where did you hear about this internship?" question instead and have "on-campus event" as a choice.
Its all too common. Probably for the usual reason - it works so well. Many candidates from a 'good school' have been filtered for ability, so essentially come with an endorsement. Those from other schools don't have that endorsement. They may be equally capable, but then again they may not. In fact, often not.
So, discrimination is rampant because it works so well. Its not fair, possibly not legal, but hard to stamp out.
They have a perfect right to use educational background as a filter. But that's not the issue here.
If that's the filter they want to use -- the time to apply it is before inviting the candidate to take 3 days out of his/her life to fly across the country for an interview. If it's such a huge "ding" for them that a candidate doesn't come from a certain set of preferred schools -- fine, don't invite them for an interview. It's really quite simple.
Of it's a "ding", but they want to give the candidate a "shot" -- that's fine too, but there's no need to blatantly neg the candidate right to their face. It serves no purpose; it's just uncivil and unprofessional. (No purpose, that is, other than to give the interviewer an ego rush, and thereby provide a temporary defense of sorts against their own very deeply rooted insecurities. That, and to basically deep-six the candidate's performance, and nullify whatever enthusiasm they might have had for Airbnb during the rest of the, by that point, manifestly pointless "interview").
And the fact that such allegedly highly educated people would so quickly resort to numbskull behavior like this suggests that maybe's it's not such a good filter, after all.
This x1000. Well said. I've gone through the same thing: at one place, for the third(!) onsite, I got to talk to the CEO, who said, "Well why the heck should I hire you, given that [part of history]?!" -- something that had been discussed with each interviewer over the previous two rounds. I wanted to find a diplomatic way to say, "I don't know if you're just probing my ability to sell myself, but if not, and this was such a dealbreaker for you, it might have been a good idea to resolve that before taking me through three onsites, you know?"
If that [part of history] was a brush with law, taking time out to deal with personal problems, or being caught up in a failed business endeavor of some sort -- you can always spin it out as a learning experience, and say some variation of "It wasn't the best choice make, but I think that going through it made me a better, more mature person."
But not knowing what exactly that [part of history] was about, of course we can only speculate.
Nothing at all like that, and I had no problem applying anywhere else. The point is, they shouldn't send you through interviews when they can know they're not going to hire you anyway. (In the context, it seemed like the CEO was just trying to make himself useful by feeling out each candidate for what his gut told him. Whenever I asked him to clarify a question, he would refuse to explain at all, and just say "whatever you interpret that to mean".)
Hmm -- I'm not you, and I wasn't there. But something tells me you're looking at this (retroactively) as a "glass half-empty" thing. As in: "they must have seen some big negatives in me, otherwise they wouldn't have asked that question, about [past history]."
Whereas you could have also looked at it this way: "They must have seen some big positives in me, being as they asked me to come talk to them, knowing full well about [past history]." You know, the glass half-full route.
You're talking about this like I'm some charity case. Again, I don't have trouble finding interest or applying elsewhere and I don't depend on anyone seeing enough "goods" to take a chance on some bum.
I was an internal referral there for an ml position. They rolled a fucking front-end developer who had never looked at my resume into my first interview just shy of 25 minutes late. And yes I'm sure about the time, because I was walking out at 25 minutes. Dude was nice and we had fun chatting (not about work, just a cool outdoorsy dude), but we had nothing in common in the work we do. I finally talked to one of their ml people and absolutely nailed that part of the interview. And talked to a weird founder (who always asks weird questions. That were not a good fit for a quantitative person.)
They then decided they weren't sure if I wanted to work there (apparently because, you know, I'm in the habit of wasting a day of my life interviewing for giggles) and made me have another conversation with an early engineer there. Who was really cool, but still, it was a strange process.
They also low-balled me on cash, and were strange about it when I turned them down and didn't negotiate at all. Someone else offered me $20k more and I figured it was a sign they wanted me so I went with them.
> They then decided they weren't sure if I wanted to work there (apparently because, you know, I'm in the habit of wasting a day of my life interviewing for giggles)
That's not really fair though. Tons of people apply for jobs because they need a job. I've surely done it in the past. I've applied and accepted jobs I didn't give a damn crap about. I had to pay rent, feed 2 kids, and pay my wife's tuition. And even did so with multiple jobs at the same time. Anything else was secondary. I went into interviews, praised the greatness of the ideas of some shitty startups which were doomed to fail. I always showed up prepared and was "professional" (in so far as you can show up and not give a rat's ass, but not let it show), and always tried to show I was invested by having already ideas about their products, website, etc... But still, didn't actually care for that stuff.
So, I was motivated and a good "employee", but was I a good fit? Probably not.
And, on the other hand, I also actually did interview at times just for giggles. Or for practice. Or just in case. Or to get leverage.
And when I was the recruiting, while I surely wouldn't assume that the person in front of me would be "interviewing for giggles" (at first), I can totally understand the "weren't sure if I wanted to work there". Like I answered on another part of this thread: the onus / burden of proof is on you, you are the one who has to show you really want to be there (even though you actually may not).
It's screwed up, but it's how it is, because we also work for money. I know I did often. Still did my best in any job I got though.
(And you should not expect that either, actually. I'm similarly pissed by friends or colleagues who tell me "damn it's like these guys don't care about the job or don't give it all". Well, heck yeah, why would they?)
> "I also actually did interview at times just for giggles."
Then you are an asshole. Seriously you wasted how many people's time for your own amusement? If you want practice or informational interviews there are ways to achieve those without being completely inconsiderate and disrespectful of peoples time.
It fits that you are suspicious of other people based on your own questionable practices. Most normal people don't do this however.
Giggles is not exactly the right word. I didn't make it just to see if I could pass or take a piss at someone.
I don't think anything is a better practice than an actual interview. Doing a rehearsal or workshops won't compare.
But thanks for the insult, random stranger.
Besides, if that was your only take away from my comment, I think you may have missed the main point. Maybe you were too infuriated by that point already.
And I think that when it comes to cumulative time-wasting, the culprit is usually more the interviewer (or the incompetent recruiting agency).
Also, would be interested in having data on the "most normal people don't do this" bit. I know plenty who do or did at some point, across several countries.
That sounds horrible! I have no degree at all, which means that I got exactly where my interviewers are entirely for free. No crushing student loan debt, no heat waste of having to take college classes that have nothing whatsoever to do with my chosen profession. Those who have the audacity to judge a person by their degree deserve to have this advantage flown in their faces, if only implicitly.
Just to add a data point - I interviewed with AirBnB in January 2014 and had a very similar experience.
I was referred by a college classmate and close friend who used to work there at the time, who knows me extremely well, and is easily in the top 1% of engineers I know (Linux contributor, loved by every employer he's ever had, etc.). He told me I totally had the level to work there, and was better than most people he worked with. So I went along with it, and went to their holiday parties, where one of their execs schmoozed with me for a while, told me I sounded like a great fit, and a recruiter would be in touch with me.
I talk to the recruiter on the phone, get assigned a home coding challenge. I spend a Saturday on it, and get a perfect score on it. I don't know if it was by design or not, but it showed me the rankings of every person who ever did that challenge. I was tied for 1st place with 40 or so other past candidates, in a pool of a few thousand participants.
I do their onsite interviews (fortunately I was local to SF) - don't remember much, except that they felt very stilted. But it was the usual "here's a canned problem I know the best answer to, you have 40 minutes to figure it out while I give out cryptic clues". After 3 or 4 of them, I sit in the room alone for about 30 minutes - the recruiter then comes to me and tells me that they won't move forward, bye bye.
My friend met me outside for a smoke, and told me he had no clue what happened. Oh well. AirBnB definitely left a bitter taste in my mouth, but I got a much better gig at a much better company a few months later, so things worked out.
The "good school" thing is an entire topic in itself. You get good and bad from any school, but from what I've found over the years is people want Ivy League or close when they want someone just. like. them. Someone that looks like them, talks like them, thinks like them. They want a person who will be a puppet for management, nothing more.
I have worked with, and currently worked with people who are amazing problem solvers and developers who went to community college or trade schools. Recently I worked with one of the smartest people I've ever known who had no college experience at all. He's so good at his job his makes over 6 figures with a high school diploma with no student loan debt.. how could you not call this person smart?
I definitely wouldn't say that people who come top schools aren't top talent, but it's no guarantee and I think it's silly when people require it.
I think just asking for a degree (in a computer-related field) is kind of a dumb idea. I don't have a degree, and I'm very successful at my software development job. The best programmer I know has a degree in Psychology; another has a degree in Biology.
From my own experience as an interviewer, "has a degree" was absolutely not even a factor when determining who was good and who wasn't.
Whoa... That sounds just terrible. What makes it especially terrible is that they already had you do some coding work before flying you in.
Something is utterly, terribly wrong with their process if the coding exercise made them think that you were worth flying in for an interview and then they cut short the interview process because they thought it was going so badly.
There are other signs that the tech leadership at airbnb is confused. Witness this almost parody of a video of their devs describing how they worked their way through pretty much every javascript hotness de jour through the years. I honestly thought this was some sort of a parody initially...
it's them that should feel humiliated. It's not like you showed up at their door right off the street; you successfully completed their take-home coding problem and i assume at least one prior telephone interview.
One thing you might not realize is that many companies ask a lot of employees to interview people, and therefore they are not well vetted. If an interviewer is terrible, chances are they don't know! Please, let their recruiting department of things like that. If they are not a terrible company, they'll probably do something about it.
Are you kidding me? This actually happened? I understand maybe feeling traumatized but really fuck those people. Its a shame that Glassdoor is such a pile of garbage there should be more of a forum for people to get the word out about such douchey and unprofessionalism. I hate to generalize but I feel like this bratty and completely unprofessionalism seem to be quite common in San Francisco and the Peninsula. I am basing this on interviews I have had and others I've spoken to. This childish behavior is not really common in other parts of the country - It's hard to imagine this happening in New York, Boston or Austin for instance.
How is user generated content "expensively-gathered"? Content comes at exactly no cost to them so yeah it is lame. The data comes from community. Have you looked at the site?
Really? Setting up the site was free? Architecting the systems scalably was free? Popularizing it was free? Getting people to give their information to it was free? Protecting it from spammers and malicious activity was free? Securing it was free? Usefully organizing the data was free? Protection from lawsuits was free?
GlassDoor didn't just put itself together one morning, or a free, open-source one would already exist.
Do you also spread the meme about "Viagra was invented by accident", as if all the clinical testing, information dissemnation, regulatory approval, chemical isolation, etc were accidents too?
This is especially hilarious^W demoralizing when the same company continues to actively recruit across all available channels. Successive waves of aggressive recruiter spam from some of my past "dead silence" rejections continue to cause hilarity^W^W rub salt on the wound to this day.
Respond with "I'd love to start a conversation about this great opportunity, but I'm still waiting to hear back from you about the interview we did 6 months ago!" :-)
This so much. No response is only really acceptable when you sent a job application, and their only communication back to you was an automated email letting you know they received it. If you were actually in communication with someone at the company, they can at the very least give you a two-line "we've decided to move forward with other candidates" message.
I've had rejection emails from huge companies and tiny startups personally written by the hiring manager. It's not that hard.
Yep. I had a company in the Bay Area fly me out for an interview explaining that they'd pay all expenses (as is common). They made me an offer and I went with a different company. They completely ignored my expense submission (they indicated how to submit this previously...basically just send them photos of the receipts and they'd send me a check) and ignored me after I let them know I was going with another offer, so I was stuck with ~$300 in taxi bills (SFO <-> South Bay gets pricey real fast in the days before Uber).
At the opposite end, I had a company fly me out and pay for expenses, and didn't get the job. They followed up a month or two later and sent a check, although by that time my address changed, so I didn't receive it, and told them this after asking my why it wasn't cashed. They sent another one and after procrastinating on cashing it (it was something like $80 worth of Lyft rides), they followed up again at which point I cashed it. Some companies are pretty good at giving a decent interview experience even if they reject you.
Yelp tried this with me, when I was in grad school and $150 was a really big amount. A friend of mine kindly offered to carry the expense report and drop it off with the recruiter when he went in to interview a month later.
Ageism is a thing in our industry. This may not be it but in other professions it is uncommon for those in the middle of their career to be applying for positions cold, there is usually an intro involved or in the case of the medical fields credentialing does this. As engineers we have poor soft skills that lead to weak professional networks (we think of our selves as mercenaries) and we don't have credentials of any sort.
So it looks a bit weird to them and the thought process is something like "this guy is talented, what is wrong with him that he's a walk on? I'm not willing to find out, pass."
As engineers we have poor soft skills that lead to weak professional networks
Yeah, I dunno. I mean, some have poor soft skills, definitely. But I would argue that engineers in many companies are simply insulated more than other groups. The biggest reason for this is that Engineering is thought of as a cost center, which has a number of resulting consequences.
Other groups like Product are exposed to many other groups (Sales, BD, Exec, Engineering) and so naturally their networks are larger and more diverse.
Sounds like a typical young startup hiring process (young mostly on the age of the company not the employees although it's hard to ignore the correlation)
More established companies will probably have 30 to mid 30 as the median age, and will have much more professional hiring process (relatively)
Also there is a saying that goes around: A's hire A's, B's hire C's
There are cases where you will be declined as "overqualified" or "no cultural fit" when they mean "will replace my job or at best make me look bad" and "too old" respectively.
I wouldn't give up yet. There are a lot of software architect positions if you have the relevant experience. Median age is higher than 30 I'm pretty sure.
But the "we don't have enough developers" is a blunt lie, "we don't have enough excellent developers" is also a lie. "We don't have enough rock star developers who are ok not being paid enough and have no aspiration to become team leads and just want to code all their career and work overtime" is probably more accurate.
"it's hard to find good developers".........who can implement a super-efficient malloc and free in a coding interview within 6 hours when applying to a CRUD/REST app job at a CRUD/REST app salary
I've noticed that your github profile doesn't even get looked at until you jump through all the standard phonescreen/homework hoops.
Even after than many interviewers look at your resume like 10 minutes before the interview there is no chance that they would read through your code on github. github as your resume is overrated.
I am curious to know if people hire or get hired purely based on their github profile without a technical interview.
* If you don't provide a link to your github profile, I'm not supposed to look at it. This an HR requirement. Other companies may use this same policy.
* I definitely look at github, but it's not always easy to tell if a project is original or not. Quite often I'm presented with either 30 forks, or a few projects that seem like they started as some boilerplate.
* Don't just provide github, also provide a specific project to look at. Even better, point out a particular section that you are proud of.
* Even with a well-stocked github, I will still ask you to code. This likely isn't to tell if you can code, but to figure out what it would be like to work with you.
It's really, really easy to tell what contributions were made to a project by the person whose profile you're looking at. There's literally a "contributors" section where you can click on them and see every commit they ever made to that project.
Also, asking someone to code in front of you is a terrible way to figure out what it would be like to work with them.
1) It's an artificial non-cooperative environment.
2) It doesn't tell you anything at all about how they present and communicate their ideas.
3) The absolute best-case scenario is you figure out one degree of conscientiousness, which isn't enough to build a working profile model of them.
I'd be curious to know if you know the personality profiles of the people you already work with, which profile framework you use, if you know what composite mix of profiles will lead to meeting your institutional success criteria, and then how you go about assessing a person's profile to fill the gaps that you have in that composite.
I over simplified to make a simple bullet list. This is not a "code in front of my while I sit in silence" kind of thing. It's collaborative, it's discussing requirements, strategies, etc. It's back and forth and suggestions. It's also open Internet and questions are encouraged.
FWIW, we follow-up on what candidates thought of the interview process and it is overwhelmingly positive. I don't think it is overly stressful. Although, I'm not sure it's possible to make an interview not stressful at all! :)
EDIT: It's simple if you think of it in terms of a single project. But, if you think of it in terms of many, most of which are no contribution or a small bug fix, it can represent a large time investment. That's why I recommend candidates point out a specific piece of code.
Well, I'm not sure how you're correcting for bias in the feedback. For the same reasons you don't think it's possible for an interview to be not-stressful at all; you also can't get feedback about that process without the bias that they're not going to want to tell you that your process might be bad.
You'd more or less need to get feedback only from people who are already happily and gainfully employed who are also close to neutral on the 'agreeableness' spectrum.
At any rate. You can remove the stress from an interview mostly the same way a therapist can remove stress from iterative therapy. By building an ad-hoc environment of trust, safety, cooperation, and goal alignment.
Hiring is probably the most important thing you can do in/for any company. It should be a time investment on your part. If you don't feel like you're given enough time to do hiring correctly, then I'd suggest setting different expectations with your leadership about how to use your time or what quality of candidate to expect given the time you have.
Seeing a bunch of bug fixes across many projects tells you a lot about that person. So rather than going into the process looking for an extremely narrow thing (like some big project they are the sole maintainer of); go into it looking for anything that's there and see what kind of information is there to help you construct a useful narrative/model of that candidate.
Lots of bug fixes across many projects may not indicate that they can own a singular vision from start to finish (though you can assess that from getting them to tell you a story about literally anything), but it does tell you that they can read other people's code, supply feedback in the way of working alternatives, will take the initiative to solve a problem themselves rather than wait for the maintainer or someone else to get around to it, and focuses on getting things working rather than design-paralysis.
My issue with the whole "github resume" thing is all my best code is in private projects because they are related to serious side projects I intend to monetize. I suspect the same could be said for any other developer who is serious about their side projects.
Exactly. A frequently under-appreciated fact. Another one is that much (complete/quality) code may be from past employers/clients, which you have no right or ability to display publicly.
>>* If you don't provide a link to your github profile, I'm not allowed to look at it. This an HR requirement. Other companies may use this same policy.
First time I'm hearing about such a policy. Can you explain the reasoning?
I don't know the specific reasoning behind it. It's not specific to github. We aren't supposed to look at any reference that isn't provided by the candidate. This includes linkedin, facebook, etc.
It's most likely an overly broad means of protecting against employment discrimination.
Considering that much of what's on people's Facebook pages is against the law to even ask about (in some jurisdictions) it's probably a wise choice. Stick to what's provided by the candidate. I provide a link to my LinkedIn page on my résumé, but nothing on it touches on areas I know would cause problems. Most of my coding is in private projects so I generally don't bother with listing my GitHub.
For example, I know that where I am it's against the law to ask if someone is married during the hiring process and that's pretty clear on many Facebook pages.
You google the candidate. You find a webpage that matches. It talks about the candidates works for the gay/lesbian alliance. You don't hire the candidate because he sucks. He sues your company, alleging that you discriminated against his gayness.
In the specific case it is probably overblown, but HR fears aren't entirely rational.
Various states have laws that amount to information about the candidates past or current conditions that should not be used for job decisions. HR is there to protect the company, so they often will tell people what they can consider. Think of it as the human equivalent of not being able to comment on crime data when selling a home.
Same here, companies don't ever look at my Github code.
I built up a portfolio partly in the hope to make future interviews easier, but it hasn't worked at all!
I remember reading that comment about Google... even though a ton of people at Google use Homebrew. The question is, what would would you be writing at Google? Would you be reversing binary trees? Would you need to instantly know which sorting algorithm would be most efficient at the drop of a hat? or would you be building more tools like you already have. The one thing that isn't immediately clear from your GitHub is if YOU wrote the code and HOW you wrote the code. I'm not defending worthless practices like asking you all kinds of CS riddles that the interviewer doesn't even remember... but I am saying that there are reasons to test your ability to reason through a legitimate problem. Because of this, I am a huge fan of this style of interviewing: "We have a problem... tell us how you might approach solving this. What resources would you use? Why?"
"The one thing that isn't immediately clear from your GitHub is if YOU wrote the code and HOW you wrote the code."
Spend a few minutes looking at the commit history and all shall be revealed...
If you can copypasta a complex project with >dozens of active users and a commit history showing that you've made improvements to it over time, I'd argue that it's hard / pointless to distinguish that from actual programming. If you can ship working code, support it over time, and enough people appreciate what you've created to use it regularly / rely on it, why does it matter if some parts are even verbatim copied from SO or elsewhere? Thought experiment: compare this to using a library someone else wrote.
That "github is the new resume" meme a few years ago was quite funny, in retrospect. People panicking that they'd never be able to get another job, as they didn't have free time to code at the weekend...
Curious what you're doing that you never have to even reference GitHub or SO. That seems strange to me in 2016, unless e.g. You're only using some language / framework / libraries that your company made / paid libraries / .NET and all the documentation and ecosystem is private.
I've attempted to use StackOverflow, but by the time I have questions difficult enough to go there they're well above the level that SO is capable of answering. (At least, not without bribing people with rep, which I don't have because I don't use StackOverflow.) So it's pretty useless to me.
As for GitHub, I've downloaded libraries from it, but I have a pretty healthy dislike of Git, which is awful, and refuse to use it for any personal projects. (I only use it at work because I have to-- in any case, work repos are of course private.) I used to have a few projects publicly available on Google Code, but now that's shut down, so there's really just nothing. I do have private repos for my hobby work.
In case it matters, most of my development is in C#.NET.
I believe usability is the most important trait for a software product, and not only does Git have terrible usability, but its designed in such a way to make it nearly impossible for anybody else to improve its usability. (Although they can improve it's accessibility somewhat-- not everybody is capable of using a CLI interface.)
And it's in a product space (revision control) where the average product's usability is already bottom-of-the-barrel. It's kind of impressive in a way they managed to deepen the barrel a bit.
I'm forced to use (struggle with) Git at work, over my objections. There's no way in hell I'd use it for a hobby project where I have a choice.
I see just sharing my opinion of Git is enough to get voted-down on this site. Oh well. Vote me down. "Person dislikes something popular!" is obviously worthy of derision.
Wait is this a thing now, "send us links to your StackOverflow questions"? If you don't ask questions on StackOverflow you might not be a good candidate? What complete nonsense. Whats next my Uber passenger rating? There is something so ridiculous about this.
We literally never hire someone without a technical interview, but we do look at github/bitbucket/gitlab/whatever code we can find the day or so before the interview. If there's something interesting we'll ask questions about it during the interview.
So far, there hasn't been one candidate that had anything resembling a portfolio online, but we don't hire all that often and i've only been doing it for a bit over a year.
It shows something slightly different than a github profile since it doesn't typically show full projects but both can show off competence pretty well IMO.
Someone with a well written technical blog or good github portfolio is definitely going to have an advantage in any hiring I do.
I'm a college senior and I've gotten interviews based on my Github activity, but still have to go through the interview ceremony. Most interviews I get start by mentioning my projects.
Never underestimate the dark powers of an incompetent HR department. Not saying this is the case here, but sure has the looks of it ... The person that interviewed was a programmer. The follow up to an interview is usually done by HR. As stated earlier, this is simply an observation I made throughout the years when being in contact with various HR departments. Your mileage may vary.
Any interview I've ever had where HR is involved is somewhere I would never work.
Last time this happened I was informed that Russian and Indian are races. Talking about my coworkers by their country of origin (I was saying how refreshing it was to work with a broad array of people in SF vs what I normally work with [white male] in Oklahoma.)
Russian is a race. Seriously.
HR employees are worthless in my experience (~35 years in the labor force).
Only worthless? You've been lucky. I have learned from my experience that HR is at best an enormous obstruction that must be continually worked around, and is at worst an enemy to whom you should never show your back.
How is this a dickish thing to say about white men. I am a white man. Having worked with 1 woman in 15 years in Oklahoma & Texas in development I worked with roughly 60/40 (men to women) developer teams in the Bay Area. Also the broad array of cultures and experiences brings different opinions to the table as well.
It wasn't intended as a slant against white men, it was more a happy dividend that I didn't realize I was missing (diversity). SF is rather diverse, but in IT competency still matters far more than gender, race, etc.
I think there is a fundamental incentives problem in hiring - employers don't have a strong incentive to treat candidates well, because either they won't need to hire again soon, or they will be trying to hire someone who really wants a job who will forgive them for bad treatment. It's a good argument for moving to a recruiter model - companies have a stronger incentive to treat recruiting companies well if they want to keep having top talent referred to them. (This idea is spelled out in this post from a while back: http://blog.hireart.com/is-it-time-to-centralize-hiring/)
> ... and even told me he thought I was a better programmer than him.
Probably that's exactly why you were ignored. The guy was scared of competition. (Maybe they were looking for a tech lead and he felt threatened by your expertise.)
Or more likely the overwhelming majority of people who think they are "A" just aren't.
Funnily enough, often people who clearly are top rate don't think so (impostor syndrome). Dunning–Kruger appears to be very healthy in development circles.
Well now you and my wife can agree on that. So I've got two people in my corner!
I'm actually a mediocre software engineer. Making an accounting system do XYZ for the 4000th time isn't interesting anymore. Doing it in Angular with all the new whizbang whistles and shit is more annoying than fun.
I'm looking at a career switch or something different. I can't keep creating the same nonsense over and over and watch IT run by people that largely wouldn't be good as managers of a McDonald's much less an entire organization's IT department.
The first way to see if a company actually understands the importance of IT is to see whether they have a CIO or a Director of IT / VP Engineering / Other less than CIO role. If they can't even commit a C role, what do you think their thoughts are on IT?
This is a great point. I wonder how many good candidates get rejected simply because an interviewer's bonus depends on him remaining the most talented person on the team?
The guy who wants to get you ignored due to potential competition is not likely to frankly admit that you are better. He will have some excuse, like you didn't use enough design patterns.
mid 30s? you're at the top of your game, mentally. I'm mid 40s and the memory is definitely a bit shot. There are other factors in my situation as well, but past 43, you start sensing it.
I can certainly still program, but interviewing...I'm tired of it. Tired of being asked picayune questions like I just graduated. Maybe I should I change my CV title from 'Senior Software Engineer'... that actually implies 30-something, late 20s. but what? "Part time CTO and dog's body for a few small startups/companies"?
I know I can do most anything I put some effort into, the relearning process is not hard. But everyone wants a warm body they can immediately plug in. I get interest due to my CV, but they want to stick me into jobs I'm too senior for. I need to figure out what to change... or tell recruiters, no absolutely not, no more front end work, ever!
well, my advice is start planning your career change now - I wish I had 10 years ago, instead of merely idly thinking about it.
From my experience on both sides of the table, 90% of the times average companies will always pick the candidate that is cheaper (that is, the one that asks for the least salary), not the one that is most skilled. So don't beat yourself over this, you simply can get unlucky when there's competition, even if you skills are sound.
Yep, the lack of professional courtesy evident in things like asking someone to write an API from scratch and then abandoning any communication with that candidate seems to be a hallmark of the 20 something tech dweeb. And sadly this behavior is now routine. It also speaks to a larger red flag - namely that the company is letting someone so short on professionalism represent the company. The sad thing is that this is so common. Its not just limited to the 20 something developer but also the clueless HR flunkie/recruiters. The upside is that you usually spot these things quite early and can decline to pursue these things further.
There are no shortage of companies that need someone your age who have been around the block and can bring professionalism in addition to a wealth of experience. Don't sell yourself short. Even if they called you back after a month of ignoring you would you really want to work for them? Probably not. Generally ding dongs like that are only capable of hiring other ding dongs(confirmation bias), hold out for working with adults. You age is an asset not liability.
"I never heard from them again and all of my attempts at communication were ignored."
Unfortunately, this seems to be par for the course these days - I have a lot of friends who complain about the same thing. It's just indicative of a total lack of professional courtesy, and you should consider yourself lucky that you didn't end up working with people like that.
Lucky, sure, but I wish there were some kind of consequences for behaving that way. Seems like there's no incentive to act professionally and businesses know they can get away with it, so "ghosting" is now standard business practice.
I am sorry to hear that and I understand your frustration. As someone else said : Keep going. And do not doubt what you're worth.
You know, the thing is there's nothing new, you're just seeing today what the illusion of the paycheck prevented you to see before. Take this as an opportunity to move your life forward : no matter how exciting your next job is, give to yourself a deadline to bootstrap a SAAS business as a nightjob and have enough customer within 6 months to - at least - replace your salary.
I agree it's frustrating - and I've been on both sides of that fence - but still... it always puzzles me when someone seems to get worked up over the fact they didn't seem to get the callback they expected even though they had been told they were probably good enough. Why do people simply forget about the possibility that someone even better showed up right after them and got the spot instead, and rightfully so?
It doesn't (necessarily) mean you were bad, or that they lied to you, or anything of the sort. It might just mean they had other candidates who fared even better.
Also, in these cases, I'd recommend you simply call back yourself. Think of it as the opposite of the judicial system (for the US and most of Europe, at least): the burden of proof is on the prosecution. In this case, it's on the job-seeker. You're the one who has to show you want the job and that you're the best fit. The company's role is to find a good fit (and to do so by using their resources in a reasonable way).
That being said, I wouldn't advise on doing "homework" assignments that are exceedingly long.
For the record, when I am on the recruiting side of the fence, I always do a phone screening first, with live coding in a shared editor. Only then might remote homework or on site coding come up, and I always tried to make sure the effort is minimal. It's hard to find something that fits all people and minds though. Try to design a recruiting scheme, and let me know how it works out and if it doesn't piss anyone off. :)
The courtesy thing is another issue entirely, of course, and obviously a lot less defendable...
>The fact that so many employers treat candidates like this tells me that the whole "it's hard to find good developers" line is a lie.
That is correct. The market is so flooded with workers that ageism is easily affordable.
You can keep trying if you want but the suggestion "it will all work out if you just try harder because the system is ultimately rational" is inaccurate and unproductive. If you glance around the work place and count the percentage of people 10 years older than you, you can guesstimate the odds of continued employment.
dfraser992 advice is, unfortunately, they way the world really works: neither ageism nor the flood of workers is going to be widely admitted to let alone addressed in the foreseeable future.
From experience and being on both sides of the table it's probably a good sign they didn't contact you.
Maybe it depends on the company, but for smaller companies and startups it's not only if you can do what they need it's if you fit in and the other employees like you and want to work with you. You don't want to hire or work with a jack ass, especially smaller teams. You could be the best developer/programmer/engineer in the world, but if no one wants to work with you, well, they probably won't contact or hire you.
It could be for the better and I'm not saying you are a jack ass. You might start there and after a month or 6 decide you don't fit in, feel miserable, and don't like the environment and decide to leave and have to go through this all over again.
Keep at it. Eventually you will find a company that wants your expertise and you enjoy working for and like people you work with. Both sides have to ultimately decide on a good balance. Technical abilities are not the only factor and I wouldn't jump to the conclusion that it's an age issue.
As an aside I have not come across any issues with age and I'm in my lower-30's. I think it has less to do with age and more to do with how your present yourself, act, work, and communicate. No one believes I'm even nearing 30 when I interview or am being interviewed for example and it's never actually been brought up or mentioned for me that I recall.
No feedback is extremely irritating, but common. I know a lot of companies are afraid to give feedback because they don't want to get sued. I worked at a startup where we did give people feedback, immediately, and they were often very surprised. Companies may reject people who are otherwise a technical match for lots of reasons - maybe there was some personality quirk of the interviewer where he didn't like you. It's also hard to hire someone who is smarter than you. And of course your unfortunate experience is just one anecdote. I hope you found another job that evaluated you better.
My current company was getting some poor candidates who passed the phone screen (the phone screen was the usual 1 hour code something in a google docs while we both look at it) type of screen. So we added a homework problem that takes a couple of hours to pull off. I found when I interviewed I had no interest in coding or following each companies stupid and arbitrary interview process. I do worry that it's too much of a pointless pain - but we have been able to reject a few people at the "homework" stage because they were just atrocious.
If someone has been a public github contributor, that should be even better than a homework problem.
One trick I often use these days is using these run-by-20-something companies as practice places before I meet the one that I really like to work for. So when it comes to the time I consider to move one, just say "Yes" to all incoming LinkedIn invitation. It worked well 2 times for me already for the last 5 years.
I've had this happen multiple times. Why would you hire your own replacement? (This is how they think.)
When they have someone hiring not based on what's best for the company but what's best for their own career goals, you know you're going to have issues.
Welcome to the world of tailoring yourself for the job. I'm in my 40s, so it gets worse. Can't wait until I'm over 50!
Maybe, we tend to put up with less nonsense though. However, that's typically beneficial to business as well. The only software engineers I've ever worked with that actually consider the costs are those that have either owned their own companies (startups/etc) or are older (and know the trade offs from decades of dealing with them).
Remote is insanity now a days, it was a reasonable market a few years ago but not anymore. There's a glut on both the supply and demand sides.
Many years ago there was a limited demand for remote work, which probably tapered the supply, but in my experience from every 3 leads you followed (granted you had the experience), 2 were promising and 1 was almost always an offer. Now a days it's more like you need to follow 30 leads to get one 'meh' answer. I don't feel it's an age issue, it's just a general market condition.
With more companies acceptance of remote work, mixed in with the "we can't find local talent" mantra, the hiring process has turned more hands-off which in turn is producing these insane hiring procedures and cycles.
To make matters worse, everything from the smallest start-up to the largest tech company is adopting the same 'exclusive hiring practices' while they sit back wait for the resumes to roll in and/or send in work samples. All of this is hands-off trying to get candidates to 'fill slots' costs them next to nothing until the final phases. But for candidates it's just a time consuming PITA.
My only advice is to treat the process as any business transaction. Try to gauge how much they are invested in the hiring process, if they are asking you for hours or days on end while they appear to invest a couple of minutes of 'human time' RUN! These are lottery-like odds of landing an offer and unfortunatly this is endemic in large companies as well as unknown startups.
>To make matters worse, everything from the smallest start-up to the largest tech company is adopting the same 'exclusive hiring practices' while they sit back wait for the resumes to roll in and/or send in work samples.
So true. I've found myself back on the market recently and what I'm finding is a large number of companies resorting to HackerRank pre-screens where they pick out anywhere from 3-6 puzzle-type coding challenges, give you an hour or so to complete them and if you don't nail them all, you're out. And that's just for the initial screening - there's no guarantee you'll make it past the N phone screens and in-persons you'll have after the initial screening.
Insanity, indeed. I hope someone writes a book on the crazy hiring practices in our industry, compared to other fields. Maybe I will someday - have to land a job first, lol :-/
>Try to gauge how much they are invested in the hiring process, if they are asking you for hours or days on end while they appear to invest a couple of minutes of 'human time' RUN!
Alternatively, give them your hourly rate and expectation that you will be paid for all work performed, including "hiring homework". That should weed out much of the illegitimate prospective employers.
I'm not sure there's a correlation between remote work and insane hiring processes. That doesn't sound correct. Also I think that lots of this ridiculous behavior is in S.F. and the Valley. There are plenty of tech companies that exist out side the confines of cliche shallow bubble culture.
> A couple of months ago I did a 'homework' assignment for an interview (it involved writing a simple REST service in go, even though I have at least one personal project demonstrating exactly this skill -- to an even greater degree -- in my github profile).
I would have asked them to look at that code and ask me any question they have about it. If they are not willing to do that I wouldn't have bothered continuing the conversation with them.
> the mid 20-something lead developer
Okay I am going to do something I don't like to do which is judge somebody on their age but a "lead developer" at around 25? Sorry but unless that person is some rockstar programmer (conceived with a copy of K&R in the womb) I find it very hard to believe somebody 3-4 years out of uni has the experience to be a "lead" at very much.
> told me he thought I was a better programmer than him.
Well that is something I guess, at least he didn't think he was God's gift to the programming world!
> Now, what do you suppose happened next? I never heard from them again and all of my attempts at communication were ignored.
Yes drives me insane. It is so fucking rude.
> I'm starting to think my age is becoming a factor (mid 30s)
Could be, hopefully not but a company that puts a mid-20-something as the "lead" developer might only be interested in getting young and therefore cheap employees.
> and also these kids have no sense of respect and professional courtesy.
Very true. That is partly why I don't think a mid-20s person can be a "lead" for much as they don't have the professional experience to lead. A lead developer isn't just a great programmer but also a great leader. Somebody for the regular staff to look up to and rely on for mentorship.
> I'd like to say this was an isolated incident, but that would be a lie.
It happens to us all. Some companies (IT and other) are shit. It is just the way of the world. Don't dwell on it too much, it is just more mental energy wasted and they already wasted a whole Saturday of your life yet were not even respectful enough to call and say "you were great but we prefer this other person". I mostly hate having that conversation (giving and receiving) but it has to be done, it is about respecting that persons time and even though you are not offering them a job you can offer them feedback so they do not walk away from the process empty handed. Sometimes that feedback is all they need to better themselves in the future.
> Stupid me just spent his Saturday doing another such project, though at least this one presented a more interesting problem.
Live and learn. In the future if you already have demonstrations of your work then ask them to look at that first and if they want to continue the process then you look at doing something specific for them. At least you seem to have found a small positive from it in that the problem was interesting :)
> The fact that so many employers treat candidates like this tells me that the whole "it's hard to find good developers" line is a lie.
A lot of the problems with finding a good dev is just finding a good employee for the company as a whole. You might have a good developer who is an asshole and will only cause issues.
Anyway just move on and forget about them. It is cliché relationship advice but you deserve better than them.
Very true but in my experience the number of under 30 year olds who have the experience to be an effective lead developer is extremely small. Yes you get some amazing 20-somethings but more often than not it is just someone who was given the title rather than a proper pay rise or similar and they took it to make their CV look better. Of course it is just my personal opinion from my own experiences.
I'm 26 and have been the technical lead on my team for just over 2 years. Yeah, I'm relatively fresh out of university, but I have 17 years of programming experience under my belt. No, I don't consider myself a "rockstar" programmer. I just consider myself someone who has been programming for nearly two decades. I'm not the best programmer who ever lived, but I do think I'm pretty good at what I do.
Yes, over half my team members are older than me. However, most of them come from electrical engineering backgrounds and have less professional programming experience than I do. There is no friction, though. They're great guys, and they don't demonstrate any sort of ageist attitudes. There's definitely a level of mutual respect and trust, and I try to foster open communication throughout the team.
Three years out of university, I got an offer to be a senior software engineer and technical lead. It came with a 50% pay raise. I'll admit I had some reservations before taking the position. What if I'm not good enough? What if I fail? The thing is, the people who hired me (I was interviewed by no fewer than 7 different people at the company, all in one day), thought that I had the skills necessary to succeed (otherwise they wouldn't have offered me the position). I took the position and I'm glad I did.
It has been the best job I've ever had. Until now, I'd never worked in an environment that placed so much trust in, and demonstrated so much respect for, its employees. There's a good bit of freedom, and the company is very good at rewarding its employees for good work. My only complaint is that the development environment is less than ideal (Oracle Grid Engine, all work done in the cloud, Perforce, SAP, lots of shitty products to deal with in the development workflow). I'm only willing to put up with that because the nature of the job (and the people I work with) is so good otherwise.
Maybe you're right that the term "lead" is thrown around too much in our industry, but I don't think it's insane to put a young person in such a position as long as they're otherwise qualified. As an aside, if you're ever doubting yourself, listen to what your peers are telling you!
27 years old lead, reporting in. Just curious if you would tell me I'm no lead material.
Now, on one hand, I dropped out and been in the industry (gamedev) for the last ten years. On the other hand, I've actually been on designer and producer positions for the first 6. But then again, on the third hand, I was programming non-stop since 8 and turned in MIX emulator (from Knuth's books) as a school project at 15.
So, may be we can at least agree that any broad statements about professional level of huge groups of people united only by their age, race, country of origin or other unrelated stuff are unlikely to be true for everyone in that group, because people are unique and deserve to be judged individually?
Of course we can agree on that. However I hope you will also agree with me in that the term "lead" for many things gets thrown around quite easily in the tech world.
What annoys me is I often see companies promote an inexperienced (due to age) developer to lead or architect or some other title when they are really not that at all. The company does it to keep the person happy [read: shut them up] with a title rather than pull out the company wallet and pay more. I know dozens, maybe even in the hundred+, people who were duped into that. Often because "it will look amazing on your CV!" or "we promise we will review your pay if things work out in 6 months" in the hope you forget about it or don't want to bring it up.
The problem I have with this is that it devalues the actual lead, architects, whatever the current trendy title is.
I look at it this way - A lead developer could be lead on a very important bit of software that somehow fits into something that could cause loss of life. If it were a structural engineer they wouldn't just be promoted to a lead architect after a couple of years in the game. Same with a surgeon or registrar or a judge or detective or ... the list is very long! Except in IT for some reason.
I do not mean to belittle anyone who is a lead developer and under 30. Good for you if you really are skilled and experienced enough to truly deserve that title, my problem is over the years I would say a good 90% of those "lead" somethings under 30 are not deserving of the title.
> However I hope you will also agree with me in that the term "lead" for many things gets thrown around quite easily in the tech world.
Hm, actually I haven't seen it. For me, "lead" has a very exact meaning: a developer who is personally responsible for code that developers people write, and has authority appropriate to that responsibility.
In my experience a lead developer is the primary contact and owner for a specific feature or program. This person should know everything about what they are lead of inside out, they make decisions on design and implementation. They are able to support members of the team that are below them. They can delegate work to those in their team. Review the work done and offer constructive feedback. Communicate their ideas and vision to those below and above them. Present their ideas and concerns to management and stakeholders with ease.
So there are a few buzzwords in that but that is pretty much my personal experience of what a lead developer should be.
I think part of the problem is that there is no industry standard definition of what a lead developer is. It has been my experience it is abused in the ways I mentioned in my previous post.
Again this is all just my personal experience. We are all shaped by our history and though we try and not judge people automatically it will happen from time to time.
If you're in the Philly area and want to work for a great company drop me a line at ccannon@50onred.com. We treat our candidates with the respect they deserve.
I wish everybody would start just refusing to do these homework assignments. I always do. I think they know they lost a great developer when I just walk away. In a way it's just sort of them getting what they deserve (loss of a great worker), but if developers would just simply refuse these homework assignments, everybody would be better of. Homework is a stupid waste of time for young children, and it is as stupid silly waste of time for job candidates also.
I have to concur with this. The interview process in tech seems like a hazing ritual, at times. In the current market, we should be able to use our leverage, as talent, to bring about some change in hiring practices.
They want someone who uses asynchronous programming in coffeescript to build a blog and use shit load of preprocessors and if the library was just released on HN they expect you to use it in production and deal with it.
Don't do these take homework projects. Don't work for free.
My company has you write a simple twitter clone using the php framework we use. If you know the framework, it shouldn't take you more than an hour, if that. I see nothing wrong with simple projects like this. We only ask you to do it after your initial interview to make sure you're a fit personality wise.
You're screening more for knowledge of the particular php framework that you use than general programming ability. Which is fine if that's your intention.
Just like the "simple tagcloud from instagram API, shouldn't take more than a couple of hours." I got given last month.
Two hours of messing about on Instagram trying to get an authentication token for their API I eventually figured it out, only to realize I was authenticated in some sand boxed mode, so only meta-data was being returned. I needed to have the acccount approved before I could use it properly.
Your company would be far down my list. I'm not working for free if what I do isn't open source. If I'm working on a proprietary product I expect to be paid for it.
If you told me to do this take home assignment I would've politely smiled and said 'sure let me do it right away'. Then I go home, research more about your product and the market, try out your demo product, figure out how things work and release an open source version and make it free. Surely, that is a much better indicator than 'Build a CRUD using Yii'.
A few years ago, I did this to one company I interviewed at who were super arrogant and condescending. I just checked their website and it returns 404. Looks like people prefered my free open source version instead of paying them for it.
"The fact that so many employers treat candidates like this tells me that the whole "it's hard to find good developers" line is a lie."
It's not a lie, you just forgot the last half of that sentence. "It's hard to find good developers, who are willing to work for the peanuts I'm offering."
I definitely wouldn't call myself an expert, but in my career I've probably interviewed a few hundred people. I think people way over-complicate this stuff by trying to be too clever.
To me, the most useful question is this: "here is an example project that we'd be likely to do, how would you build it?" Then you just let them walk through the steps they'd take.
From there you can launch into why they made the choices they made, trade-offs, philosophy, etc. When you hear people explain how they would make something real, you start to learn a lot of things about them without even needing to ask, and so you're less likely to get scripted answers. They're also probably in their comfort zone at this point, so you get to see them in a more real way.
I don't necessarily mind "homework" style projects, but I tend to shy away from that sort of thing as it's not always respectful of the candidates time.
Two questions I usually avoid (but see getting asked all the time): puzzle questions, and language trivia. I don't ask puzzle questions because I've never seen it correlate to something useful. Most puzzles require an "aha" moment where your subconscious bubbles up some kind of answer, but the easiest way to short circuit that part of a persons brain is to put them in front of strangers with a time constraint. Puzzles might give you a clue as to a persons overall IQ and confidence, but it won't tell you a lot about how they can do the job.
Puzzle questions are also "expensive", in that they usually put a candidate on edge, and they set off the candidates bullshit detector. Let's keep in mind that we're going to reject the majority of candidates, statistically speaking, but you still want them to think highly of your company. If they feel like they're being rejected for a BS reason, you've just created animosity towards your company. It's important that the people you reject still feel respected.
I don't ask language or framework trivia, as I don't think it's useful. I might lob a softball about a framework just to make sure they've actually used it, but I'm not going to ask something hard.
I always have turned down homework assignments. It just feels insulting and disrespectful. Even whiteboard crap is useless but I'm OK with it considering they've paid for my travel expenses etc.
If you think about it ... homework assignments are a classic case of B's looking for C's. A's wouldn't need to resort to such silliness. They can identify (as an interviewer) and exhibit (as an A interviewee) with just an intelligent conversation.
Interesting. I applied to DO about ten weeks ago. I had an initial phone screen, and they sent me a code challenge. I completed and turned in the challenge. Then I heard nothing for two weeks. I reached out to my contact there, and she got back to me a week later saying, "I've been waiting on feedback - sorry it's taking so long! I just pinged the manager again this morning." That was the last I heard from DO.
I feel like I wasted the half-day I spent on their code challenge. I don't expect a job, but a simple "Thanks but no thanks," would be nice.
Consider yourself lucky. DO seem like a bunch of clowns. I'm not saying there aren't good people working there b/c I'm sure there are but by and large as an organization they are clowns, management recruiters etc. I think it was about a year ago that most of their ops department up and left. That should tell you something. It's not known as a great place to work(heard form ex employees) And if you consider their business model - a race to the bottom it's not surprising.
Nice. I had the same experience with DO last September...The same month Braintree asked me to write a ruby project that took about 3 days and then on the call only asked about python sqlalchemy database queries. I don't know what the disconnect is with these larger companies and their HR staff? By the time that third one asked me to write a node.js rest api from scratch. I just chuckled and said thanks for your time...I doubt I will commit more than a few hours in the future to any throwaway project for just a call back. Why can't we get paid for the time spent writing sample code like a freelancer...If it isn't good enough pay for my time (up to a max) and both parties can move on. Time is more valuable than the risk of getting passed that initial callback/more screens.
Yep, companies are really abusing the take home. A long time ago, when I was actually bothering with interviewing, I would ask for $1-2K depending on the size of the problem.
If it was about 10 hours, $1K was usually OK. I never had a problem asking for this, but the problem is that so many companies are doing it now that they cannot afford to pay everyone.
Yeah I ignore jobs that ask for these screens. I've spent a lot of time on them and then not heard anything.
When I'm adding to my own team I would rather talk to them about code than have them do these screens. It's more holistic and I get more of a sense of how they think. If I'm going to give them a code challenge like this I wait until after the phone screen so I don't waste people's time.
After having this happen a few times during my job hunt a few months ago, I decided I won't do any take-home coding tests if they take more than 2-3 hours. Even if you get great feedback on your work, there's still a very high chance that the company will just go radio silence on you. This seems to happen especially frequently with smaller startups.
Ugh, I have a take home assignment from them to do, worried the same thing will happen to me :/ I don't want to waste the time if they don't get back to me..
I've created from scratch: new CRDT data-types for geospatial problems, new highly-available transaction patterns that provide useful causal history and atomic visibility, large-scale messaging platforms (400k ops/sec), high-throughput machine learning pipelines, lock-free lightweight-process mailbox implementations, and an end-to-end build pipeline for generating bare-metal rumpkernels to be parallel deployed to N-number of Minnowboard Max devices. Among other things.
If you asked me to do homework to prove to you that I can "program", I'd have a brief discussion with you about how misguided that seems, thank you for your time, and walk away.
I mean fully "hundreds of connections" to a socket pool? Are you serious? If I submit a solution that can do "hundreds of thousands of connections" that includes QuickCheck tests for your protocol and my implementation, Ansible scripts for deployment and orchestration, and a Makefile that builds it, tests it, bakes it into a unikernel, and drives the Ansible scripts to push it out and start the end-to-end load test, do I get to be CEO or something?
Why is tech hiring so full of strange, meaningless obstacle courses? Do we just collectively not have better ideas?
Because there are a lot of shit candidates. You might know you're worth talking to, but try hiring and you'll see why people want to separate the wheat from the chaff.
I have tried hiring. Many times. As recently as yesterday.
Using a combination of (semi-)rigorous personality profiling (time constrained), and mapping the abstract problem domain of their prior work to the problems I actually have for them to work on, it's been possible to align new people with the work such that they're intrinsically motivated, and make sure all the bases are covered for the necessary roles (hacker, inventor, finisher, watchdog, etc.) to carry a very large greenfield project from start to finish.
I've never once given a cute riddle, puzzle, or coding challenge as a part of the interview process, and actively dissuade others from doing it as well.
Sure. To start with there are many, many models for personality profiling. I tend to stick to "The Big 5" mostly because it's foibles don't sufficiently affect the outcomes I care about, and I've gotten proficient enough at it that with the right set of questions in the right environment I can typically get a pretty good read on at least 4 out of the 5 factors, and given a follow-up interaction I can usually clear up anything that looks like contradicting signals by getting additional context.
Like for instance, if you were to meet me, you would probably immediately peg me as high on extroversion. While understandable given the outward traits I project, you'd have needed to really thoroughly created a controlled environment during an interview (requiring a series panel, a day-long engagement, and an intentional highly-social event in the middle) to figure out that I'm actually introverted, but have just learned how to benefit myself by projecting extroverted traits.
Now the richness of any assessment is bound by time, planning, training, and practice. If you want to get really good at it, you learn to do it in realtime by assessing people you know well, assessing yourself, then moving on to acquaintances, and eventually onto strangers. In each step you need to be aware of where your assessments are drifting from the model. Like if you assess yourself or someone else as high on agreeableness because you find that you're very typically conciliatory or trend toward diplomacy and keeping the peace amongst your peers, but you also are prone to "blow-ups" where you drop the hammer on people in rare, but consistent, circumstances (when you've "been pushed too far"), then you're probably not as high on agreeableness as you think, and are probably higher on neuroticism than you think you are.
Given enough inputs and hypotheses you can get pretty good at this. Good enough to provide useful points for making decisions given otherwise limited information. More importantly you can get good at how you setup your environments and your interactions to get higher quality signals from your limited information. For instance, say I wanted to assess someone's "Openness" because I wanted to bring them onto a team where their primary responsibility will be in driving phases of invention. The simplest pass would be to just ask them about personal activities and look for signals of risk-taking. However, one needs to control for the difference between risk-taking due to openness to experience and risk-taking due to self-destructive traits. The former would be awesome for the job role and the latter will bring down the whole ship. To control for that you'd want to put additional emphasis on assessing neuroticism and conscientiousness. Doing that can be as simple as leaving a lot of awkward pauses in the conversation and see how they deal with it. Does it make them uncomfortable? Do they feel compelled to fill the air with something? What do they fill it with? Relatable stories, trivia about their work history, etc. When they talk about anything, not just work-related things (sometimes specifically not work-related things), what level of detail do they provide? Is it consistent? Is it always TMI, always 30k ft view, or can they move fluidly from one to the other?
Things like that. Different kinds of job roles require a different kind of personality profile to be successful, and more important than that, the composite of personality profiles filling those job roles is a requirement for a healthy team where each person is competitive with themselves, but cooperative with their peers, and has the right mix of people to own each phase of the development and business process.
Hey, thanks for the reply, your insights are amazing. Totally with you on the whole "being an introvert who learned the traits of extroversion" thing too.
I've played around with the Big Five model ages ago and found it to be a really good way to look at personality. I especially liked its usefulness for self-assessment - like you say it's easy to self-deceive yourself into thinking that you're much more open and non-neurotic than you really are, but so long as you are honest with yourself it can be a good tool in understanding your own strengths and weaknesses. I hadn't really tried practising it on strangers, though, that would definitely be a useful exercise!
I'm actually in the process of setting up a crowdfunding campaign for a personal project that I'm working on, and if that goes well then I'll be thinking about bringing in more people on board - hence why I asked you about this.
I have to say, the way you're going about this is really impressive in terms of methodology. Most high-level advice in this area that I've seen is full of hand-waving and vagueness, but you've got the whole thing down to a science. Especially the part where you talk about counterfactuals! So many people overlook that.
If you don't mind answering another question, I would appreciate more of your thoughts on this. You've said that you look for particular combinations of traits to fill in particular roles (hacker, inventor, finisher, watchdog, etc.) - what are the traits that you look for in each of them and how exactly do you envision each role's responsibilities within the company? (Is there a set number of such roles that you discovered or do you find yourself inventing new ones as the company evolves?)
Also, it sounds like you've been doing this for a while and probably have quite a few people on board, which would make the dynamic of hiring someone a bit different than if you were just starting out. If you were back to square one and had to consider hiring your first employee or even finding a potential co-founder, how would you approach that?
Sure, do you want to take this conversation offline? This is just going to get buried deeper and deeper and eventually become locked when it's stale enough.
I really hate having to solve these kind of programming challenges. I've already sent you my CV, with references from former/current employers and co-workers. Call them up if you are worried that I'm lying on my résumé, don't waste my time by making me work for the chance of maybe getting a job as only payment. Doing multiple interviews already takes up enough of my time, seeing as I'm the one who has to commute to your location.
No former employer is going to say "this guy can't program, don't hire him" for fear of getting sued. Co-workers might be friends who are covering for you, or just genuinely have no idea of your actual ability.
Taking up hours of a candidate's time is excessive, but it seems reasonable to ask for some demonstration of your ability, when so many candidates simply cannot code.
> Taking up hours of a candidate's time is excessive, but it seems reasonable to ask for some demonstration of your ability, when so many candidates simply cannot code.
So why not simply ask technical questions during an interview? I'd think you'd be able to determine whether or not someone know what he is talking about by simply asking him a few questions on the matter.
How do you know what level to pitch the interview at if you don't know what language features someone understands and how they code?
Where I work we now set a small simple test which is very representative of what colleagues do because we've had so many time wasters. I'm looking to see their style, the fact that they can actually read a simple spec (apparently over half can't), and that they can explain why they approached the solution how they did. If their test is no good, we don't waste each others' time.
If someone has a decent GH account I'll look at that too - if it's sufficiently comprehensive (very rare to see anyone with a GH account at all, let alone their own projects in it) they won't need to do the homework (should take about an hour, less if they're good). This just saves us wasted time.
Remember - you might know you're good. How do you expect strangers to?
Because there are plenty of people who can regurgitate things but not be able to do much with it. I've seen it with CS grads from good schools, its disconcerting and confusing.
Why are you asking "fact regurgitation"-type technical questions? I prefer to ask open-ended ones, questions that start a discussion that will quickly determine if the candidate really understands what they are saying. It also reveals correct but rigid thinking, something I would like to generally avoid but that doesn't always come up in a coding exercise.
That's why you drill down when a statement sounds like it came from a blog/book/screencast.
While I agree it's frustrating dealing with someone like this, often times it's easy to pick out the statements/topics that the person is regurgitating.
Agreed, but for people who have to justify hire/nohire/fire decisions to their bosses or other parts of an organization an objective metric is very useful.
A quick coding problem doesn't have to take that long either. I agree that asking for a (relatively) huge project is the wrong way to go about it, but it doesn't have to be huge.
Because technical questions are pretty bad indicators. Just because someone doesn't remember how to reverse a binary tree off the top of their heads doesn't mean they're not a competent developer.
Right with you buddy. I no longer accept coding challenges or even interviews that go over 30 min. I tell them my services are $150/hour. If you want me to do a 4-8 hour exercise for the privilege of interviewing further then make it worth my time...just like any other consulting gig I do.
Wow, that's self confidence. Paying someone for the homework problem feels semi-okay. But what if you have a no-moonlighting clause at your current job?
But asking to be paid during the interview seems too much, even though you could have spent 3 days of your life, traveling each way plus the interview day.
Asking to be paid during an interview seems too much but a 4-8 hour interview doesn't seem too much? The average interview length across all industries is 40 minutes. Asking interviewers to spend 4+ hours on the hope of a job offer seems a tall demand. I think asking to be paid seems a fair counter to what is otherwise a very unfair ask.
What you're actually saying is "I have enough freelance / contract work and am not looking for a full time job." I said similar things when I was freelancing.
If you were actually looking for a full time position you'd do the interview. It's completely reasonable to require an unpaid interview from a candidate.
Not a multi hour one though. My first programming job interview was 6 hours and I had no idea that was even a thing. Now I inform places I'm interviewing "Hey I am taking 1.5 hours vacation/PTO whatever, so I need to be back at work after that time."
The problem is: Writing good resumes and having a lot of experience with programming is a good heuristic for "experience" and "knows how to play the game" but not meaningfully useful for "excellent at programming".
Work-sample tests measure the latter.
A worker's experience is a heuristic for programming skill, but a heuristic of a heuristic is like an average of a set of averages: Useless.
Very true! I find it disappointing that many candidates appear to put little effort in their cover letter. It's a chance to show me you can communicate well, which is maybe the single most important skill in working on a team.
I feel like cover letters are an easy way to show that you've thought about the company you're applying for, but in my experience I've never got the impression that my cover letter was actually read in the application process.
I could be plenty wrong though, and I'd love to hear from HR/recruiters about their experiences with cover letters.
I dunno. I'm sure some places don't read them at all. But I read (or at least skim) every cover letter that comes across my desk before looking at the resume.
Which makes it extra frustrating that hiring practices are the most often cargo-culted practices in this industry. I feel like the root of hiring problems is that most companies know neither what they need or how to identify those features in a candidate.
I think that's debatable. The quality of your measurement is then simply a function of how well your tests are in the first place. Do you really think giving a person FizzBuzz is any kind of accurate predictor of future success at a job?
(Switching back to my old account because rate limits.)
I wouldn't ever use something like FizzBuzz to assess a candidate. It would be more of "here's a mostly finished sample application with a corresponding SQL file, add this feature (e.g. a search bar for a blog) and fix any (intentionally introduced) security bugs you find".
They would be evaluated based on how successfully they complete the main task, and if they have an eye for finding/patching vulnerabilities, that's a bonus that can be used as a secondary selector if a lot of candidates pass. If no one does, it won't be used against them.
That's how I'd approach it, personally. Something specific to the kind of work we're doing, but abstract enough to be approachable without a lot of insider knowledge.
FizzBuzz isn't a test of whether a candidate will succeed, but of whether they will definitely fail. Someone who passes may be good or bad, but someone who can't do it is definitely not qualified.
Someone who can't do it is definitely not qualified to do fizzbuzz level programming off the cuff in a stressful interview situation.
Whether that tells you anything about their ability to do fizzbuzz level programming in a more normal work environment is an open question.
There are a few HN readers who've had experience of "choking" on fizzbuzz level programming tests during interviews - even though it's trivial there's something about the interview situation that causes some people to sometimes freeze.
What do you mean by probation periods? Something like...
"Hi, I'd like to ask you to work for a very temporary contract with us so, if it doesn't work out, you have to scramble to find more work and maybe risk homelessness."
In my experience, in the US, in the few times I've been asked to work for a 2-3 month test-drive, the proposition has been more like ...
Them: "Your skills are great, nice job on the coding project. You seem like a really good fit. We want to hire you, but we'd like you to work on a temporary contract with us at first to see how it goes for both of us."
Me: "Hmm, OK, this does seem like a very good fit and I'm cool with the test-drive. My off-site rate is $150/hr, I can have the contract on your desk in two days."
Them: "Er, wha ..., no, you see, we'll take the salary we talked about and just translate that to an hourly rate. It shouldn't be a big deal, this will only be for three months max."
Net of it: after killing it in the interview, I'm offered a short term C2C contract at drastically reduced rates, doing my usual best work, while getting no employee benefits and paying my own SE taxes, retirement contributions, and all business expenses.
I've encountered such propositions only a few times in the past 5 years, and walked each time obviously, but I still find the chutzpah of these companies astonishing.
On the other hand, maybe that was the last part of the interview? They may have wanted to see if I had any self-respect, any self-confidence, could do math, and understand basic business concepts like taxation and fully-loaded employment costs? A "no" to any of these things would have meant I'd be a more ignorant, cheaper and thus much more highly-valued employee as time went on.
In the US almost all employment is at-will - even if you've worked at a company for years. Probationary periods here typically mean that you are hired as an independent contractor without the benefits that are usually given with a full-time position such as health, dental, and retirement benefits.
Employment with [company] is "at-will." This means that you may terminate your employment at any time, with no prior notice given to [company]. It also means that the company may terminate your employment at any time, with or without notice or cause. While the company generally adheres to progressive discipline, it is not bound or obligated to do so.
As an at-will employee, you are not guaranteed, in any manner, that you will be employed for any set period of time. No one in the company, except the President, in a written, signed contract, may make any representation or promise to you that you are other than an at-will employee. Any employee, manager or supervisor who makes such a representation or promise to you is not authorized to do so.
I've no idea why this has been downvoted as it's correct.
For the last few years this has been written into law and employees don't get their full employment rights (such as the right to contest an unfair dismissal) until you've been employed for 12 months. (A de-facto one year probation period.)
I should note that employee rights during this probation period are probably stronger than in many US states.
You don't want to hire people who are incapable of functioning in a professional setting or interacting with coworkers, so I'm not sure expecting experience and a well-crafted resume (regardless of the content) is a problem.
Just as grep and cat solve different problems, work-sample tests and traditional resume-based hiring practices select for different candidates.
I wasn't arguing in favor of work-sample tests for every company and every candidate, just saying their scope is different (although work-sample tests are more likely to find the untapped potential in the marketplace).
We live in an era of FB/LinkedIn. It's really not that hard to contact someone that they've worked with and ask, "did you like working with this guy/gal?"
I just want to create a well documented simple resful API for applicants to use. If an applicant wants to apply for a job they have to write code in the language of their choice to apply using the API. Upon successful application, request their SSH public key and supply a git repository they can check their code into. A hook script will email me upon successful commit.
A moderately experienced dev will not spend much time to apply, and frankly would probably enjoy the interface better than most job application websites. :-)
A lesser experienced dev will end up spending more time, but really if they are successful we would still want to look at them.
And the GREAT devs like me will not waste their time on your antics and will look elsewhere for a job at a company that is less of a hassle to deal with.
Great devs never apply for any job using the traditional job application (except maybe as an after-the-fact HR formality); they are always recommended and hand picked by their network.
As a intermediate (after so many years, should I just replace that with 'mediocre') dev I think a test like this would be a fantastic way both for a company to judge me and for me to judge what a company would expect from me.
There's a huge variety in dev roles ranging from challenging to code monkey and it's sometimes hard to figure out from a job posting or even conventional conversational interview where along the spectrum the expectations are, but establishing those expectations on both sides is critical.
This sounds like a great idea! One caveat being that the it probably caters more to web/mobile devs. Eg. you probably wouldn't use this challenge for a database engineer, or machine learning role. You could, but it wouldn't tell you much about their skills in the domains you're interested in. Still definitely worth trying for roles where it makes sense. I might try this.
It does make me wonder how hard it would be to come up with basic challenges for different roles to simply apply to the job using their skills. I guess for some rolls harder than others. :-)
The goal wouldn't be a hard challenge, just one that shows basic competency and problem solving ability within their field.
Still this would take time and effort to create. That said, the last time I hired someone I probably spent 100 hours reading resumes, filtering candidates, and interviewing people.
The real problem here isn't coding interviews; its how we (hiring managers) approach the entire question.
The goals of a technical interview should be:
- Confirm the credentials presented aren't complete BS
- Validate they know enough to be immediately helpful
- Assess their long term potential (brains, social skills)
Coding challenges tend to be good at the first two points but very questionable for the third. Incidentally, given that I'm seeing a 50% washout rate from a basic SQL code question (supported by confessions from candidates that they fabricated credentials/experience), you would be silly not to include some form of practical test.
The third point (potential) is best measured by talking with them about a project they really cared about. For those who cannot share work examples, pick a good side project. Don't get hung up on the content - focus on their passion. You'll get a better view of my capabilities if you chat with me about building an ad server, mobile optimization, or SEO analytics (real world projects I care about) than with a contrived example.
As for the github profile of code shrugs why? Seems like a bit of a cult to me. I'm happy to sharing anything that's useful (and do so on my blog) but don't have the free time to spend developing code for the sake of "work samples". My work samples run on production servers as commercial projects, thank you very much..... Suspect many other good candidates are the same.
"you would be silly not to include some form of practical test"
Yes, I'm coming to the realisation that it's idealistic to assume that anyone with N years experience will be at a certain level of ability.
"(potential) is best measured by talking with them about a project they really cared about"
I agree. I've always thought that once you've made sure that a candidate's programming knowledge isn't fabricated, the best way to evaluate them is to get talking about code. Whether that's proprietary code they've written but can't share, or it's on a GitHub profile for all to see shouldn't make a huge difference.
One of the best interviews I 'gave' was when the interview was for a position programming on a topic I knew almost nothing about. I had the person bring their laptop and walk me through their implementation of the topic at hand, then asked how they'd scale/improve it given more cpu/memory/etc and what kind of constraints the larger environment would impose upon the work.
Like the author, having run a hiring program for several years based on coding challenges designed to mimic the work the team does (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way.
I particularly like how this team iterated on their uploader problem, abstracting it out to a socket server and providing a test suite for it. Reacting to ambiguity by abstracting the problem was clever. And, of course, a great illustration of how a standardized hiring tool can, like any software project, be iterated on and improved --- unlike a free-form whiteboard interview.
> (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way.
Because every method of hiring has its own biases and tradeoffs. Requiring work samples biases against programmers who aren't interested in doing a "homework assignment". For example, I don't enjoy whiteboard interviews but I'd rather write some fragments in front of the interviewer and "think out loud" instead of working on a multi-hour (or multi-day) coding project. Writing on a whiteboard is just not that big of a pressure cooker to me.
One could argue that the majority would prefer self-paced work samples instead of whiteboard interviews and you're optimizing for a wider candidate pool. That's fine but it's still a tradeoff. I think you're running a smaller scale boutique firm so work samples makes sense for you.
For a company like Google Inc who is more selective[1] than Harvard University, I don't see a compelling need for them to rely on work samples. That company is so desirable for programmers that any "work samples" Google tries to standardize on would get leaked and endlessly discussed on stackoverflow (see FizzBuzz for precedence.) If Google has to keep changing out the work samples to stay ahead of the street knowledge, you've lost the ability to compare work samples over the years which was one of the motivations to use that method in the first place.
At their scale and selectivity, the "study your algorithms book and prepare to be grilled on the whiteboard" seems to work best for them. Yes, they reject a lot of false-negatives but it's offset by ... their scale and selectivity. They can afford to reject false-negatives. If their screening methods were truly terrible, I don't see how the label "ex-Googler" would have the currency it does in the marketplace.
It's easy to be selective. I can ask all comers with a degree to roll three dice, and if they don't roll three sixes, I consider them unworthy. Only about 0.5% of candidates will pass. That's a pretty selective first screening, isn't it?
Selectivity is only good if it selects for traits you want, and, in practice, what you want is not a uniform skillset. So being selective for one trait, any trait, is already a bad idea.
Even the basics of the interview format make a difference. At other companies, all coding interviews are timed at 45 minutes or so, including the problem statement. It's a bit like going to an episode of Chopped. It's certainly selecting for 'can you think under pressure' along with 'are you friendly enough that your interviewer will help you when you are getting something wrong without docking your score'. But that's not good for a careful candidate that is trying to build sturdy, reliable code. So guess what: The company's codebase has few tests, things fail often when deployed to production, and reliability is a problem. It's not that they are willingly selecting against careful programmers, but it's a consequence of the interview process.
The moment you are hiring a lot of people, and you think you have a single model that works, you are hiring from a cookie cutter, and you'll get gingerbread men.
Companies that do work samples minimize on-site coding interviews, because the whole point of offsite work sample testing is that most candidates can't provide an accurate picture of their aptitude in an on-site coding interview.
No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge.
The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission. Nobody wants to do homework that goes into a black hole, only to find out 6 months later that they were in consideration for the role. That's a problem with all hiring companies, and it is orthogonal to the structure of the interview itself.
The problem with take-home assignments isn't how long they take - it's how many you end up doing.
Resume-to-offer attrition rates are often as high as 99.9%. In-person interview-to-offer attrition rates are rarely worse than 90% and often in the 30%-50% range.
The thing about homework is that it costs companies basically nothing (one form email followed by an automatic grader in some cases), so they can afford to give it as early as possible - strictly by the numbers, this means offers cost on average 1000x8 hours. Whereas in the in-person interview case, the big cost is much later in the process, so it's more like 10x8 hours per offer.
Worse yet, this cost falls heavier on developers that have more trouble getting jobs, who are probably less likely to be able to weather that cost. Not a great situation.
>No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge.
Sure, Google/Microsoft have the legendary "6 hour" marathon interviews with multiple teams with lunch in the middle but for smaller scale of companies, they don't have bandwidth to mess around with all-day interviews. It's ~2 hours. In this thread, it shows I'm not the only one who prefers onsite whiteboard over homework projects so the "no developer prefers" claim is too absolutist.
>The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission.
Regardless if the feedback is received within 10 minutes or 10 days of submission, if I apply to 4 companies, I don't want to do 4 homework projects. I simply don't. At least with 4 onsite interviews, I see glimpses of the office and meet the interviewers.
This is just not true. I talk to interviewing developers every day, and very few of them are interviewing at Google.
The final round of on-site interviews usually eats a whole day, and is preceded by a whole battery of time-wasting phone interviews, which themselves eat as much time as a coding challenge and often involve coding with someone else over the phone or Skype.
There are companies that are not Google that have multiple rounds of on-site interviews.
No. Everyone interviews this way. The very most marketable candidates leverage personal brand and connections to dodge a lot of it, but you have to be good at sales to do that.
> No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge.
I'd prefer it, since if I pass the coding challenge, I'm likely in for a airplane flight and an on-site interview anyway, so I've still lost that time from my life in addition to the time spent on the coding challenge. Unless the coding challenge is conducted INSTEAD of an on-site hazing session, in which case, well, E-mail in profile!
The sensible solution, which I have seen done very successfully before, is to add a 1/1.5hr hr on site/skype step, in which the candidate goes over the solution, and asks for a small feature. It both proves that the code was written by the candidate, shows some of the personal stuff the homework didn't, and makes it far easier for the candidate to perform well, because they are familiar with the code, as they wrote it!
It's not an expensive investment for what you get, and since the meeting should happen soon after the code is written, it's easy to provide basic feedback.
> For a company like Google Inc who is more selecitve than Harvard University
Nitpick, but I'd love to see a citation on that. Google, like every technology company on the planet (modulo a small error value) goes to great lengths to recruit and hires lots and lots of people.
See my previous footnote about them receiving 1 million resumes to fill 1,000 slots. If that's true, it is more selective than any Ivy League university.
No. That's not how a market works. Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it.
And engineer headcount costs are a huge component of their business --- so much so that they've been accused of breaking the law to collude with other companies to avoid competition in hiring!
Google is succeeding in spite of the waste and unreliability of their hiring processes, not because of them.
>Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it.
But there's no evidence that switching to self-paced work samples would cost them less. With Google's popularity, they'd get more false-positives from candidates that copied the code from widely disseminated previous projects. False-positives cost money.
Your medium size firm with smaller volume of candidates won't have that problem of increasing false-positives.
Sure, with whiteboard interviews, the rejected candidates (and even ex-Googlers) can write a "brain dump" blog with blow-by-blow algorithm questions but history seems to show that these don't work so well as cheating mechanisms.
What kind of work sample project could Google realistically design for 10000 programmers to complete? (It can't be as hard as "solve this Clay Millennium problem" or as easy as "reverse this string". Anything between those 2 extremes is trivial to copy to github.) How often do they need to redesign the work sample? What about objective "comparisons" which was touted as a feature of that method? What about the programmers that don't want to do the work sample? (They do exist!) Is there also a cost to filtering them out?
It's great you're really enthusiastic about work samples and want more companies to adopt it but I see no slam dunk evidence that they are the universal best method for every company.
Google is manifestly too capriciously selective in their interviews. They are infamous for turning down people who go on to do excellent stuff elsewhere. Watching acquaintances navigate their process makes me believe the infamy is well-earned.
That's an argument that is separable from the question of how best to design the Google interview process. I think Google's interview process should be work-sample based, like I think every tech company's should be. But you could argue that either way. We can both agree that Google's challenges are sui generis. We're both reasonable and might disagree on the rest of it.
Where I don't think reasonable people can disagree is on the question of whether Google overpays for engineers. They do. They pay a tax for the luxury of being capricious about who to hire. They can afford to do that, but most companies can't.
Finally, some validation that my interpretation of their process is not insane.
One thing that really rustles my jimmies is the constant assertion that "false negatives are (effectively) free". I think Google and the companies who hire like them seriously underestimate how much this costs them, both the direct costs of spending so much to ultimately reject people and the indirect costs from the work that is not getting done or being foisted on another overloaded engineer.
I worked in a small microcosm of Google's market (Google wants the "best of the best" software developers, and we wanted qualified app pentesters; both are a small subset of the overall market for software talent).
My experience is that running a hiring process that lights up only on the kind of talent that qualifies itself with a standard tech interview is ludicrously expensive. People that do well in standard tech interviews can work anywhere they want. If you can only hire those people, you are competing for talent with the wealthiest (or most overfunded) tech companies in the market.
Fortunately: performance in tech interviews is in fact not a good proxy for programming ability (in fact, there are ways in which being good at interviews can obscure deficits in candidates), and you can get ridiculous discounts to the price Google pays for talent if you don't try to hire people the dumb way Google does.
The root issue is that, the costs of bad hiring are even higher than that. For a rapidly-growing company bad hires can snowball into a bad organization.
Apparently this is where I will disagree with Tom, because I think the costs of a bad hire are often overstated. Part of it is loss aversion, and part of it is inability to quantify risk. In fact, it seems like the industry is at a point right now where they would rather repeat this mantra than put effort into understanding the scope of the problem.
The costs of a bad hire are overstated. The cost of systemic bad hiring may grow geometrically. If that estimation is correct (bad hires result in more bad hires) then no price is too much to avoid a bad hire.
And consider the US Air Force. They have an unlimited number of young people willing to learn to fly jets. Qualified candidates even. So they can filter any way they like, and still not run out of applicants. So their filters seem capricious, because they sometimes are. And it doesn't matter.
Is Silicon Valley in that position? Depends upon who you are. I don't think Google for instance is running out of candidates.
I suspect that the idea that the costs of bad hires are huge comes from not identifying bad hires early. If you hire a jerk who makes poor coding decisions and fail to oust him for a year or more, the effect could be devastating. If said jerk is spotted in a month or so, it may not be so costly.
And really there are levels of bad hire. There's the bad hire who really doesn't know how to do the job and will never get good enough to do it. That person should be very easy to spot with not too much effort in the interview process. The dangerous hire is someone who on the surface can do the work but has a toxic attitude and/or doesn't learn/grow. I'm not sure putting someone through a torturous interview process is going to root that person out.
I think where a lot of the elitist hiring is at now is that many companies aren't so much trying to filter out people who can't do the job, so much as they're holding out for who they think are rockstars. So they put candidates through the ringer with the thought that what will be left is rockstar material.
But many highly-qualified individuals won't jump through hoops for any but the top tier companies, and sometimes not even then. Furthermore, by definition, rockstars make up a very small percentage of the devs out there. What are the chances that every company who is holding out for elite coders even has any applying? Especially considering that elite people probably don't jump around often.
> filter down from a large number ... to a small number ... doesn't say anything about how selective they are.
But that's what the definition of "selectivity" is for database retrieval. Selectivity == n_rows_selected/n_row_count. The "larger number" was the denominator and the "small number" was the numerator.
Your example SQL is not consistent with your previous sentence:
SELECT TOP 1000 FROM resumes ORDER BY received_date
Notice that nowhere is the total row count for resumes known in your isolated example? So yeah, we don't have the denominator to determine selectivity.
For examples of Harvard and Google, we know the denominators (the total applications and total resumes). Therefore we know the selectivity.
I suspect you're mixing up "mathematical selectivity" from "decision process selectivity" because Google's internal decision tree for hiring might look to outsiders as "black box" or nonsensical.
The denominator has no relevance to how selective your hiring process is. Your process does not become more exacting and precise simply because you received more applicants.
Thank you for confirming that you were using the colloquial version of "selectivity" which doesn't require knowing the denominator instead of mathematical "selectivity" which does.
That wiki page orders the ranking on mathematical selectivity and not colloquial selectivity. My previous comment of Google Inc being more "selective" than Harvard is to be interpreted as mathematical selectivity. Sorry for not stating it more explicitly to prevent confusion.
So you don't care about on what basis selection is performed?
If your assertion is just that Google rejects a higher proportion of applicants than Harvard, that's... not at all interesting. The lottery rejects and even larger proportion of applicants for its 'grant' program, but I'm not going to try to learn anything from how it goes about picking winners.
Part of the reason why is that it's super-easy to apply to jobs online. With just a couple of clicks (especially via LinkedIn) you can apply for whatever you find listed. This is an area where Taleo & similar provide enough friction to make it somewhat painful comparatively. So, you end up with thousands of people submitted applications for each of the positions Google lists. Most are not serious candidates (or at least worth seriously considering).
Because at the end of the day coming up with work sample problems & then applying rigorous metric analysis is much harder than "grab engineer & throw him in a room with the candidate".
It's such a false economy. It's harder the first time. By the third or fourth time, it's free. And that's before you count the expense of making super dumb hiring decisions, which is what happens when you use virtually any other process.
How long did it take you to get scripted interviews implemented at Monsanto? How long to actually figure out what the scripts should say? Did your data indicate that the interviews were valuable & if not, how long did it take you to get interviews removed from the hiring process? How much of your time did you devote to building work sample tests or work sample sales funnel devices (microcorruption)? This is at an organization where you had a fair bit of influence.
Now take a more normal organization where the hiring pipeline is guided by people who treat it either as a sales process or a regulatory one. Those people are given their marching orders by executives that either believe or want it to be true that employees are fungible and readily available. The actual resources are allocated by middle management that are already resource constrained (thus the need to hire) and the people doing the interviews have never thought about it being something they can apply engineering skills against. Its a hard problem...
Also, I suspect your marketing department might prefer if you never downplay how hard it is ;)
I am in the midst of my job search, fortunately I'm not currently working (due to an international move) so I have more time.
So far, I have completed around 12 1 hour phone coding tests, the same amount of 30 min chats with recruiters, I have 8x 5 hour on-sites scheduled, have spent about 4 long days on one take-home assignment, 6-8 hours on another, and have two more assignments to complete, both of which I estimate will take over 8 hours each.
I haven't had a weekend for the past 2 weeks because I've been working on assignments and I'm pretty stressed and exhausted.
This process has made me consider changing careers because it's so exhausting. When companies give you take-home assignments I don't think they realise how many things you have going on at the same time.
Additionally, I've found that a one hour coding test has allowed companies to move faster in the process with me than those who have given assignments. When I receive an offer from a company I am happy with then I will tell those companies with assignments I haven't finished that I won't be moving forward with them and they will miss out on a great candidate!
yep, I am there with you. Completely exhausting. Have missed a few weekends + reading some stupid how to do interview books and stuff like that... a real shame.
> This process has made me consider changing careers because it's so exhausting.
Me too. I'm so put off by the entire process but it seems that to stay relevant, you have to get lucky and end up at a place that keeps your skills up-to-date with opportunities to learn and use the latest tech, or you jump ship every 2-3 years meaning you're once again dealing with this insane pressure of interviewing. Throw in ageism once you get past your mid-30s or so and the mere thought of staying in the industry starts to look quite depressing :-/
Furthermore, after providing ZERO feedback in the past when I have provided github links, offline code samples, personalized cover sheets, etc. to prospective employers this also will not be done. I'm not going to worry and beat myself up because you can't be bothered to provide feedback even when requested to do so.
Homework for programming jobs is just like homework for school: it is not used to judge competency but to demonstrate that your time is not your own as it belongs to someone else. In the case of programming jobs the homework assignment also acts as a filter to weed out employees who will not be properly subservient to the employer.
Last week, I finished 2-3 hours of on-site interviews which required a flight and an overnight stay after an initial phone screen, a phone technical interview, and a short technical challenge online.
I was surprised how a couple really basic concepts evaporated from my head during the in-person white boarding. The questions though were reasonable and the interviewers were friendly. All in all a positive experience just an incredible investment of time it seems for all concerned.
The take away is I need to practice solving problems on a white board with just 3 hours of sleep. The sleep deprivation part might be the most important factor to simulate.
So I know you're kidding about the last, but a good nights sleep can make a huge difference to recall and memory and performance during an interview. I have interviewed tons of people and can always tell who had to fly internationally to get there..
On paper (or blog), having a candidate write code for an interview is better than a BS whiteboard session.
In practice, it means I spent 20 hours on my last piece of sample code I submitted to a job I was excited about. Only to be told no thanks, with the feedback of:
"Your app meets what we spec'd out, but it differs from our style."
And to be clear, after I repeatedly asked for what they were looking for in this code, they replied "we are purposely providing nothing except functional requirements to see what you produce".
I could have given them exactly what they want, but I guess they'd rather just wait and hope that someone magically codes the same way they do?
A startup in Berlin gave me a code challenge that would take at least 20 hours, I had even to deploy in specific version of the libraries, they give the datasets and etc.
I was very suspicious of being an actual feature development. I've said I would only do that if they would pay me to.
They answered that they feel very sorry for me because a lot of the candidates feel the coding challenge very challenging because they can learn new stuff and they love it
I had a pretty famous startup in Toronto decline a second interview because I flat out refused to do a take home test that probably would've been at least worth a day's exploration.
In comparison, a YC company (who eventually got acquired) actually responded very positively to my suggestion that I get paid to do the test they required, not dissimilar to bringing in a freelance contractor for a day.
I've heard places that actually do that and I believe it's the smaller company (startups) that would actually go about doing such a thing than a large company
> As brain-dead as I was after eight hours at my project, [..]
Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month?
I don't really understand this ideal. What's the point of maintaining an online portfolio and a github profile full of code if companies prefer to waste your time writing a pointless uploader?
I got laid off recently and was applying for all the jobs I could find. So I had to do a bunch of these programming projects. I don't mind them per-se, but it takes so long to do each one and you have to be ultra-clean with each one. I don't think companies take into account that you might not have that much free time. It's particularly stressful when you don't get through.
On pair programming tasks, I had a pair programming session with a guy, he gave me an empty project and a poorly specified brief, verbally, then gave me 15 minutes to crank something out. It was pathetic. I didn't get the job and the feedback was, "he didn't know some of the keyboard shortcuts I'd expect." In hindsight, I'm glad I didn't get that one but at the time things were getting desperate.
The best process was the one where I finally got a job. We talked on the phone for an hour and a half and by the end you could just tell we had that, "developer bond". His approach was the best I'd seen. He just talked through some of the problems he had, I proposed solutions and we talked through pros and cons. He treated me as an equal from the start. After that we had the face-to-face HR questions (how do you resolve conflict, etc.) which they have to ask because it's a big company, and another one with another manager but by then it was pretty much a done deal.
And I think that's the way to do a decent hiring process. Don't behave like an authoritative dick, and use phone interviews to screen candidates. Programming projects don't work because it's going to take you forever to review them, and pair-programming doesn't work because there's not enough time, and it's kind of horrible for the candidate.
Wholehearted agreement here. The only purpose of these challenges is to start a conversation about code. Why not just bypass the bullshit challenges and just _have a conversation about code_?
My best job experiences are exactly as you describe.
The worst have been companies that sought me out (I didn't apply) and then wasted my time during the phone screen (having background conversations with other people in the room, asking me to repeat answers to questions because they weren't listening)...I'm looking at you, Uber.
"Why not just bypass the bullshit challenges and just _have a conversation about code_?" Because talking and doing can be different? _Do_ they actually write test cases? Do they write documentation? Do they make output machine parseable? etc. I want to see what work product looks like even if the work product is simple. (which is also why the homework I assign is nothing ridiculous like 8 hours nor do I timebox it)
Talk about that stuff. People sometimes spend extra time polishing a code challenge than they do in their day-to-day. People can lie to you in code just like they can in conversation.
Sure, you know that their ability to do it is there, but you still don't know that they will and you still don't know that if they didn't they could learn. You can get that information from having the right conversation.
What testing tools do you use? What's your approach to testing? What pitfalls have you run into with testing?
What projects have the best and worst documentation that you've used. How does this affect the work you do? How do you make your code usable to others?
What's your opinion about input and output of functions? Separation of concerns, etc?
Or the best question of all: What books about programming have you read and liked and why?
You can't stare at somebody's code and know if you'll like working with them. More importantly, weedout challenges are a solution for the wrong problem. If you're worried about wasting your time bringing in the wrong people to interview, maybe focus on getting better indicators on the kinds of people that you (want to) bring in.
"People sometimes spend extra time polishing a code challenge than they do in their day-to-day. "
Maybe thats because they are under resourced in their day to day, and don't get a chance to do things nicely despite complaining to management about it constantly.
A lot of people have the "get it done so I can get out the door" mentality and cut corners which they obviously wouldn't/shouldn't do during their interview process.
Though them not doing it and spending the energy to "complain to management constantly" might be a problem too. I'm sure we're all familiar with terrible management practices, but some people are complainers and some people are pushovers and you don't want either (or at least you don't want to bias your team towards one or the other).
Being able to calmly explain a process problem and demonstrate why is a critical skill. If you're in a company where that's a waste of time, don't complain, just leave. If you can't fix or guide people, your code still won't get shit done.
I think a lot of people, ourselves included, think that we're in the business of writing code, but this is actually a mistake. We're doing business Operations, yes, with the capital-O. The only difference is that our tools to get the job done are "our software, our people and other people's software" instead of just "our people and other peoples' software".
Developer is the right title for us most of the time.
"You can't stare at somebody's code and know if you'll like working with them." Sure...and there's not mutual exclusion between the two. Looking at someone's work product is simply another set of data points. I'm not judging someone's fit for a position simply based on a code work product. Or a resume. Or one cultural fit question. I'm using them all to paint a picture and weighing the pieces to determine if I think this person will perform well under the complete circumstances (work/life balance, work required, what team they're on, etc.) Simply put, I've found several different kinds of work products have helped determine positive fit in the past for me.
>> The best process was the one where I finally got a job. We talked on the phone for an hour and a half and by the end you could just tell we had that, "developer bond". His approach was the best I'd seen. He just talked through some of the problems he had, I proposed solutions and we talked through pros and cons. He treated me as an equal from the start. After that we had the face-to-face HR questions (how do you resolve conflict, etc.) which they have to ask because it's a big company, and another one with another manager but by then it was pretty much a done deal.
I've had the same experience, and I absolutely agree. Just about all my best interviews were with someone where we just hit it off and talked deep tech for an hour. On most of these we had to consciously cut the conversation off because we went long. I don't think that, when this sort of interaction occurs, you know the person is going to be good at writing production code. But at least you do know they're the "sort" of person you would expect to be good at it, and frankly none of the other methods discussed do a better job at providing that assurance.
I don't think that, when this sort of interaction occurs, you know the person is going to be good at writing production code. But at least you do know they're the "sort" of person you would expect to be good at it, and frankly none of the other methods discussed do a better job at providing that assurance.
I some times feel that part of the problem with hiring is that people expect too much of an interview process. Whatever tricks you pull to test out people, there's only so much that you can actually learn about people through a few hours of interaction, in a contrived context. Talking tech with developer candidates is great because a) it puts you in a natural conversation, which affords you to get some idea whether you like the person or not and b) it reveals at least something about their technical skill - it's hard to fake deep knowledge, if you don't have it.
That could work for those without a job, but if I'm securely in a job, if I'm going to be switching to a 2 week contract, there needs to be a significant bonus attached.
It's #3 that makes all the difference: a task that means something, and makes it worth one's while.
Duolingo wanted a functioning nontrivial (albeit sparse) app, expected to take 10 hours to write. I found it amusing on its own, but interviewed & got multiple offers elsewhere in less time.
That's actually harmful for getting quality candidates - "hot" prospects nope out of the process when they get an offer elsewhere.
A clever option is emailing the recruiter at Duolingo with something like "hey, I've got a competing offer, so the 10 hour coding challenge is really not something I have time for at the moment. Is there any other way to proceed through the hiring process?" Either way they answer, you're okay with.
I did that before during an interview with a pretty good company overall and the employer refused to accelerate the process or make an exception and just stopped the process.
There exists a continuum of hiring practices which place more or less burden upon candidates. I would encourage HNers with input into their company hiring practices to choose less burdensome approaches over more burdensome approaches, particularly when less burdensome approaches also yield additional signal about ability.
A thing you can expect to be asked in 2016: you can expect to be asked to have an on-site interview in a city you do not live in. (How many people will be asked to do this for the SFBA or NYC? Literally jumbo jets full, this week.) For some candidates, this will involve more than 16 hours on planes, a (minimally) overnight stay in a business hotel, and six solid hours of interviews in the course of an 8~10 hour day. This requires minimally 2~3 days of these candidates' lives.
Most companies keep "conversion rate between onsites and job offers" very close to their vest. To put it mildly: it is not guaranteed that if you're flown out you will get an offer.
If you are hypothetically designing your interview process, and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"
If you fly across an ocean and start bombing an interview, that's a terrible result for everyone. If you happen to be doing a project and discover "Oh, wait a minute, I've really miscalibrated here: this is far above my level of expertise with $FOO and honestly if this is the character of the work then I'm not sure I want to do it", then you have an easy option: simply close the window and, maybe, send a two-sentence email to the person who you were talking to.
Smart use of projects as a filtering mechanism can minimize costs to candidates and the company of administering high-cost testing (e.g. onsites, long projects, etc) to candidates who will ultimately not be successful at receiving offers and/or defer the high-cost assessments until the anticipated chance of receiving an offer is "very high."
>For some candidates, this will involve more than 16 hours on planes, a (minimally) overnight stay in a business hotel, and six solid hours of interviews in the course of an 8~10 hour day. This requires minimally 2~3 days of these candidates' lives.
... To put it mildly: it is not guaranteed that if you're flown out you will get an offer.
..., and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"
All true but my observation is that the companies that put candidates through multi-day-out-of-town interview processes can afford to miss out on the candidates that can't do it. Tellingly, the type of companies like Google and Microsoft that put a lot of burden on candidates hire heavily from a pipeline of fresh college graduates. Not surprisingly, a lot of 22-year olds don't have existing jobs or kids they have to juggle to commit to intensive interview processes. Sure, they also interview older middle-aged candidates but the benchmark tolerance for hoop-jumping is set by the 22-year olds therefore you won't get sympathy from employers about disrupting your life to stay in the running. For those companies, even if they are flying you out, you're still in the "evaluation" stage and could be 50/50 accept/reject.
Contrast that with boutique consulting firms that hire from the 30+ age bracket (often by poaching other consulting firms' employees.) A lot of their candidates already have existing (lucrative) jobs. Most of their evaluation is
done on multiple phone interviews. If the company decides to fly you to their headquarters to interview, you basically have the job unless you unzip your pants and urinate on the interviewer's desk. The onsite interview is not a technical screening but a personality sanity check. At that stage, you're 90/10 accept/reject.
When many valley companies look for senior people (and they do), they still use the same mechanisms to hire those 30 somethings out of consulting firms. And that's when they have a 1/4 on site to offer ratio(es, that's an actual ratio of senior engineers that pass the phone screening.
In one case I know, the interviewing + travel took two work days and two nights. That's thousands of dollars for a consultant! Add to that the grand or so of travel expenses for the company, interviewer time and overall, every senior hire costs applicants + company well over ten thousand dollars, past paying the recruiting team.
Compare that to a company that does the whole process over Hangouts/ScreenHero. The waste is amazing.
>Sure, they also interview older middle-aged candidates but the benchmark tolerance for hoop-jumping is set by the 22-year olds therefore you won't get sympathy from employers about disrupting your life to stay in the running.
So basically they find a legal way to discriminate against older candidates?
If I had some process that fit male candidates far better than female candidates, with no clear benefit compared to other processes that had less of a biased fit, would that be a problem?
> All true but my observation is that the companies that put candidates through multi-day-out-of-town interview processes can afford to miss out on the candidates that can't do it.
All companies can afford to waste less money than they need too.
Perfect, I've done +-4 onsite interviews and only got accepted in one of them. I get really nervous in on site interviews being judged by usually two people at the same time while I try to solve something.
One company in Amsterdam, just last week, I went through a four step process, the last one being the onsite interview. I did really well in the first two, but then in third I went with a wrong approach to the problem and couldn't get my mind in the right position again. The person judging me just kept putting pressure. I got really nervous and couldn't do any more interviews that day... my mind really got completely blocked for the rest of the day.
That happens and, really, the company spent so much time of me (and me on them) for everything to be decided on that? feels wrong..
> Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice?
I'd say 8 hours is too long. I always strive for a 4 hours, but I've seen that 4 hours chop 16 hours off of the candidates time and more than 32 off of the companies.
> What's the point of maintaining an online portfolio and a github profile full of code
The vast, vast, vast majority of candidates do not have an online profile full of code. Either because their code is IP restricted or they do not have time outside of work to maintain that. I view using online profiles as a decided anti-pattern in hiring on the company side as it restricts your candidate pool to a tiny subset of the community that I've seen no evidence provides any more value in outcome and its much more prejudicial to the candidate population than any coding assignment can ever be.
We ask candidates to pick a work sample of something they already have, if they have one they can provide. If they don't we give them a relatively painless coding test instead.
It's not perfect, it'd be great if everyone could have a work sample but as you say that's just not the world we live in.
I appreciate this approach. I'd love to be more active with outside-of-work projects, but my days are usually already full. And I can't provide a lot of code samples because the majority of my work is IP.
This is true for most good people at big companies. Your day is already 60 hours long, and your company forbids (via IP ownership) coding outside of work. I fear that most of the interview approaches pointed out in this thread select against people who are already successful at well-regarded companies. Don't you want people like this in your interview funnel?
You'd be surprised. There are an increasing number of folks who get to at least occasionally work on open source projects as part of their day job, and many other less obvious ways of getting a prior sample. But if they don't have one we don't hold it against them for the reasons you cite
Exactly. Furthermore my experience has been that requiring prior work samples unfairly biases towards younger developers. Our system is far from perfect but it allows us to see prior work where possible by provide a fallback when it isn't
I was one of this vast majority once, so I know how it feels. Eventually though however slowly, but I've gathered enough code samples on my github account, samples that are actually rather unique and at the same time useful and getting starred. It takes time, polishing, sure, but as a result quite a few companies stopped asking me doing coding tasks, so I'd say in the end it's worth it.
Exactly. My after-work profile consists mainly of my non-driving kids getting to their non-school activities on time, the custom-built furniture in my living room, the lawn calibrated to give the HOA conniptions without actually breaking any covenants, the brake fluid level in my 2001 car that is definitely leaking it very slowly, my almost-completed low fantasy novel that I started for NaNoWriMo in 2012, DIY pajamas that my kids wear, a well-socialized terrapin, and yes, even all my online gamer achievements.
The reasons I don't like long coding assessment projects and the reasons I don't already have an example code profile are the same. Reinventing all the same wheels in different programming languages just isn't as fun for me as it once was, and I don't have as much time to dick around with any specific side project, especially ones that don't have any immediate utility to me or my family.
Does anyone ever ask about how I spec'd, designed, built, installed, and maintained my DIY entertainment center? No. Same methodology as building software, you know, except the problems are solved with different tools from a different toolbox.
If you're truly really looking for someone "T-shaped", you have to realize that the tittle on that T might include things entirely outside the realm of software or computer hardware, like how to hang a bear bag when camping, or how to fly a small single-engine aircraft, or how to train cats to use regular toilets, or how to run for political office, or what to do when you get a flat tire, or how to hold someone else's baby, or how to hit a gong target from 300m, or how to make a longbow for under $10 at Home Depot, or how to report a pothole so the city will fix it, or how to repair a pothole when the city won't do it, or how to play "Flight of the Bumblebee" while slowly rotating your B-flat concert tuba through 360 degrees.
All those miscellaneous, general-purpose skills do, in fact, make someone more effective at quite a lot of software-related tasks, sometimes in unexpected ways. But they are never going to appear on a resume, or crop up in the answers to any of the stock interview questions. When you include a criterion that specifically selects for people whose after-work hobbies also involve software, you are implicitly selecting against those who do other things, because there is much, much more to life than writing code.
There was only a very narrow slice of time when I actually wrote code for fun in my free time, from the ages of 15-25. It basically stopped after I got laid off from my first software job, and interviewing for software jobs became my next full time job. That's when I realized that I needed to do other things in my life, because it didn't matter how much I loved software if it didn't love me back.
So if you think need a portfolio to get a job, you might want to build one up that includes more than just code samples. The software industry does not love you back. It will move on to someone younger when it gets bored of you.
Seriously considering putting a write up of how I repiped the natural gas lines in our house. One inch pipe to the utility room, valves on all tees and a stub for the meter so I could pressure test the whole house by zones at the first tee after the meter.
Systems, problem solving, engineering. Happens everywhere not just on a computer screen.
Leaky brake hydraulics aren't anything to mess with, you should fix it or have it fixed soon. It could be something (relatively) harmless like a common hydraulic system shared between the clutch and the brakes (VW uses this design, perhaps others) in which case a failing master/slave cylinder in the clutch could cause the level to drop without compromising the brake system, but even then, soon you will be clutchless. But barring that unusual circumstance, the brake system is compromised and that's dangerous.
Otherwise I agree with what you said, and the best way to tease those details out of a candidate is to have an informal, personal discussion like getting lunch or getting beers together. But that's not enterprise scale.
Funny you say that, I once worked for someone who interviewed potential product managers by asking how they would spec, design, and build their own entertainment center. Seemed to work pretty well.
For promising candidates, we ask that they complete a pre-specified project in their own time. The project takes most candidates 2-3 hours to complete.
The difference is that we do this as paid work. Whatever their going rate is, we'll match it.
A surprisingly high number of candidates interview quite well and look promising on paper, but fail horribly in a "real world" coding test.
That sounds entirely reasonable; by paying, you're respecting the time the candidates have to put aside and chances are it will motivate people to do better.
(I'd send this in email, but I can't find one in your profile)
What company are you talking about hiring for? I'm looking for work as a programmer, and I'd prefer to apply to places with a hiring process like this. You can find some code I've written (a server clone for www.stockfighter.io/) at https://github.com/bcoburn3/forex
My email is bcoburn3@gmail.com if you'd prefer to respond that way
The time involved in these things really can add up... I was recently asked to do a take home challenge that took a couple of hours to hack together, followed by several hours of nailing down edge cases due to the nature of the task. Then the company scheduled a phone call during which I thought we'd discuss the design decisions I'd made while working on the task. Instead, the interviewer had never seen the code I sent in, didn't even know which challenge I'd done and had me screenshare-coding brainteaser puzzles for over an hour on the phone. Talk about wasting my time.
Often these things are scored and ranked separately. Your phone interviewer will likely have scored you on various things, the score from your coding challenge will be taken as well, then everyone will sit down and discuss how people did and rule people in/out.
The only purpose of a code challenge or whiteboard session is to get the candidate and the interviewer talking about code. This is the only signal that you really want out of these exercises.
To do both is wasteful, but if I did either and that _didn't result in a conversation about code_, I wouldn't continue with the interview process. Their processes are broken.
That depends heavily on what they're actually screening for. I've received an embarrassing number of utterly atrocious code challenges from candidates in the past. If you can't code something like a roman numeral generator/reader (when allowed to do so at home, in whatever language you want, spending as long as you want on it) then continuing the interview process at this point is a huge waste of time.
In those processes, the purpose was to weed out people that simply could not code at all. Or even cheat, since there are solutions all over the internet for any language you want.
A later stage was to do some programming with us, and we'd talk through issues and see how they dealt with problems/etc.
Call it what it is then. It's not a challenge but a weed-out. I know full well that that's what your company is screening for, but that also means that I know that I don't want to work for you. My time and contributions will not be appropriately valued by such a company and I won't like working there. My skills/value are not commodity. I don't want to start out a hopefully multi-year relationship on dishonesty.
I imagine though that if you explicitly call it a weed out that a sizable percentage of the quality talent pool won't apply...unless they're a referral, and then why are they doing a code challenge anyway?
On that note: giving code challenges to employee referrals, especially hiring to their own teams, is a clear indicator that you don't trust your employees.
I guess I'm not really sure what the difference is, the entire point of all hiring processes is to "weed out" those that you don't want to hire. Otherwise what's the point?
> My time and contributions will not be appropriately valued by such a company and I won't like working there
I don't get how that's related.
> I don't want to start out a hopefully multi-year relationship on dishonesty.
There's no dishonesty there, the applicants were given a simple task to do in order to progress to the next step. If you're applying for a software engineer position and cannot even make a decent attempt at an extremely simple task when given complete flexibility then it's a waste of both of our time to continue.
(edit - I should point out that this was not at my current employer)
In many ways, I see these projects as a stand-in for the kind of comprehensive professional exams taken in many other fields.
As developers, we often take a 5+ hour whiteboard interview on some of the fundamentals of CS, but presented as challenging problems. We may also have to do a take-home "project" which can be viewed as a "practical" component of a comprehensive.
I don't object to this per se. What I dislike about it (as I've mentioned on HN before) is that we take these exams without the protocols that evolved over centuries in exam-heavy institutions (universities, professions) to safeguard against abuse ensure the process is fair and decent to the people taking the exams.
The exam must not be capricious, it must be relevant and consistent across candidates, it must be created and assessed by competent members of the profession, there must be an associated study path, the content of the exam should't be a huge surprise to the candidate, candidates are provided with feedback should they fail.
And, perhaps most importantly, the process of taking and passing the exam provides the candidate with a certain stature, a lasting credential that is widely respected in the profession. The candidate doesn't have to re-take this exam over and over every time he or she interviews (in many ways, that is the point of the exam).
In many ways, I feel that programmers experience the downsides of this sort of professional entrance exam but without the positives.
I'm glad to see this discussed on HN, because I really do think that software "interviewing" as entrance-exam is one of the things that eventually drives people out of the field (or causes them never enter it in the first place). It's not a good thing for our field.
I'm not saying it's an easy question with an easy answer, just that our current approach is failing.
I for one have "walked out" of any interview that has asked me to do a take home assignment. Usually, the request for the take-home comes early enough. This shows me that the engineering team is too busy with work to even give time for a 30 minute shared text editor code interview. If we all refuse to do it, this crap will stop.
I balked at a take-home. They agreed it was a nuisance, instead hired me for a week to work with their team as a contractor! At my rack rate. That was a great experience, didn't hit me in the pocketbook, and convinced the team we could work productively together.
This is a good idea. Doesn't work for people on visas but I can imagine working this out somehow. Basically, make the potential employer realize that your time isn't free.
I don't really agree - I remembered a take home assignment which combined enterprise-like object-oriented design (data model, strategy) with algorithmic thinking (several flavors of graph traversal). The job also turned out to be top-notch before the company was bought by a certain trading firm which has 2/5 (and falling) on glassdoor. 9 months later it was pure shite. it was the best team i ever worked in though - still keep in touch with some of the guys :)
I'm helping hire developers here at HelloFresh and I thought of this a lot.
A surprising amount of people don't maintain a very impressive public profile (me included, tbh). These people need the opportunity to showcase their skills and the only way to do so is by spending some time coding a nice solution.
We try to minimize the candidate's overhead by providing general guidance in the challenges we issue (like "please demonstrate the SOLID principles").
Then we do a code review on the solution, in which we also spend some time. We point out issues, suggest possible improvements and give props on stuff we consider well done. At the end, if the candidate doesn't progress they at least learned something useful. We hope that this way our recruitment process might always be worth the time.
You're on the phone with them, you can ask them if they'd prefer a little challenge to showcase their skills, or whether they'd like to provide a portfolio example instead.
Maybe a bright self-taught college student switching tracks into software would pick #1, a parent switching jobs would pick #2.
I'd rather spend 8 hours programming than burn a full day on 5 whiteboard interviews the way Google does.
More generally, I think the target should be to make the work sample test take a similar amount of time to the in person interview you'd have to do instead.
I've been looking into changing jobs and yes: it is a huge time sink. Traveling to interviews, being available for phone calls, preparing and researching... Especially the smaller companies are struggling to set up a good hiring process. I tried to discuss salary ranges before going into interviews to filter out some companies, but it didn't help. One recruiter put me on a one hour train ride, turns out there was some miscommunication about the job description..
However I really liked the Thoughtworks challenges and couldn't resist coding for eight hours. It's better than spending one hour on-site for a badly designed 'challenge'.
The way a company signals their respect for my time is by either compensating me for the time I spent on them instead of literally anything else, or by demonstrating that they are spending an equivalent amount of time on me rather than anything else.
If I am doing a project that takes me 8 hours, that company should either be writing me a check (for somewhere between $100 and $500, probably) or planning the mother of all individual sales pitches to convince me to not just work there, but also to go the entire distance through their interview process.
No company has ever done this for me. Every last one of them has expected the candidates to spend as much of their own time (and even money) as necessary. Several (all of them in Denver, possibly by coincidence) have even reneged on paying travel expenses. Tyler Tech in Lakewood, CO, tried to get out of paying for my hotel room, declined to spring for a rental car, and remains to this day the most hostile interview I have ever suffered through.
Reneging on paying for interview expenses is the most scummy thing that companies regularly try to get away with (well, OK, no it isn't, but in this industry it is, mostly).
That's exactly why I tattle on this particular company--Tyler Tech, in Lakewood--at every available opportunity. (In the U.S., truth is sufficient defense against defamation.)
They also had me drive my own car from Madison to Milwaukee, to catch a flight that actually stopped in Madison after the first leg, just so they could save a few bucks on the airfare. And then they refused to pay for the mileage between Madison and Milwaukee, after promising earlier to reimburse all my travel expenses.
I put up with an awful lot of inconvenience from interviewers without comment, but every little slight is ratcheting up the minimum acceptable offer from that company. And if you act like sleazebags at the interview, you had best be prepared to lose any candidates with an ear to the grapevine.
Of course not, but it is (or at least should be) a two-way process. If the interviewer wants you to invest hours of your time this should be respected; either by paying for it, or at least by being sensitive to the fact that people generally apply to jobs while already employed somewhere. So don't give them a 24-hour deadline on a programming task that takes 4-5 hours, things like that.
I interpreted that as "after 8 hours of work at my regular job", not "8 hours of working on the project". Otherwise, why is he thinking about it on the train, and talking about how fun working on it that night was?
This almost always comes up in work sample discussions. There is a fairly obvious reason those of us who advocate for them don't do that. It would rule out a large contingent of the candidate pool who have signed agreements not to work for money without prior approval or notification to their current employers.
It also opens the hiring company to potential liability with regards to IP laws if you are hiring in a similar industry.
Maybe this is a bit rant-y, but "Paid Fairly" is incredibly relative. Every time I've been asked about doing some sort of paid coding assignment in my free time, I've asked to be paid at my hourly consulting rate, which many people do regularly, which is $60/hr. This is really not that much for a consulting developer.
Every time this has come up, the company would not pay that rate, and offered something more like $20/hr.
It is just insane to me that if you are interviewing me for a position which makes $105,000 a year and cannot offer even close to equivalent compensation for the interview.
I have the same issue. It costs me hundreds of dollars to even agree to an interview, at my hourly rate. To further ask me to do homework is to bilk me for thousands. I cannot afford to apply for most jobs, as long as I have a consulting backlog. Which I almost always do.
Do you interleave full-time and consulting gigs? If so, how does that work in practice? Wouldn't doing a fulltime job for a while tend to dry up your client pipeline, as they find someone else for urgent work? With that in mind, when is it worth it to even try to find a fulltime job? I'm about to start my career, and wondering how hard it is to walk the line between consulting and "regular" jobs.
As you mention, having a client pipeline is the easiest way to find contracts. My last fulltime job came out of a contract - they wanted me on board. Worked for a few years, then they changed direction.
I thought work might have dried up. But I got a call the next day from somebody who had dug up my number in an old rolodex, desperate to get me to pick up the slack on a project. So, right back in the saddle!
That works better if you have 10 or 20 years of experience at different places. So there are people out there thinking of you.
I'm pretty sure this is in reference to the his project that he was wrapping up at his old job.
He is saying that even though he was working long hours at his current job, he was so enticed by this interview challenge that, even after a long and difficult day thinking about a (programming) problem, he couldn't keep it off of his mind on his train ride home.
IMO the upper limit should be a couple hours, but I'm not sure that should be communicated to the people interviewing because it can stress people out.
> What's the point of maintaining an online portfolio and a github profile full of code if companies prefer to waste your time writing a pointless uploader?
There are a few problems with using GitHub or BitBucket profiles. First, not everybody has them, or they don't update them frequently, or whatever. Second, it's pretty easy to fake a GitHub profile by copy/pasting code from other places, using other people's code, or pushing broken stuff that doesn't really work. And third, a lot of people's GitHub profiles are cluttered up with a bunch of forked repos that they haven't even pushed code to and don't really contribute to at all.
If the project is designed to take that long, it's ridiculous. The project we give at my company should take maybe an hour if you know the framework we use.
There are enough employers that you can avoid ever doing these coding challenges. Any time I've been looking for work, maybe 2 out of 10 companies would ask for these challenges, and I would skip them while interviewing at the other 8. I always ended up with several good offers before ever wasting my time on the coding challenges.
You're free to your opinion, but, you probably should be. Any company that deems your time worthless for the interview probably feels the same way about your time during the work week. Maybe 60-80 hour death marches are your thing, but, that's not a perk I am (and I suspect many others are) looking for.
It's better than a 5 minute brain teaser question. Any job worth having is worth spending 8 hours applying for. Anyone who views this as "free work" probably won't be a good hire for other reasons.
In my experience, asking candidates to read and explain someone else's code is a much better indicator than letting them do some whiteboard programming.
Similarly I've found that talking through some deliberately broken code, and what improvements could be made to it, gives a good idea of what a candidate would be like to work with on real problems. It's more about the discussion than the code changes they come up with!
Agree 100% especially since that's most of the daily job is fixing up old code that was written in a hurry or for a different circumstance.
The ability to see what some code was trying to do and how to fix it and make it extendable and or understandable for future generations is invaluable.
This is a great point. Most programming jobs I've seen are about 10% writing new code and 90% maintaining / fixing / extending old code. I'd rather know that you can jump into a codebase you've never seen and get productive quickly than know that you can invert a binary tree on a whiteboard.
I think a coding test is the wrong approach. Typically a coding test is too simple to be meaningful, or too difficult to be practical.
Instead I would have a Mock PR in a github style discussion forum. Have it be a contrived example of some things that could be improved or some things that could spark really good discussion. Give the mock PR link to the candidate and ask them to Peer review the code. Make the discussion and comments of the the candidate the basis for which you determine their aptitude. If they have a lot of depth in their critique then you can be relatively confident how they would interact with the team in a real work scenario.
I can see the value from a hiring perspective in asking candidates to code, but it's no panacea. The bias in the interviewing process that so many acknowledge still bleeds through into many of the coding projects in the form of prescribed languages or frameworks. I suppose there's some merit to that if the intention is to screen for experience in a particular language or framework, but it does run counter to the commonly-expressed sentiment that companies are looking for smart developers who are able to learn new technologies rather than developers who have happened to use particular technologies.
As a candidate going through the job search process now, though, I have to say that it gets tiring to do a project or programming test for every different company. I can juggle more traditional applications (phone screens, on-site interviews) at a time than applications that require coding projects as I'm limited by the number of 4-hour (or 8-hour or whatever) blocks of time I can devote to completing a project for each one.
I just instituted a coding assignment with our hiring (exceptions made for those with extensive github/similar open source contributions), and so far only have had three candidates do it, but I'm a fan.
Mine is crafted so a really competent developer could get it done in 30 minutes, and intermediate 2 hours and a junior probably not finish. I tell them to send what they have in after two hours that I'm as interested in seeing the structure and thought process than the final result. It seems much better than having someone do it at the office or one a whiteboard for accessing basic competence.
Yes it sucks, but after you get bit once or twice by hiring people who knew all the right words but can't actually produce something useful you get a lot more open to it. I'll gladly take the time to take you out to lunch to discuss the job and code assignment and give feedback afterwards, investing a couple of hours into finding your next job shouldn't be this huge ordeal and gives off a diva vibe I don't want in my organization anyway.
>I tell them to send what they have in after two hours that I'm as interested in seeing the structure and thought process than the final result.
While this seems like a good idea on paper, you know that people are not going to stop after 2 hours unless you force them to (i.e. by doing the assignment on-site).
>get it done in 30 minutes, and intermediate 2 hours and a junior probably not finish.
What kind of exercise could a junior programmer not finish? Give up or produce miserable code sure, but not being able to finish? Do you require some really strange domain-specific knowledge?
PS: The website in your profile doesn't seem to be working.
well with 3 attempts one went over and kept working until he got a solution (took a while), another stopped at around 2 hours to submit and asked for feedback, 3rd finished in time and is a badass.
You've be surprised. Maybe I expect too much, but the assignment is essentially network aware k/v store with a single get command and set command. Extremely poor mans redis and a step up from an echo server but for some people doing anything over a network that isn't HTTP breaks them.
Thanks for website, my consulting/blog site that pretty much fell into disrepair after taking architect position at a startup.
Are your company especially desirable? Because if not, why should I invest 10-20 hours across ten companies to get one job? Sure I may get lucky and get hired the first place, but thats not very likely, no matter how good I am.
To me requiring me to waste that much time indicate the company being a diva, something I wouldn't want in my employer.
I'd like to think the company is pretty desirable and building something legitimately special :)
10-20 hours invested to find and and sell yourself to the job you'll be spending the next year at (optimistically 1% of the working hours during the next year and realistically a lot less) seems like a good use of time to me, but to each his own.
A lot of people here seem to suggest it is unreasonable to ask someone to do some coding in an interview given that you've shown a series of projects and provided references. Unfortunately I've been through a variety of interviews where I feel the conditions which I was asked to code were unreasonable (whiteboard, overly complex problems while under pressure, using a language I was not comfortable with or just academic problems that are rare in the real world), but I really think confirming their ability to write code, beyond things like github repos etc, is an important step of hiring a developer (because i've seen great github repos and references, but ended up with developers that are very, very average)
I've only hired tens of people, and while that is not a massive sample size, I'm still astonished by the simple questions we ask that people get stuck on. The one that continues to shock me:
"In any language of your choice, write a function that takes an array of ints and returns the sum of those ints (If you use a language such as php do not use array_sum)"
Then we follow up with something like: "lets say your input array contains [4,-7,0], walk me through the code"
And we finally ask "talk to me about some things that could go wrong at runtime that might cause issues with this function". Expecting people to talk about overflows (maxint?) or if its a dynamic language like php, checking for non-integer values.
I estimate that around 50% of people get ruled out during the "coding" exercise mentioned above. It is astonishing that these people even apply for developer jobs.
Imagine there are twenty candidates who can't code at all, so they apply everywhere. There are also twenty candidates who can code, but are presently unemployed because they all worked for SpoonRacket.
Now the entire lot apply for jobs at your company, and you hire two of those who can code. Within 3 months the rest of the good ones have found jobs, but 30 others have temporarily been unemployed and none of the bad ones have been unemployed.
So you interview again and roughly 40% of the programmers you interview can't code. But that doesn't mean that even 5% of the programmers out there can't code, it just means it is the same bad programmers that interview in lots of places.
It is the same when employers say they are getting ten or twenty job applications for every open position - that doesn't mean anything because everybody who is unemployed applies to more than one place, but from only one side of the fence it sure looks like that.
Yeah, lots of people who are not amazing applying and having to be filtered is a key challenge for anyone trying to hire at scale. In fact the key issue that this question is intended to address, so I agree with you.
I would never want to suggest that 'most programmers are bad' or anything like that, i think the real issue is that people who are not really great programmers apply for jobs that are beyond their level of skill at the time of their application.
I'm not sure I'm following, do you mean that the company may not be extracting optimal performance out of them? I'd agree, great people don't always do great work, often simply due to the environment they're in.
Having said that, i think when people have a great personal Github repo where it appears they should be able to answer the above question, but in practice cannot do it without looking up the answer on Stack Overflow...then there is an issue.
If a company asks me to do 8 or more hours of artificial coding test I usually refuse, unless I really want to work for this company (because it is well known in the community, which are few).
However, I'm happy to work on any real task for a reduced or limited fee. It's a win-win: the company gets to know the candidate under real conditions, has an actual task solved at a reduced price, and the developer does not give away his/her time for free. Plus, if it works out, the candidate has learned already the first steps about the company's system and process and can directly build on it.
I'm always wondering why not more companies do this.
The process I've seen working best to this day was at Pivotal Labs: pair for a half hour to one hour with 3 different people in the team you're being hired for. You get to measure everything, from communication skills to cultural fit. Perhaps pair on an internal tool, or even better, an open source project (in which case the candidate gets an extra incentive for not wasting their time).
If you're dealing with too many candidates, issuing a simple 1-hour coding challenge will weed out the uninterested (and won't favor people that have 4-8 hours to devote to a huge coding challenge).
I've interviewed there. Only two people I've paired with, one in the morning and other on after lunch. I had two problems:
* The 2nd guy I've interviewed with was completely non interested on doing it. He was checking the phone all the time and getting off and on. I felt so awkward because of his lack of interest.
* I didn't get _ANY_ feedback at all, just got refused. After 6hours in their office...
The problem is, there are no realistic 2-hour, or really even 4-hour, coding projects that faithfully map to on-the-job skill. 2 hours is too long for a data structures riddle, but way, way too short for anything of even a tiny degree of complexity. Let alone writing some unit tests, mocking up a design and then scrapping it for something that makes more sense.
Timed coding tests are just a waste of everyone's time, whether it's a weekend take-home thing, or a 30 minute whiteboard thing, or anything in between. They do not account for individual developers' needs, like privacy, their own editor or IDE, and they exist in this ether between bullshit trivia and an outright working internship that ought to be paid.
The other huge thing is that in a lot of firms (I doubt Digital Ocean is like this, but many firms are) "programming" is a low-status, junior activity. In these companies, if someone asks you to write code in an interview, especially if you are an experienced candidate with a GitHub profile, references, and project experience, then even merely asking you to code is more like saying "dance, monkey, dance" and setting the whole atmosphere of your negotiations and interviews in such a way where you are the lucky low-status person who should be so grateful as to receive a job.
Unless you get a really great cultural feeling from speaking with technical team members first, the best general advice is to simply reject employers who ask you to write code. If they ask you to write code before even speaking with you, absolutely reject. Full stop.
I also think all candidates should fully reject internet-based timed "exams" as well. Things like HackerRank are designed to commoditize software labor, which is a creative design activity and if it even can be commoditized at all, it surely can't be boiled down to data structure trivia that you have to code around in a browser-based IDE with a literal clock ticking down.
Anything like HackerRank immediately screams "quantity not quality" and is straight rejection-worthy, no questions asked.
When we hire, after a few phone interviews we give the programmer an in person coding exercise that is very basic. Open a file and parse data, etc... They can use the internet. It's very basic. 80% of the candidates cannot do that. I'm not exaggerating. Maybe I'm missing something here, but it's pretty astonishing to me.
Do you require them to do it in a specific language or let them choose which one they are most comfortable with? How do you decide which programmers to bring onsite? Have you considered giving them different options in the from of doing a take home test or coming in and coding inperson instead?
We require a specific language... the language we use for the job. The phone interview asks technical questions, a few design questions, and some personality geared questions. The technical questions are basic and cover some of the basic concepts of the language and basics of OO.
We haven't considered doing a take home test for 2 reasons. 1) We want to see how well the person can get around windows/keyboard. I believe this is important. 2) What we are asking to code is very basic. If we sent something home it would have to be harder.
Are you thinking that the in-person coding would make them nervous? I ask because we are clearly doing something wrong if it's hard to find candidates that can do basic programming. Even if the person is entry level, that would be fine as long as they are an A player at the entry level... if that makes any sense.
Valid points as far as the language goes, but I'm not sure I agree with your points about workflow... the primary goal should be to see if they can reach the solution using the tools required for the job over how the tools are used in my opinion, and how much guidance they require to do so. I am thinking that the in-person coding might make them nervous. As a personal example for my specific line of work coding is more of a secondary requirement over having knowledge of how systems work, and despite having contributed code to some widely used open source projects and having enough knowledge to get by given language given enough documentation, I would likely freeze up in an interview if asked to code.
If I were you I would look for candidates that actually have some projects they can showcase that proves they know how to code, and offer them the chance to either do an easier in-person test or a take-home project. During the job search I personally jumped at the chance to do take-home projects since I view them as learning experiences, but for more experienced people I can see them being viewed as tedious. Most truly passionate entry level programmers looking for their first job and some direction I hope would jump at that chance to get some more directed experience as well.
That does not surprise me -- many web developers only do web development. They use frameworks for database access, and rarely, if ever, do direct file access. And parsing data? There are libraries for that, right?
Sure, you would think that would be a trivial task for a professional coder. But it is amazing how much you can accomplish without ever having to do anything other than model some data, write some business logic and security around it, and build a front end. Frameworks FTW. The downside is that they don't know how to code without the frameworks.
I don't doubt what you're saying, but in my opinion, if you can't write code outside of your chosen framework... you can't write code. It would be like calling yourself a mathematician because you passed 8th grade algebra. You learned some math tools, but you didn't learn math. (Not you specifically of course, the hypothetical "you")
Parsing data is a very low barrier to entry. Likewise, a person that can write an ORM data model without understanding the basics of a database is a disaster waiting to happen. If you don't understand the primitives you're working with, you're hopeless when the abstractions you use inevitably break down.
One thing which I've wanted to see a company try is to give someone code to read and asking them to walk through how they would go about understanding it. I've done this once when I worked at MassChallenge and was trying to hire a more senior engineer to work above me and I felt like it gave me a good idea of his ability to talk through problems and work with others, but that was only one interview and I'd like to see a larger sample size.
Calcado describes his wish that the candidates be "more T-shaped", and not just worker bees with narrow skills. But I see no mention of ways his more successful hires "branched out" and expressed wider interests or capabilities, presumably in in domains outside computing.
Here, do the T branches apply only within computing, like knowing more than one software tool? If so, I think that's not what Tim Brown meant.
Presumably an interview seeking signs of "T-branching" would propose higher level questions, like business acumen or domain curiosity or spontaneous Q&A to better understand or elaborate the requirements needed to solve a representative problem. Otherwise the "T" just equates to broad software skills.
not sure why there is so much resistance here about doing an 8 hour test, I might be in the minority but for a traditional whiteboard interview I would spend a lot more than 8 hours revising algorithms and so on, and have a lot of stress due to whiteboard coding not being anything like real coding.
Being able to take a Sunday to work on a challenging problem in my own editor / computer / dev environment sounds great! I wish that all companies added in their job ads something like 'if you want to skip the whiteboard send us your solution to this problem together with your resume' where the problem is a representative problem of the type of work they do, then you spend the interview discussing your solution as opposed to playing algorithm-roulette.
It would also cut down the uncertainty when you see a job ad where they ask for all sorts of different languages / skills, if you have fun doing the coding test, it's likely you'll enjoy working there, and vice-versa (in which case you might decide not to even apply)
> not sure why there is so much resistance here about doing an 8 hour test
If you're applying to just 5 companies, that's a full (well 40-hour) work week of effort for a small chance of going forward with the next stage of the interview/hazing ritual. Might be good if you are already unemployed, but incompatible with candidates who already work.
I ask them to give me a full design document with their coding style guide. Since it's an 'easy test', this is my 'easy test' to check their procedures.
They should already have a coding document in place and they can use their boilerplate document to quickly whip up a design doc. Right??!!?
Which means that, if you're hiring, and you want only candidates who are currently unemployed, it's a reasonable practice. But the best candidates probably already have jobs, and you're not going to get them. So maybe that's not really the way you want to do things...
not necessarily, if I am not unemployed I am not likely to apply to tons of jobs, but be a bit more selective, and I don't see finding more than 1 job a week that I would be interested in... of course I am not a typical developer (C, python, back-end, security, networking, ...) so there are a lot less jobs in my niche than say if I was a front-end person
This means that taking every sunday to work on cool / interesting self-contained problems would be great, and much better than spending time revising red-black trees and avl tree rotations and sorts and so on for the n-th time to prepare for the whiteboarding
Because usually you're not applying to just one company, but several. And as you get older, you'll have other things to do outside of work, like family, which makes finding that 8 hours extremely challenging.
I like the 'simplified job description'. All too often a job description is simply a list of technologies the last guy claimed to be using/have used/knew something about.
I've only had to do 4 of these, as they aren't that popular in my corner of the earth yet, but I didn't like them, I have a kid and stuff to do and I can't spend my time doing 4 hours extra on the weekend unless it is a job I really, really want.
First out of the 4 I did what was asked but got refused because I didn't clean up the code afterwards ( I thought I'd been cool for demonstrating some lesser known functionalities of the language and API I was dealing with). If I've spent 4 hours doing it, I don't want to spend 2 hours making it really pretty.
Second out of the 4 I misunderstood the instructions so I went in and 'fixed' their code to make it work they way I thought they wanted it ( was maybe too tired since it was late at night after a day of working on a personal project) This was actually a job that was close to one I really, really want.
Third out of the 4 I can't remember anything about it now.
Fourth out of the 4 they really liked what I did and we had a great interview, and then I got turned down because they thought I wasn't really that interested in their company (which was true, I was just fulfilling a job search requirement while getting my startup going)
Aside from that I interviewed at a social analytics startup one time and we ended up talking data mining and they asked me to do a 2 weeks project with them to do a POC of sentiment mining Twitter/Facebook. I gave them what my consulting fees would be, but they seemed really interested in me doing it for free as conditional for pursuing employment there. So I never got to try that coding exercise.
I wonder if maybe instead of asking people to code on the fly, it would make more sense to ask people to review, analyze, and explain some existing code.
A few years ago I was given a programming test after an initial phone screen with a HR person. They said do it in any language, and it had a fancy framework that let you edit and test the solution before you sent it.
I chose Clojure since I was learning it at the time. The problems were easy and I made working solutions, but the framework wasn't working. I gathered some call stack data and sent it to the people that make the tool. They thanked me for the feedback and later fixed the bug.
I sent the completed code by email to the company with a note about what had happened. Showing clearly that my code works in the form of some tests.
> we would ask you to use just your language’s standard library, no third-party libs or frameworks... With the problem description, we sent to candidates a functional test suite, a binary that when started would try to connect to the candidate’s server implementation, open lots of sockets, sends lots of messages, and verify the results against what the problem description stated. The candidate was instructed only to send their submission once it passed the functional test on their local box.
Incidentally, this is exactly how the "Sun Certified Java Developer" certification was structured. You were only allowed to use java.* and javax.* packages provided as part of the JRE, and even among those things like the SQL packages were off limits. Instead of sending a test suite, they provided an interface you needed to implement and then when you submitted it, they had some sort of test suite that tested your code for conformance to the spec (and if it failed, you failed). If it passed, someone would manually review your program to make sure it made sense with respect to the requirements (which were intentionally somewhat vague, like real requirements) and if you passed that step, you had to write an essay about WHY you made certain design decisions (like sockets+serialization vs. RMI, etc).
This was by far the most challenging and fun task of its type that I've done, and to this day if I see that someone has that certification I know that they have what it takes to get things done. This methodology should really be utilized more, although for many companies the overhead of designing such a challenge would be way over the top. Makes me think that things like https://www.stockfighter.io/ have a future in our industry.
Well, you can’t give people stuff to do offline because they cheat (you’ll see the whole thing show up in no time as a Stack Overflow question). And you can’t avoid coding questions during interviews because it is astounding how much people lie on résumés; seriously, even people who describe their background as “Advanced Knowledge of $LANGUAGE”, can choke when asked to do the most trivial things in $LANGUAGE.
I try to ask questions that aren’t completely ridiculous, but definite tests of knowledge. And in my mind I judge correctness not so much on remembering obscure syntax but on how they approached the problem, and how much time it seemed to take them to start doing something. I always ask about things like how they approach debugging, testing, etc. because these are important too and they tell you a lot about how likely the person is to be able to handle any problem you come up with.
Good for initial screening, but should not take more than 30 minutes. Else IMHO laziness or incompetence asking a programmer to do an assignment. Any good manager/developer/interviewer can sit with a candidate for 1-4 hours and determine if his skill level and personality match the job requirements.
"we sent to candidates a functional test suíte, a binary that when started would try to connect to the candidate’s server implementation, open lots of sockets, sends lots of messages, and verify the results against what the problem description stated"
Codility.com is a software as service company that automates this.
we use this http://play.elevatorsaga.com/ because it's extremely easy to understand, is open to multiple solution and immediately sort out both who doesn't understand queues, priorities, closures but most importantly who has completely no empathy and win level pushing numbers instead of satisfying clients.
it also takes very little time to introduce and solve which is a plus since we prefer to give it out in-office. but we do tell the candidate beforehand that there will be a 15 coding challenge so they don't panic.
I would argue it contributes to huge bloat. People pull in huge powerful libraries to format a single date. In addition, a vulnerability in a library you pull in could compromise your application. Even deeper, a sub-sub-library (i.e. one you didn't even add yourself) could have a vuln that affects you.
This article sounds pretty good, we need more people like you, but I think the next step for DigitalOcean is not hire for resume, or at least giving a chance to make one of those coding tasks
I like Jeff Atwoods approach[0], hire the candidate for a short project (2-3 weeks) let the candidate a feel for the product and team while getting paid. And at the same time let the team get to know the candidate. I would love to go through a hiring process like that :)
Unfortunately, that approach filters out already-employed people whose employers do not permit them to work simultaneously for someone else and/or impose IP ownership rules (We own everything you write inside and outside of work).
I don't usually ask candidates to write code for free. They're professionals and I expect them to _review_ code with me -- some of theirs and some of ours -- but not write it. I find that asking a candidate to write code for no true economic purpose that I will lightly read and then throw away does not inspire somebodies best work and I can gain more insight by an exercise where i have them read an explain code to me.
"Language standard library" seems like a very arbitrary standard to impose. Some languages have a very large one, others a small one. Wouldn't it be better to specify what "primitives" you wanted the code to use? (e.g. must use raw sockets vs. may use a http library vs. may use a basic json-parsing library vs. may use a full json object mapper)
As I mentioned in another comment on this thread, one of the biggest issues is framing programming as a low-status, commodity activity.
I doubt Digital Ocean does this since they want good people, but a lot of firms absolutely design their hiring process to create an upper hand and lower your status before you even walk in the door -- especially if you're an experienced engineer.
Short timed tests or whiteboard hazing are the worst version of this. These are the most blatant attempts to commoditize software labor down into a fixed set of "primitives" like data structure trivia or riddles. This is what organizations like HackerRank exist to do: allow big companies to suppress wages by creating these sorts of commodization filters. They don't attempt to capture the value of creative problem solving at all -- because the company is not pricing the value of creative problem solving into the budget for the position, since it's a rank-and-file commodity job.
For this reason alone, you are better off flat out rejecting anything like a HackerRank test or similar online, interactive, short timed test. I would absolutely go so far as to even refuse to write code on a whiteboard if asked to do so in an in-person interview. It's fine to talk about how to solve a problem and spec things out. But the minute it becomes focused on actual fucking syntax, it's game over. You are now a cog.
Longer-form tests are a lot harder to evaluate from the candidate's point of view. Now you are asking for a significant chunk of my time, without paying me. And I am still at the mercy of whatever you happen to think constitutes a valid test. I might look at your take home test and thing, "wtf? this has nothing to do with real world work." Where does that leave me? Of course I want to impress the hiring staff, but I also don't want to get roped into a bad job, and a team that hires me to do real world work by using contrived coding examples is probably not a good place to be.
Personally, I think it's a lot more useful to talk about code that already exists. Either example code form the candidate, or example code that you give to them along with some time to study it.
Engineers read code more than they write code anyway, and right when you hire someone, even if you're a bleeding edge start-up, their short-term impact is a lot more predicated on their ability to read code and quickly learn a new system, not so much writing a bunch of stuff from scratch.
It's also pretty hard to fake competency when reading and discussing actual code. If you don't know how something works, you just don't know. You probably can't just google how the internals of some highly-specific ad hoc code works, unlike data structure trivia (which is yet another reason why it just doesn't matter how much data structure trivia you have memorized).
Basically, my overall conclusion is that when someone asks you to code in a short, timed setting, they are basically lighting a cigar, fingering their handlebar moustache, kicking their feet up on the table, and saying "dance monkey dance."
Unless you are literally desperate for the job, you should reject it right away. You are being positioned so that no matter how well you do on the test, you are but a lowly code typist and they will not take your attempts at negotiation seriously.
My main hope when talking with a recruiter person is that we avoid the kabuki theater. at this point: I'm good at some stuff, poor at others. My resume is an adequate description of things I am good at. I'd like to talk personality fit now, thanks.
Not writing code for a potential employer or being asked to in an interview is a warning flag to me personally. I feel better if they do, as they've seen the goods to influence their decision on the hire. It's more about "How does this person think, how do they approach the problem". How can you measure that unless you're there? I see a lot of "I shouldn't have to do that". Well yeah, ok. But if you're any good, you shouldn't have a problem with that either.
Well yeah, ok. But if you're any good, you shouldn't have a problem with that either.
Whiteboarding, sure.
Homework assignment that takes 8 hours, as the author experienced? No way. I'm good, my hourly rate reflects that, and I don't work for free.
As an aside, I can't find any data to support your second point. There seems to be a great deal of talk how companies can't find the engineering talent for bargain bin prices, this is why the H1B visas are so popular.
The biggest issue on this site, imo, is that we can't take our heads out of our asses and admit that the vast majority of programming positions are brain dead easy. You don't need a rigorous test to vet the developer you're hiring to make what is essentially a CRUD app (and your product probably fits that description). It's to the point where companies with deep pockets (think finance) don't even bother hiring solely CS students anymore. You can take any reasonable motivated graduate, put them in training for 2 months and pop out a budding developer for your tech pipeline. One two punch of competent tech worker, and company loyalty all in a super cheap package.
I understand the appeal of having candidates write code as part of the application process, but in my view it's useless and worse, it will drive off some of the best potential candidates you could get.
First, why is it useless? Because it is an artificial and contrived exercise and not real work. Even if you design your requirements to mimic your real work environment, there's something key missing; the candidate has no knowledge of your team and your environment. How I would write code for my current team vs. how I would write code at any other job I've been at is different. You're basically asking the candidate to take a guess at what kind of paradigms your code reviewers like and what they don't like and hope it works out. One team might find use of closures smart and great, and another might find it unintuitive and adding unnecessary complexity. Your applicants have no way of knowing and just have to hope they write code your team likes.
On top of that, one contrived exercise is not a good way to get an idea of a persons' actual skill and knowledge. I'd much rather have a 30-90 minute conversation with someone where nobody writes any code than to review a contrived example. I get the appeal of the programming task, it can be done asynchronously and thus doesn't require any developer time until you go to do the review. But is it really saving you much time? Anyone who's code doesn't pass unit tests or any other automated level of screening wouldn't probably make it very far into a conversation either.
If I have an applicant spend 1-4 hours writing a code example I've had them use at least as much and probably more of their time for far less benefit than if I had simply called them up on Skype and talked to them about programming. The conversation will reveal not only a lot more to me about their actual skill set, but also their personality and how they might fit into my team. Now I realize teams doing exercises aren't skipping the conversation step, but I'm advocating for skipping the programming task step and going right to the conversation if someone's resume is solid and they can intelligently answer some basic questions (a handful of questions that should take no more than a couple minutes to answer, not an essay.)
Second, why would I say it drives off good candidates? Because I know a lot of really good developers (including myself) who skip any job posting that requires writing code as part of the application process. Why do I do that? Because it tells me the team behind this application is immature. They haven't yet gotten to the point in their careers where they realize these exercises are a waste of everyone's time. That means there's probably going to be a lot of other young dude bullshit in the team that I'm not interested in dealing with.
I think the reason so many companies resort to asking candidates to do a programming project for the interview is because they are lazy and don't want to take time to interview someone, or they suck at interviewing, or both. Bottom line, if you can't judge someone's ability by talking to them it's YOUR fault. You suck at interviewing. Last time I was looking for a job a company I was interested in gave me this massive assignment and I just told them to take a hike. I'm not spending all day writing some code for you for free sorry. Sure there are lots of horrible programmers out there, and you'll end up hiring them if you suck at determining what their skill level is via a conversation. But I hope other GREAT developers follow suit with me. Refuse these stupid programming challenges.
Have you considered that part of the purpose of the challenge might be to filter out particularly arrogant applicants who might be problematic in a team setting?
Even with whiteboard interviews, you still need to prepare for them. I would say I probably spend at least 8 hours preparing for them mainly because of its arbitrary nature. I have no idea what they will be asking.
With a take-home programming challenge, there is less uncertainty. By looking at the exercise, you can make a good estimate on how many hours it would take and see if it's worth doing.
I would prefer it that way too but whiteboards aren't getting replaced with take-home assignments. Instead they're a step towards the whiteboard stage. The whole process is just getting sillier compared to other professions.
I recently spent 4 weeks of my life interviewing for one of the bigger video games companies for their web dev team.
After those 4 weeks, I didn't get the job. Around the 3rd week I felt like my time was wasted. I want to work for this place, but if I want try again later in life, I probably won't because it took up way too much of my time with little to no value.
It sucks that I'm required to sacrifice my personal and vacation days to find potential new employment.
HN is not a place for discussing personal details about somebody, like how they look. Moreover, that weird "but" makes this comment read like an attack. Please don't post anything like this again.
Sorry, wasn't meant to be an attack, just noticed that almost every startup about page and video makes it clear that grey hair is not welcome, even at exec team level. Can't delete now.
Ok, but singling out a single company, let alone a specific person, isn't the direction to go. Think of HN threads like a Markov chain: each thing you add biases what others add next. A comment like the one you posted leads to an ugly place.
I would have said he looks more like a young-looking mid-20s, no idea how old he actually is, couldn't find anything in my 5 seconds Google search. Out of interest how old is he then?
