Who Y Combinator Companies Want(data.triplebyte.com)
data.triplebyte.com
Who Y Combinator Companies Want
http://data.triplebyte.com/who-y-combinator-companies-want-c1880a08ac88
547 comments
I'll use myself as an example -- I work as a programmer in the Defense industry. I've wanted out for years. So every so often I start sending out resumes and going on interviews.
After wasting about half of my vacation time on (multiple) rounds of interviews with each prospective employer (that ultimately lead nowhere -- most often, a potential employer who inexplicably stops communicating with me), I give up.
Then, when I need to find a new job (project/contract ending, etc.), I do the safe thing and apply to other defense companies, because getting an interview almost always results in an offer (and no multiple-rounds of white-board hazing either). After a while at the new job I'll start looking outside the industry again --- and promptly get pounded back into my pigeonhole :)
After wasting about half of my vacation time on (multiple) rounds of interviews with each prospective employer (that ultimately lead nowhere -- most often, a potential employer who inexplicably stops communicating with me), I give up.
Then, when I need to find a new job (project/contract ending, etc.), I do the safe thing and apply to other defense companies, because getting an interview almost always results in an offer (and no multiple-rounds of white-board hazing either). After a while at the new job I'll start looking outside the industry again --- and promptly get pounded back into my pigeonhole :)
"Whiteboard hazing"
Heh. I'm going to squirrel that one away for later. It beautifully captures what's currently thought of as a best practice in tech interviewing.
Heh. I'm going to squirrel that one away for later. It beautifully captures what's currently thought of as a best practice in tech interviewing.
I've turned down offers when the interviews were like that.
[deleted]
"whiteboard hazing"
there are two types of whiteboarding questions. The kind that's a perfectly reasonable thing to ask (i've had people ask me to develop some simple system... which I think is reasonable, because i'll do that as part of the job)
but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.
there are two types of whiteboarding questions. The kind that's a perfectly reasonable thing to ask (i've had people ask me to develop some simple system... which I think is reasonable, because i'll do that as part of the job)
but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.
The best argument for whiteboard algorithm questions is that they (to some degree) filter out people who think that whiteboard questions are "an exercise in memorization".
I mean, whether or not the company actually values the underlying non-memorization skill is another question (as someone who is very strong in that skill, I think that most companies/roles do not have a use for that, and should not test for that).
But the main argument against whiteboard coding applies equally to both kinds of questions. That argument is that it's a psychologically unrealistic environment, and that the main signal you get from such questions is whether or not the interviewee is psychologically comfortable under this particular artificial form of pressure. Does this generalize to other types of pressure? Does it generalize to the work environment at large?
I mean, me personally, I love whiteboard questions of either kind. Wheee. But I'm not convinced that the tech sector should use my hobby as the ultimate test of employability.
(PS: and for good engineers who are bad at whiteboarding in interviews, I'm available for coaching, heh)
I mean, whether or not the company actually values the underlying non-memorization skill is another question (as someone who is very strong in that skill, I think that most companies/roles do not have a use for that, and should not test for that).
But the main argument against whiteboard coding applies equally to both kinds of questions. That argument is that it's a psychologically unrealistic environment, and that the main signal you get from such questions is whether or not the interviewee is psychologically comfortable under this particular artificial form of pressure. Does this generalize to other types of pressure? Does it generalize to the work environment at large?
I mean, me personally, I love whiteboard questions of either kind. Wheee. But I'm not convinced that the tech sector should use my hobby as the ultimate test of employability.
(PS: and for good engineers who are bad at whiteboarding in interviews, I'm available for coaching, heh)
I say this every so often and get blasted for it, but... if you don't want to whiteboard code in an interview, bring your development environment with you. It's at least worth a try.
> That argument is that it's a psychologically unrealistic environment
I feel the same way about algorithm puzzle type interviews.
I feel the same way about algorithm puzzle type interviews.
That last part is a book or course Inwould buy
When you figure out how you can memorize your way through Google's interview process, please give me some advice. I study algorithms constantly out of interest, and still only managed to do well enough that they gave me another try a week later.
Do I think algorithm questions predict how well you do on a job? No. However I certainly don't think they are just memorization unless you mean memorizing run time of various data structure operations, but that's actually useful to know.
Do I think algorithm questions predict how well you do on a job? No. However I certainly don't think they are just memorization unless you mean memorizing run time of various data structure operations, but that's actually useful to know.
Careercup.com
If you can ace Algorithms 101 exam, you can get hired. It is a measure of intelligence and ability to learn (and for older folks, free time to refresh) but it doesn't have much to do with job performance.
I don't understand what the fuss is all about... Just learn to invert binary trees, shouldn't be that hard...
Unfortunately I already use CareerCup.com and aced my algorithms final when I was in school. However, it's not like you can just memorize the stuff you see on CareerCup since it's unlikely you'll be asked a question you saw on there, unless it's a relatively easy/popular one.
> Do I think algorithm questions predict how well you do on a job?
Personally I prefer (as both interviewer and interviewee) a weekend project style format -- pick your IDE, language, have time flexibility, etc.
Personally I prefer (as both interviewer and interviewee) a weekend project style format -- pick your IDE, language, have time flexibility, etc.
I think OP was perhaps referencing the human interaction that happens after you put something on a whiteboard with their "hazing" comment.
We've all been in that interview with the one jerk engineer who seems to want to hear themselves talk more than honestly walk through a problem. (Hint: it tends to be the person who offers "Well, that's not the way I would have done it" as a negative and without further explanation)
We've all been in that interview with the one jerk engineer who seems to want to hear themselves talk more than honestly walk through a problem. (Hint: it tends to be the person who offers "Well, that's not the way I would have done it" as a negative and without further explanation)
Honestly neither are great ways to interview someone. The first is better, sure, but it doesn't actually tell you if they're a good programmer.
The only thing I've found that does work is asking them about problems they've encountered/solved before, and then maybe have them write out something from them on the board. This gives pretty decent insight into their problem solving process.
The only thing I've found that does work is asking them about problems they've encountered/solved before, and then maybe have them write out something from them on the board. This gives pretty decent insight into their problem solving process.
>but then there's the solve x algorithm questions. Which ultimately is an exercise in memorization. At this point I've just accepted that i'll have to do that.
Pedantic (but hey this is HN), but I don't think algorithms are a question of memorization all the time. Sure, "implement quicksort" is a bit silly, but "rotate this binary tree" is eminently reasonable as a shibboleth to comfort with data structures
Agree about it not being super useful for a lot of interviews though.
Pedantic (but hey this is HN), but I don't think algorithms are a question of memorization all the time. Sure, "implement quicksort" is a bit silly, but "rotate this binary tree" is eminently reasonable as a shibboleth to comfort with data structures
Agree about it not being super useful for a lot of interviews though.
The defense industry is strange. I've had three jobs in it. In every single interview, the most technical question that anyone ever asked me was, "What do you like to do on the weekends?"
And all three jobs have been engineering positions.
And all three jobs have been engineering positions.
My last two jobs (including my current one) have been at smaller defense firms. Both interviews involved some amount of coding (mostly a 'homework' project).
Now, several years ago when I interviewed with a frickin' huge aerospace company who shall remain nameless, my experience was similar to yours. The interview was a panel-style discussion with the hiring manager and several engineers. They had to follow a script given to them by HR and ask every candidate exactly the same questions in exactly the same way. It was.... surreal. At one point I was asked something along the lines of (my memory is a bit hazy here) "Describe a time when workplace diversity significantly contributed to the accomplishment of a challenging project."
"Oookay. Uh... Well.... Uh... So... Hmm...," and so on and so forth.
Now, several years ago when I interviewed with a frickin' huge aerospace company who shall remain nameless, my experience was similar to yours. The interview was a panel-style discussion with the hiring manager and several engineers. They had to follow a script given to them by HR and ask every candidate exactly the same questions in exactly the same way. It was.... surreal. At one point I was asked something along the lines of (my memory is a bit hazy here) "Describe a time when workplace diversity significantly contributed to the accomplishment of a challenging project."
"Oookay. Uh... Well.... Uh... So... Hmm...," and so on and so forth.
"I've never had the pleasure of working at a company where this was even attempted, would [present company] provide opportunities in this regard?"
Exactly. If you can't think of a canned answer for that question, there is approximately 0 chance you can navigate the workplace politics of a large defense contractor.
Is that a bad thing? I mean, I could probably BS something, but this strikes me as the kind of question that only an HR person would ask.
And yes, I'm already in the exact scenario you say I shouldn't be able to handle.
And yes, I'm already in the exact scenario you say I shouldn't be able to handle.
Who knows what random stuff will come up in an interview. I've worked at companies of all sizes and never received any guidance on interviewing, so questions swiped from internet headlines would come as no surprise. This is an old story around here.
Ah, yes. I had a bit of a strange experience when interviewing for my current job (at a large, hyphenated aerospace company...probably the same one you interviewed with). Because I knew the hiring manager already, and he knew I could do the job. So it was very much a "Well, tell me what has happened" and "When can you start" kind of interview.
So does that anecdote reflect poorly on the interviewer, or the interviewee?
I personally would be hard-pressed to answer that question. If they mean diversity by gender and ethnicity...well, for some reason I always find myself in teams largely of white males. Not through any selection process of my own, it's just that is how it works out.
What about teams where some of the white males solve problems or think differently from others? How about foreign language proficiency helping with suppliers? Not all diversity involves overt differences. Sometimes it's as simple as one guy's test-driven mentality shipping something on time.
...Thus why I said on the basis of gender and ethnicity
[deleted]
> "What do you like to do on the weekends?"
I code for fun in Ada.
I code for fun in Ada.
I've only interviewed at one, but yes, it was the exact same for me. They asked me about school projects and times I acted like a "leader". No technical questions whatsoever, other than asking stuff like what programming languages I liked.
I left feeling very confused, but after I received the offer, I realized it was basically a grunt work position, despite what the original job listing said.
I left feeling very confused, but after I received the offer, I realized it was basically a grunt work position, despite what the original job listing said.
The DoD are the biggest offenders in my past. They were the "what do you do for fun on the weekends" people. Turns out they are hiring engineers and telling them they will be doing actual engineering, then putting them to work as project managers and job estimators.
Exactly the same situation here; been in the defense space for a while and while it's easy to get another defense job as you already have a clearance (so you're a much safer bet) venturing out into the commercial world can be daunting.
I once interviewed with Amazon and after flying out and doing the interview I'm told that they liked me but I wasn't a fit for the team and could interview with another team without a delay and they'd even help me figure out the team to interview with. But why would I waste my time again taking days off to fly out and either not pass the interview or interview with the "wrong team" again?
When I interviewed at Microsoft it was a pretty positive experience aside from one person and while I certainly wasn't upset about not getting the position I was told they had 100 people interviewing in person for a single position (supposedly almost 1,000 applications). Great odds for Microsoft but for me taking 3 days off work to do it? Great experience but I'm not sure I'd do it again so easily.
I once interviewed with Amazon and after flying out and doing the interview I'm told that they liked me but I wasn't a fit for the team and could interview with another team without a delay and they'd even help me figure out the team to interview with. But why would I waste my time again taking days off to fly out and either not pass the interview or interview with the "wrong team" again?
When I interviewed at Microsoft it was a pretty positive experience aside from one person and while I certainly wasn't upset about not getting the position I was told they had 100 people interviewing in person for a single position (supposedly almost 1,000 applications). Great odds for Microsoft but for me taking 3 days off work to do it? Great experience but I'm not sure I'd do it again so easily.
I suggest only doing interviews in the evening via phone. (not video. I've been discriminated against by video, but never by phone.) Do this in the evening. If the job is in your town and you feel its reasonable to meet them in person, do it in the evening or on a weekend.
Universally I've found that by being a little bit picky you filter out the people who aren't serious... and a lot of people aren't "serious". They might seriously want someone but they have no capability to identify that person accurately when they have found them.
Universally I've found that by being a little bit picky you filter out the people who aren't serious... and a lot of people aren't "serious". They might seriously want someone but they have no capability to identify that person accurately when they have found them.
Have you considered saving up enough money to quit and give yourself 3-6 months to find a job you enjoy?
Somehow it seems wrong to be saving 6 month salary just to get into another job (even if you enjoy it).
My Euro-biased perspective is for the job to be something that you don't actively hate doing. The fun stuff(hobbies, family, etc) can be done outside of that.
My Euro-biased perspective is for the job to be something that you don't actively hate doing. The fun stuff(hobbies, family, etc) can be done outside of that.
For what it's worth, I too am European (Swedish). I think whatever works, well, works - If OP is fine doing what they are doing, there's no problem really. However, a lot of people seem to be (a) afraid of quitting jobs they hate (b) bad at saving money.
Learning to quit a job you hate and to save money are both vey useful skills on their own. In reality, it might just take a few weeks of intense effort to find a new job in a different field - but it's always good to have a buffer, especially if you want to re-skill to a completely different field.
Learning to quit a job you hate and to save money are both vey useful skills on their own. In reality, it might just take a few weeks of intense effort to find a new job in a different field - but it's always good to have a buffer, especially if you want to re-skill to a completely different field.
I'm a CS student and most students I know dislike whiteboarding too (and by extension many, if not most, YC startup employees do too). But I'm pretty okay at them now, having had lots of practice. The key advantage for students I think is the ability to have sustained practice over the course of a month (e.g. > 4 onsites over the course of a month), which most students can afford since their schedules are flexible. Also, I've recently had interviews at a few YC companies you've heard of, and they had me code on my laptop. I didn't whiteboard at all except for system design questions.
Reply to below: Most companies have me do at least one non-technical system design and/or talk-about-a-project interview.
Reply to below: Most companies have me do at least one non-technical system design and/or talk-about-a-project interview.
IF they have you write code, think twice about taking the job. That's an indicator of a junior engineer conducting an interview in a company that didn't care enough to work out a good process.
Seriously. I've been working for startups and starting companies for 26 years, and for half that time I've been building teams. I stopped asking people to code a long time ago. If they can't code it will be obvious by their answers to your questions (And I'm not talking about coding brain teasers either.)
Ask them about a project they worked on and to explain to you how it worked. That's sufficient.
Seriously. I've been working for startups and starting companies for 26 years, and for half that time I've been building teams. I stopped asking people to code a long time ago. If they can't code it will be obvious by their answers to your questions (And I'm not talking about coding brain teasers either.)
Ask them about a project they worked on and to explain to you how it worked. That's sufficient.
I'm not trying to be pretentious here. But all big companies (Google etc.) I've interviewed so far asked me to code, what should I make of your advice?
My guess is that he's referring to startups, not monstrous companies like Google.
I think the reason you whiteboard for google interviews because you will necessarily be a cog in a wheel, and the focus of the cog is to code.
At smaller companies / startups, you will potentially be expected to design, architect, gather requirements, code, etc.
I think the reason you whiteboard for google interviews because you will necessarily be a cog in a wheel, and the focus of the cog is to code.
At smaller companies / startups, you will potentially be expected to design, architect, gather requirements, code, etc.
I have worked at companies that don't expect candidates to code during interviews, and I have worked at companies that do. I was personally acquainted with programmers who couldn't write working code at the former, and I have never heard of a programmer who couldn't write working code at the latter. I'm sure this perfect correlation anecdote fails to generalize to all workplaces, but I would not accept a job at a company that hires by bs-session again.
See also: FizzBuzz
Sorry, I think google is incompetently run. That they whiteboard, and want prestigious degrees, and all that other BS is just a smell of their incompetence. (Their performance in key technical areas is the proof... but I understand to most readers here they are probably starry eyed about google, while I've competed with them and kicked their ass in the market.)
Google stopped caring about degrees a few years ago.
(Interviewing is still somewhat silly.)
(Interviewing is still somewhat silly.)
I counter this. I am not disputing your observation.
When I interview people, I start by asking the interviewee to tell me his/her background, then start conversation about things they just told me. If they mention Ansible I expect them to be able to answer a few technical questions regarding Ansible. If the mention they have Python experience, I expect them to be able to read some code and tell me if they spot a bug or if they knew a solution to the problem. I expect some side conversation like "actually there is a bunch thunder methods in Python, etc" (which is actually related to the question). If you just answer the question, that's boring. There is a skill in interview. You need to make the person enjoy talking to you at work. We are not robot.
I don't care if the person can implement heap or not. If you use a tool enough, you need to go beyond syntax. If you can't show me how you would debug the code, the interview would end there. print, dir with print, pdb, interpreter, whatever. Coding question can help eliminate candidates who are strong in communication but with weak technical skill.
Some candidates think they can code, but they cannot structure the code to make the code usable, and that's a red flag. For the position we want, we are not looking for scripting monkey.
If I am hiring a senior position for the team, I expect to have system design conversation. The last thing I ask is whether the interviewee has done any side projects. I don't penalize people for not having a github/bitbucket account, but would be a huge plus during the evaluation.
Anyway, mileage is different for different position.
When I interview people, I start by asking the interviewee to tell me his/her background, then start conversation about things they just told me. If they mention Ansible I expect them to be able to answer a few technical questions regarding Ansible. If the mention they have Python experience, I expect them to be able to read some code and tell me if they spot a bug or if they knew a solution to the problem. I expect some side conversation like "actually there is a bunch thunder methods in Python, etc" (which is actually related to the question). If you just answer the question, that's boring. There is a skill in interview. You need to make the person enjoy talking to you at work. We are not robot.
I don't care if the person can implement heap or not. If you use a tool enough, you need to go beyond syntax. If you can't show me how you would debug the code, the interview would end there. print, dir with print, pdb, interpreter, whatever. Coding question can help eliminate candidates who are strong in communication but with weak technical skill.
Some candidates think they can code, but they cannot structure the code to make the code usable, and that's a red flag. For the position we want, we are not looking for scripting monkey.
If I am hiring a senior position for the team, I expect to have system design conversation. The last thing I ask is whether the interviewee has done any side projects. I don't penalize people for not having a github/bitbucket account, but would be a huge plus during the evaluation.
Anyway, mileage is different for different position.
Coding as part of the interview process is a reasonable request to ask from the applicant and I'm having hard time to understand your objection to this step.
Not really you don't get to see surgeons operate when applying to a position. There is a lack of trust why this whiteboard stuff happens to be honest I pass about 60% of the white interviews that i did.
Seriously, there's a large number of applicants who apply for programming jobs, have had programming jobs in the past, can talk about their programming work, but are actually unable to write code.
Fizzbuzz is an absolutely necessary filter, or you will accidentally hire these people.
Fizzbuzz is an absolutely necessary filter, or you will accidentally hire these people.
I think you have to be careful about what you do, versus what is common in the industry. It is pretty common to get asked coding questions in the Bay Area, regardless.
Most of the better interviewers work to understand how the candidate thinks and their aptitude to learn new things. Those can tell you a lot about how successful they will be in a job. And folks have shown that take home projects can show you what they can get done.
I found it interesting to compare the company's interviewer training at Google and at IBM. IBM is focused on finding highly qualified people compatible with their values, Google was more interested in finding people who were not intimidated by "impossible" questions. Both have their strengths.
Most of the better interviewers work to understand how the candidate thinks and their aptitude to learn new things. Those can tell you a lot about how successful they will be in a job. And folks have shown that take home projects can show you what they can get done.
I found it interesting to compare the company's interviewer training at Google and at IBM. IBM is focused on finding highly qualified people compatible with their values, Google was more interested in finding people who were not intimidated by "impossible" questions. Both have their strengths.
I've had people nail general CS and SE questions and then completely flop the simplest of coding exercises. I didn't hire these people, and I'm guessing you would have.
Anyway, I disagree with you. Though I'm not saying your process is bad.
Anyway, I disagree with you. Though I'm not saying your process is bad.
Are you in a position to name company names? Most everybody I interview with does this (at a minimum). I'd love to interview at a company that has a smarter system in place.
See http://sockpuppet.org/blog/2015/03/06/the-hiring-post/ and Matasano.
I've already seen those. Have you seen this? https://news.ycombinator.com/item?id=10480684
There's a reason I asked MCRed. He has a unique perspective on this that I value.
There's a reason I asked MCRed. He has a unique perspective on this that I value.
While it may be possible to tell competance easily this way, one thing I found difficult to tell without live coding is someone's ability for architecting components. One recent hire at work is competant at coding, but for a senior engineer, weak on designing API for a UI service to generate components, as well as weak on unit testing (which in this instance, turns out to be somewhat linked).
How would you screen such a person out?
How would you screen such a person out?
Just the opposite:
If they don't make you write any code, do not work there: you might end up working with people who can't write code---because the application process doesn't filter those bozos out.
(Doesn't have to be `write code on a whiteboard'. Whiteboarding is actually pretty artificial. Just make sure they do make you write code at all.)
If they don't make you write any code, do not work there: you might end up working with people who can't write code---because the application process doesn't filter those bozos out.
(Doesn't have to be `write code on a whiteboard'. Whiteboarding is actually pretty artificial. Just make sure they do make you write code at all.)
It's not only the applicants who have limited time. The startup founders are also time constrained. You can't found a successful startup if you spend 10+ hours a week interviewing potential employees.
I suspect much of the initial bias and "hard line" preferences are due to a startup's unwillingness to spend inordinate amounts of time interviewing candidates to find that one diamond in the rough.
Imagine 4 of every 10 "academic programmer" candidates are a good fit, and 6 of 10 "product programmer" candidates are a good fit. Why waste time interviewing 10 academic programmers, for a max hit rate of 40%, when you could focus solely on product programmers and get a max hit rate of 60%?
This data certainly suggests that different founders have their own biases and preferences for what makes a "good programmer." Most of them probably realize they are pigeonholing and could be wrong, but they're willing to risk that for more efficient interviewing and a high hit rate.
Stick with what you know if it's "good enough." Optimally, as a founder you can already identify multiple potential early hires just from your own network. If you have the right background and connections, you can hire your first couple employees without doing a single interview.
Time is money. Interviews take time and cost money.
I suspect much of the initial bias and "hard line" preferences are due to a startup's unwillingness to spend inordinate amounts of time interviewing candidates to find that one diamond in the rough.
Imagine 4 of every 10 "academic programmer" candidates are a good fit, and 6 of 10 "product programmer" candidates are a good fit. Why waste time interviewing 10 academic programmers, for a max hit rate of 40%, when you could focus solely on product programmers and get a max hit rate of 60%?
This data certainly suggests that different founders have their own biases and preferences for what makes a "good programmer." Most of them probably realize they are pigeonholing and could be wrong, but they're willing to risk that for more efficient interviewing and a high hit rate.
Stick with what you know if it's "good enough." Optimally, as a founder you can already identify multiple potential early hires just from your own network. If you have the right background and connections, you can hire your first couple employees without doing a single interview.
Time is money. Interviews take time and cost money.
This is definitely true. The filters that companies and recruiters use mostly trend in a meaningful direction. There are a higher percentage of good programmers among MIT grads than SUNY Potsdam grads. But this fact does nothing to help the good programmers who look bad on paper who everyone is ignoring. This is precisely the problem that we're trying to fix with Triplebyte. We want to make actual technical evaluation (not credential evaluation) cheap and accurate, so we can just interview everyone.
The filters that companies and recruiters use mostly trend in a meaningful direction. There are a higher percentage of good programmers among MIT grads than SUNY Potsdam grads.
Imagine how mistaken that would sound if you substitute "startup founders" for "programmers."
The reason you feel company filters are anything except random noise is personal bias. It's disheartening that your article notices that company preferences are essentially random noise, and then you don't really internalize that fact or take it to its logical conclusion:
Interviews where programmers do anything except work-hire tests tuned to the signal that the companies want are doomed to fail.
And it's almost impossible to do a work-hire test in an interview. A real work-hire test. The type of test where you actually do some work and then show that yours is effective.
We're so backwards that people probably read this and think I'm saying whiteboard work or something stupid like that. No. Real, actual work. The problem you're working on can be fake, but the problem needs to be literally the same type of thing that the company does on a day-to-day basis.
Want a 100% success rate? Do that, and then don't pay attention to anything but the results. Including whether the candidate has an MIT degree, or any degree at all. If you actually set up a work-hire test, a real one, and then stop asking about all the other stuff that doesn't matter, then you will get a 100% rate. Again, you have to tune the test to what the company is looking for, but that's not hard. "Here is an iOS app. Find and fix these bugs, then add a new feature."
Imagine how mistaken that would sound if you substitute "startup founders" for "programmers."
The reason you feel company filters are anything except random noise is personal bias. It's disheartening that your article notices that company preferences are essentially random noise, and then you don't really internalize that fact or take it to its logical conclusion:
Interviews where programmers do anything except work-hire tests tuned to the signal that the companies want are doomed to fail.
And it's almost impossible to do a work-hire test in an interview. A real work-hire test. The type of test where you actually do some work and then show that yours is effective.
We're so backwards that people probably read this and think I'm saying whiteboard work or something stupid like that. No. Real, actual work. The problem you're working on can be fake, but the problem needs to be literally the same type of thing that the company does on a day-to-day basis.
Want a 100% success rate? Do that, and then don't pay attention to anything but the results. Including whether the candidate has an MIT degree, or any degree at all. If you actually set up a work-hire test, a real one, and then stop asking about all the other stuff that doesn't matter, then you will get a 100% rate. Again, you have to tune the test to what the company is looking for, but that's not hard. "Here is an iOS app. Find and fix these bugs, then add a new feature."
The cost of a real work test is much higher, both to the company, and to the applicant. Some companies take that approach (weebly for one), but it means that some of the best programmer will not apply, and it only makes worse the problem of having to aggressively pre-filter (based on credentials, or something else).
You are 100% correct that most research into interviewing has show it to be far less predictive than companies believe. However, I'll add that no one is doing the false negative studies that would really be required to show this. For example, Google has shown that among people who pass their interview GPA is not correlated with success. This does not at all mean that GPA is not correlated with programming ability. In fact, it almost certainly is. People with low GPA who pass google interviews have a lot of other things going for them. To really analyze this, you'd have to give a job to a random sample of applicants. No one has done this. My goal is for Triplebye to get large enough that I can.
You are 100% correct that most research into interviewing has show it to be far less predictive than companies believe. However, I'll add that no one is doing the false negative studies that would really be required to show this. For example, Google has shown that among people who pass their interview GPA is not correlated with success. This does not at all mean that GPA is not correlated with programming ability. In fact, it almost certainly is. People with low GPA who pass google interviews have a lot of other things going for them. To really analyze this, you'd have to give a job to a random sample of applicants. No one has done this. My goal is for Triplebye to get large enough that I can.
> No one has done this.
Not for coding specifically, but there have been some studies correlating GPA with career success, and the correlation has been found to be very low. But the reason there are very few studies that look at this is that GPA A) isn't epistemologically meaningful B) isn't a measure in the mathematical sense.
"A grade can be regarded only as an inadequate report of an inaccurate judgment by a biased and variable judge of the extent to which a student has attained an undefined level of mastery of an unknown proportion of an indefinite amount of material." -Paul Dressel
Not for coding specifically, but there have been some studies correlating GPA with career success, and the correlation has been found to be very low. But the reason there are very few studies that look at this is that GPA A) isn't epistemologically meaningful B) isn't a measure in the mathematical sense.
"A grade can be regarded only as an inadequate report of an inaccurate judgment by a biased and variable judge of the extent to which a student has attained an undefined level of mastery of an unknown proportion of an indefinite amount of material." -Paul Dressel
The best programmers do apply. Whatever you think a work-hire test is, that wasn't it. A work-hire test attracts the best programmers. It doesn't repel them. It's a chance to demonstrate their skill. It's also far better: anything is better than the fake contests they're currently forced to endure. Which would you prefer? Spend a couple hours remotely fixing some bugs and adding a feature on a fake iOS app, or spend all day playing "dodge the bias" for a hit rate of ~60% at the cost of a vacation day?
Why do you think the programmer from your article didn't get a job when you "sat back to watch him get a job"? You didn't tune your test to what the company was looking for.
Any YC founders who are reading this: Refuse to talk to Triplebyte until they set up a work hire test for your company. Force them to do it, and force them to work with you to tune the test to the work you need. You will get a 100% hit rate. And you'll notice something else: Your retention rate will go way, way up. Want to not deal with firing people? Get them to show you they can do the work. Nothing else matters.
The test needs to be set up so that the candidate can demonstrate they can do exactly the same things all other employees do on a day-to-day basis, or it's not a work-hire test.
Why do you think the programmer from your article didn't get a job when you "sat back to watch him get a job"? You didn't tune your test to what the company was looking for.
Any YC founders who are reading this: Refuse to talk to Triplebyte until they set up a work hire test for your company. Force them to do it, and force them to work with you to tune the test to the work you need. You will get a 100% hit rate. And you'll notice something else: Your retention rate will go way, way up. Want to not deal with firing people? Get them to show you they can do the work. Nothing else matters.
The test needs to be set up so that the candidate can demonstrate they can do exactly the same things all other employees do on a day-to-day basis, or it's not a work-hire test.
EDIT: I thought that sillysaurus3 was talking about a work trial period (days or a week), but it seems they are talking about asking question during that interview that are similar to actual work. I retract me objection :)
If only it were that easy. I am not at all opposed to work-trial tests. They are almost certainly more accurate. But a high percentage of programmer will never apply to a company that requires one. Read any HN comment thread about the topic. It's very controversial. Lots of programmers are against it. Work-trials require MORE time upfront from the candidate, and of course still often lead to rejections (by design a hiring filter rejects most people). A failed work trial burns an entire week of vacation. An unemployed programmer (who is being paid the work-trial) may like it, but someone working another job may not.
If only it were that easy. I am not at all opposed to work-trial tests. They are almost certainly more accurate. But a high percentage of programmer will never apply to a company that requires one. Read any HN comment thread about the topic. It's very controversial. Lots of programmers are against it. Work-trials require MORE time upfront from the candidate, and of course still often lead to rejections (by design a hiring filter rejects most people). A failed work trial burns an entire week of vacation. An unemployed programmer (who is being paid the work-trial) may like it, but someone working another job may not.
It's really frustrating when people are clearly talking around each other, and either failing to notice or willfully continuing to do it.
sillysaurus3: "Spend a couple hours remotely fixing some bugs and adding a feature on a fake iOS app"
ammon: "A failed work trial burns an entire week of vacation."
You're not talking about the same thing!
sillysaurus3 is talking about doing a small amount of work that is similar to what the company does, under conditions similar to those you would have as an employee. You seem to be talking about short trial period contract-to-hire. Yes, the thing you're talking about sucks and is a huge turnoff to candidates, but (mostly speaking for myself here) what sillysaurus3 is suggesting is massively appealing.
sillysaurus3: "Spend a couple hours remotely fixing some bugs and adding a feature on a fake iOS app"
ammon: "A failed work trial burns an entire week of vacation."
You're not talking about the same thing!
sillysaurus3 is talking about doing a small amount of work that is similar to what the company does, under conditions similar to those you would have as an employee. You seem to be talking about short trial period contract-to-hire. Yes, the thing you're talking about sucks and is a huge turnoff to candidates, but (mostly speaking for myself here) what sillysaurus3 is suggesting is massively appealing.
It seems like you're being forced into a false dichotomy of being either completely for work trials or completely against them, and that's unfair.
But if your biggest objection is that it will take additional time, that depends entirely on the nature of the trial. I was given a work trial at my first job and it took about 40 minutes. It didn't go as smoothly as I'd hoped, but I would much much rather have done that than spent 40 minutes answering brain teasers in front of a white board.
If I'm already taking a day off, I don't care if the interview lasts three hours or five. I'd rather work on a collaborative task with my potential teammates to see if it's going to be worth radically altering my life to take a new job. I understand that there are many programmers who are opposed to work trials, and they can say "I'm opposed to work trials and would rather demonstrate my abilities in another way."
It seems like your research so far has been very comprehensive, why dismiss an effective technique because some people are opposed to it?
But if your biggest objection is that it will take additional time, that depends entirely on the nature of the trial. I was given a work trial at my first job and it took about 40 minutes. It didn't go as smoothly as I'd hoped, but I would much much rather have done that than spent 40 minutes answering brain teasers in front of a white board.
If I'm already taking a day off, I don't care if the interview lasts three hours or five. I'd rather work on a collaborative task with my potential teammates to see if it's going to be worth radically altering my life to take a new job. I understand that there are many programmers who are opposed to work trials, and they can say "I'm opposed to work trials and would rather demonstrate my abilities in another way."
It seems like your research so far has been very comprehensive, why dismiss an effective technique because some people are opposed to it?
Why don't we let the interviewee choose between a few interview methods? Or bypass it if they think their public code proves their ability?
I think this is the best solution. It does raise issues of how you keep a consistent bar between the various options, but I think it's better than the alternatives. Currently we let people do a project track where they do a project on their own time, or an interview track where they answer interview questions. We also give them a choice of interview questions in a number of areas, to try to increase the probability that we see a strength.
If you're getting paid for a week of work, you can take a week of unpaid vacation from your day job.
No vacation days burned. No money lost.
No vacation days burned. No money lost.
Huh? You can't just take unpaid vacation because you feel like it.
Can't you? Your only obligation to the company is the time they pay you for. The time they don't pay you for is yours.
We're not longshoremen. Virtually nobody has a contract saying "just show up when and if you feel like it, and we'll pay you for that".
I don't think Swizec was implying that this time couldn't be coordinated in advance with your employer.
I suspect that the flexible "unpaid vacation" scenario you're describing is much more rare than you think. If your team is pushing for a major release and you decide just not to show up, your days are numbered. If you spend the week working for another company, you are quite likely to be fired from the old one.
Ammon mentioned Weebly, above. They are one company that I've seen require an on-site week as a contractor. I know of a Weebly candidate who lost her current job because the employer considered the leave to be job abandonment. Thankfully, she got the job at Weebly. Perhaps Weebly's weeklong trial is effective for them at weeding out bad hires. But I suspect most good programmers would never consider giving up a week of their lives to an extended job interview.
Ammon mentioned Weebly, above. They are one company that I've seen require an on-site week as a contractor. I know of a Weebly candidate who lost her current job because the employer considered the leave to be job abandonment. Thankfully, she got the job at Weebly. Perhaps Weebly's weeklong trial is effective for them at weeding out bad hires. But I suspect most good programmers would never consider giving up a week of their lives to an extended job interview.
Thing is, most companies will fire you as soon as they notice you're actively looking for other jobs.
And I wasn't suggesting job abandonment. Asking for a week of unpaid vacation is a different conversation than asking for a week of paid vacation.
And I wasn't suggesting job abandonment. Asking for a week of unpaid vacation is a different conversation than asking for a week of paid vacation.
> Thing is, most companies will fire you as soon as they notice you're actively looking for other jobs.
Only if they don't need you and think you are not being productive. So be needed and be productive.
Only if they don't need you and think you are not being productive. So be needed and be productive.
You're assuming the rates are the same, and that your current company will allow you to take an unpaid week off.
Triplebyte does notionally allow you to apply (to Triplebyte) via a trial project. But it's in addition to the interview(s), and the feeling they get from you during the interview trumps the project. They gave me the following feedback:
> This was a tough decision and one that we were on the fence about. We really appreciate you taking the time to work on the take home project. We're aware this requires a substantial time commitment and we are really grateful that you invested the time in completing it. We thought you wrote a great, very full featured [trial project]. It was especially impressive how much you dug into the academics behind [the project].
> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here, where making changes to the project seemed to be slower and more difficult than we'd have liked.
tptacek had some advice for hiring-through-a-work-test that I (from my armchair) agree with, which is that it's important to give everyone the same work test so your applicants are comparable. There's a little bit of tension (I don't think it's unresolvable) between that and "The test needs to be set up so that the candidate can demonstrate they can do exactly the same things all other employees do on a day-to-day basis, or it's not a work-hire test".
> This was a tough decision and one that we were on the fence about. We really appreciate you taking the time to work on the take home project. We're aware this requires a substantial time commitment and we are really grateful that you invested the time in completing it. We thought you wrote a great, very full featured [trial project]. It was especially impressive how much you dug into the academics behind [the project].
> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here, where making changes to the project seemed to be slower and more difficult than we'd have liked.
tptacek had some advice for hiring-through-a-work-test that I (from my armchair) agree with, which is that it's important to give everyone the same work test so your applicants are comparable. There's a little bit of tension (I don't think it's unresolvable) between that and "The test needs to be set up so that the candidate can demonstrate they can do exactly the same things all other employees do on a day-to-day basis, or it's not a work-hire test".
It always surprises to me to no end when I see people get any real feedback from the interview. Do these employers not care about getting sued, like everyone els.
That feedback may not be hopelessly vague, but it's also totally unactionable. They wouldn't let me reinterview, and interviewing was the only problem they identified.
I don't know if I'm a "best programmer", but I definitely enjoy "add a little feature to our fake app" tests.
A friend of mine's company usually sends out a little canvas-based browser paint app with a bunch of features, and asks them to implement a few things, like flood fill. It's really enjoyable.
A friend of mine's company usually sends out a little canvas-based browser paint app with a bunch of features, and asks them to implement a few things, like flood fill. It's really enjoyable.
Favorite interview I've done was something similar to this; they gave me a small, pre-made project with tools they knew I was familiar with, asked me to implement some specific functionality, and then told me to "have fun with it for a few hours". So I did, and the project blew them away.
Unfortunately, they then flew me out to their office, whiteboard hazed me, and sent me home. Called me a few weeks later to tell me I didn't get the job, but that they sent me a hoodie in the mail (felt like a consolation prize).
It's a pretty comfy hoodie. They spent that VC money well.
Unfortunately, they then flew me out to their office, whiteboard hazed me, and sent me home. Called me a few weeks later to tell me I didn't get the job, but that they sent me a hoodie in the mail (felt like a consolation prize).
It's a pretty comfy hoodie. They spent that VC money well.
"The best programmers" aren't all fixing bugs in iOS apps. The blog post perfectly outlined people who are motivated by other things. I don't want to work at a company where "realistic" work is me working alone on doing assigned tasks.
I identify with the "product engineer" concept they outlined, I want to talk UX and user testing in an interview not prove I can understand someone else's code base. Honestly many companies will get far more value of a programmer who has user sympathy and writes user-friendly applications than one who writes a fully tested, bug free and technically sexy app which users don't want to use.
I identify with the "product engineer" concept they outlined, I want to talk UX and user testing in an interview not prove I can understand someone else's code base. Honestly many companies will get far more value of a programmer who has user sympathy and writes user-friendly applications than one who writes a fully tested, bug free and technically sexy app which users don't want to use.
This is absolutely true. Doing work-hire tells me if it's work I'm interested in doing as well as showing that I can do the work. Interviews are a crap shoot of bias avoidance as sillysauras3 says. Please actually work on fixing it.
> A work-hire test attracts the best programmers. It doesn't repel them.
I'm not the best programmer, but I'm comfortable I'd slot in the top quintile, probably top ten percent, of people that walk through a startup's door. And I'd never even return your call. No work-sample test I've ever seen would take less than four hours. That's a $550 opportunity cost for me at my standard rates. What the hell makes you think you deserve that for free? You aren't Google and you aren't Facebook. You need me more than I need you. And almost everybody else who's like you--and given the way you are acting, probably you too--will forget about me or blow me off at some point in the process, wasting my time even further.
On the other hand, an in-person, discussion-based interview isn't work and isn't priced as work; not only does it tells me about the company and whether or not I actually want to work there, but I enjoy meeting new people in a professional setting (there are multiple companies where I've turned them down, but have become friends with people I've met through the process!).
Look at my Github and decide if I can hack if you want, that's why it's there, but I don't work on effing spec.
I'm not the best programmer, but I'm comfortable I'd slot in the top quintile, probably top ten percent, of people that walk through a startup's door. And I'd never even return your call. No work-sample test I've ever seen would take less than four hours. That's a $550 opportunity cost for me at my standard rates. What the hell makes you think you deserve that for free? You aren't Google and you aren't Facebook. You need me more than I need you. And almost everybody else who's like you--and given the way you are acting, probably you too--will forget about me or blow me off at some point in the process, wasting my time even further.
On the other hand, an in-person, discussion-based interview isn't work and isn't priced as work; not only does it tells me about the company and whether or not I actually want to work there, but I enjoy meeting new people in a professional setting (there are multiple companies where I've turned them down, but have become friends with people I've met through the process!).
Look at my Github and decide if I can hack if you want, that's why it's there, but I don't work on effing spec.
If you're a top ten percent programmer who charges $137/hr then this whole discussion probably isn't oriented at you. By definition, most programmers are not in the top ten percent. They make money by sitting down and writing code, not by projecting confidence and machismo. So why shouldn't they prove their abilities and evaluate the company and it's general environment by sitting down and actually coding?
I'm very old and out of the loop, I have no idea what modern work-sample tests look like. I remember when I did one many years ago it was to the effect of "Write a script that checks to see if a URL returns a valid response code, and trigger an event if it does not". My prospective employer liked my coding style and I got hired. What was so wrong about that?
As I recall, they intended to modify the script and use it in production whether they hired me or not. I also don't care about that. It took less than an hour, and it seemed like a valid form of evaluation. Maybe it's a pride thing, but I had no problem with it and I think a lot of other people would have been ok with that practice as well.
I'm very old and out of the loop, I have no idea what modern work-sample tests look like. I remember when I did one many years ago it was to the effect of "Write a script that checks to see if a URL returns a valid response code, and trigger an event if it does not". My prospective employer liked my coding style and I got hired. What was so wrong about that?
As I recall, they intended to modify the script and use it in production whether they hired me or not. I also don't care about that. It took less than an hour, and it seemed like a valid form of evaluation. Maybe it's a pride thing, but I had no problem with it and I think a lot of other people would have been ok with that practice as well.
Because you shouldn't work for free. That holds true for writers, that holds true for artists, that holds true for web designers, and that holds true for programmers. And unlike those other professions, the creative has the power in this relationship. What these companies hate admitting but all know is true is that even a mediocre programmer, a sit-down-and-write-code programmer, needs these companies more than the programmer needs them.
If a company wanted to pay you for that work-sample test, that's different. But they don't, of course, because that costs them money instead of costing you. There's no need to let profit-seeking entities use you for nothing. You just don't need to be their monkey.
If a company wanted to pay you for that work-sample test, that's different. But they don't, of course, because that costs them money instead of costing you. There's no need to let profit-seeking entities use you for nothing. You just don't need to be their monkey.
Most professionals do work for free, in small amounts relative to the amount of money at stake. If you clearly only need 2 hours of lawyer time, you pay for both of those hours. But if you're talking about maybe hiring a lawyer to do something complicated for you, the lawyer will give you an hour or two of time for free, in which they will use their professional expertise (i.e. do work) to assess whether or not your case will benefit from their services. But maybe you think law is a situation where the client has the power in the relationship? No worries, accountants do that too, as do architects and building contractors, as do SaaS companies, as do.... basically, as do members of every industry where the customer isn't obviously a penny pincher (i.e. retail sales does not do this).
You made this exact case yourself in a related comment, in which you called meeting people business development. I agree there's a non-zero distinction here between work-hire-test and consulting-about-consulting, but claiming that the issue is that "you shouldn't work for free" is misleading.
Also, you suggest that if they pay, that costs them instead of costing you. It already costs them more to interview than it costs you. But sure, if making sure they don't get any benefit out of their relationship with you unless you get benefit too, tell them you'll only do a work-hire if they make a donation to the EFF in the value of your hourly rate.
You made this exact case yourself in a related comment, in which you called meeting people business development. I agree there's a non-zero distinction here between work-hire-test and consulting-about-consulting, but claiming that the issue is that "you shouldn't work for free" is misleading.
Also, you suggest that if they pay, that costs them instead of costing you. It already costs them more to interview than it costs you. But sure, if making sure they don't get any benefit out of their relationship with you unless you get benefit too, tell them you'll only do a work-hire if they make a donation to the EFF in the value of your hourly rate.
> But if you're talking about maybe hiring a lawyer to do something complicated for you, the lawyer will give you an hour or two of time for free, in which they will use their professional expertise (i.e. do work) to assess whether or not your case will benefit from their services.
Of course. That's the sit-down-and-chat "interview". But lawyers don't draft up a contract for you to demonstrate that they can write up a contract to your satisfaction. If you want a lawyer's expertise applied concretely to something of your direction, you pay. And while lawyers do have bar exams, they don't have a very detailed demonstration of their work up on Lawhub for your perusal!
> I agree there's a non-zero distinction here between work-hire-test and consulting-about-consulting, but claiming that the issue is that "you shouldn't work for free" is misleading.
I think it's misleading only if you consider the beneficiary of that work to be the same in both cases. I don't. The only beneficiary of every work-sample test I've ever been given was the company--it goes into some black hole and whether it was even good or not, to say nothing of any actionable feedback, has literally-literally never been forthcoming. On the other hand, I have very rarely not benefited in some way from sitting down and chatting with a technical leader at a company, whether it was directly about their problems (or their solutions!) or about tech in general. Both in a consulting-about-consulting capacity and an interview one.
> Also, you suggest that if they pay, that costs them instead of costing you. It already costs them more to interview than it costs you.
In an absolute sense, it definitely costs them more. In a relative one, it emphatically does not: they've got plenty of bodies that can parallelize. I can be interviewing with them, or I can be working, or I can be mopping my bathroom floor. I can't be doing all of those things at once.
Of course. That's the sit-down-and-chat "interview". But lawyers don't draft up a contract for you to demonstrate that they can write up a contract to your satisfaction. If you want a lawyer's expertise applied concretely to something of your direction, you pay. And while lawyers do have bar exams, they don't have a very detailed demonstration of their work up on Lawhub for your perusal!
> I agree there's a non-zero distinction here between work-hire-test and consulting-about-consulting, but claiming that the issue is that "you shouldn't work for free" is misleading.
I think it's misleading only if you consider the beneficiary of that work to be the same in both cases. I don't. The only beneficiary of every work-sample test I've ever been given was the company--it goes into some black hole and whether it was even good or not, to say nothing of any actionable feedback, has literally-literally never been forthcoming. On the other hand, I have very rarely not benefited in some way from sitting down and chatting with a technical leader at a company, whether it was directly about their problems (or their solutions!) or about tech in general. Both in a consulting-about-consulting capacity and an interview one.
> Also, you suggest that if they pay, that costs them instead of costing you. It already costs them more to interview than it costs you.
In an absolute sense, it definitely costs them more. In a relative one, it emphatically does not: they've got plenty of bodies that can parallelize. I can be interviewing with them, or I can be working, or I can be mopping my bathroom floor. I can't be doing all of those things at once.
I don't get why you perceive the realistic-work-sample test as "working for free", but the unrealistic-whiteboard test as "isn't work." They are both taking a similar amount of time and effort, serving the same purpose, and benefiting the same people.* The only difference is that one does a better job.
*The primary beneficiary being you, if you're a top-10% programmer: It gives you a better chance to accurately show off your ability, which is probably worth thousands of dollars in salary.
*The primary beneficiary being you, if you're a top-10% programmer: It gives you a better chance to accurately show off your ability, which is probably worth thousands of dollars in salary.
Work-sample tests, in my experience, are universally "do this crap and then maybe we'll talk to you." It's nothing you'll get serious feedback on, it's nothing you can open-source, it's garbage code and wasted time that benefits the company unilaterally.
But the alternative--it's not the whiteboard, it's the meeting people. Right now, I consult, but I do take interviews for "permanent positions". But we all know they aren't actually permanent positions. The last thirty years of corporatism have made this loud and clear: we are all expendable tools. and I go into them with that in mind: a W-2 doesn't mean I'm anything other than working for a client under a tax-advantageous status. Interviews are business development; I am effectively offering my exclusive services on retainer to a single company. So meeting people to discuss the gig (whether or not the whiteboard comes into play, the only interview I've been on in the last two years where I was both interested in the company and wrote code on the board was Google) benefits me, too: maybe it's not a fit, but maybe I meet somebody I'll remember as "hey, I'd like to work with them again." Or "hey, I don't want to work here, but I know somebody who will, so I can do them a solid and they can help me in the future."
So, yeah, it is work. It's just business development, which is a different, and valuable, kind of work. And it applies to everybody, not just consultants; it's the game we're all playing even if one doesn't realize they're playing it.
But the alternative--it's not the whiteboard, it's the meeting people. Right now, I consult, but I do take interviews for "permanent positions". But we all know they aren't actually permanent positions. The last thirty years of corporatism have made this loud and clear: we are all expendable tools. and I go into them with that in mind: a W-2 doesn't mean I'm anything other than working for a client under a tax-advantageous status. Interviews are business development; I am effectively offering my exclusive services on retainer to a single company. So meeting people to discuss the gig (whether or not the whiteboard comes into play, the only interview I've been on in the last two years where I was both interested in the company and wrote code on the board was Google) benefits me, too: maybe it's not a fit, but maybe I meet somebody I'll remember as "hey, I'd like to work with them again." Or "hey, I don't want to work here, but I know somebody who will, so I can do them a solid and they can help me in the future."
So, yeah, it is work. It's just business development, which is a different, and valuable, kind of work. And it applies to everybody, not just consultants; it's the game we're all playing even if one doesn't realize they're playing it.
OK, I agree it's also really important to spend a few hours meeting people, and I would never accept a job where I couldn't do that first. But I am personally thrilled to be able to spend two hours demonstrating that I am a really good programmer in all of the ways that a different kind of test doesn't pick up. That seems to benefit me a lot, and it also speaks well of the future coworkers I will have if I work at the company in question. Google's process (for instance) makes me nervous about this.
(Disclaimer: I strongly prefer to quit my current job before looking for new jobs. If that weren't the case, I'm sure I would be more sensitive to anything that takes time, but I think I would still feel this way.)
(Disclaimer: I strongly prefer to quit my current job before looking for new jobs. If that weren't the case, I'm sure I would be more sensitive to anything that takes time, but I think I would still feel this way.)
Who said anything about working for free? The only work trial I've ever done was paid in full at the same rate as I would be making if I had already been hired.
It was fun, and more profitable than a free boring discussion-based interview.
It was fun, and more profitable than a free boring discussion-based interview.
eropple's entire spiel was in response to "A work-hire test...doesn't repel [the best programmers]", so saying that this discussion is irrelevant to a top 10% programmer doesn't really follow.
Our culture is rejecting the one effective test we have.
Do we care about equality, or not? I tried not mentionining this aspect, hoping people would realize on their own. But a remote work hire test is also mostly anonymous. It doesn't matter whether you're black, white, male, or female. All that matters is whether you can do the work.
On the flipside, what you're saying is that you genuinely want to spend a vacation day meeting a new company instead of with your family or working on your own projects.
And it's like, if you think you're a good dev, why wouldn't you leap at the opportunity to show it off? I get that it's a little annoying to spend a few hours on it, but the standard interview is literally random noise. Why subject your future to a random process?
I don't know. I respect your view. I'm going to bow out now. Have a good week.
Do we care about equality, or not? I tried not mentionining this aspect, hoping people would realize on their own. But a remote work hire test is also mostly anonymous. It doesn't matter whether you're black, white, male, or female. All that matters is whether you can do the work.
On the flipside, what you're saying is that you genuinely want to spend a vacation day meeting a new company instead of with your family or working on your own projects.
And it's like, if you think you're a good dev, why wouldn't you leap at the opportunity to show it off? I get that it's a little annoying to spend a few hours on it, but the standard interview is literally random noise. Why subject your future to a random process?
I don't know. I respect your view. I'm going to bow out now. Have a good week.
I get what you are saying. And equality is tremendously, spectacularly important; I have more than once been That Guy at companies, making management uncomfortable when asking why the whole place is White Dude Central. But I very strongly feel that your value prop isn't an effective one from the perspective of the employee. You are not telling me why I should give a damn about your work-hire test, as somebody you need to hire to make your company work. What are you offering, aside from Yet Another Startup with Yet Another Startup Problems and Yet Another Startup Under-Market Salary? Why should I be your monkey?
And, FWIW, when salaried, I not once have taken a vacation day to interview. I've said "hey, I'll be in late," and because this industry is so deranged as to think that 50+-hour weeks are normal, no manager has had the temerity to get mad at me for taking a morning off because invariably it will be cashed in when I have to pull a sixteen-hour day to deal with a problem. (The days around Heartbleed earned me some goodwill at that gig, if you follow!)
And, FWIW, when salaried, I not once have taken a vacation day to interview. I've said "hey, I'll be in late," and because this industry is so deranged as to think that 50+-hour weeks are normal, no manager has had the temerity to get mad at me for taking a morning off because invariably it will be cashed in when I have to pull a sixteen-hour day to deal with a problem. (The days around Heartbleed earned me some goodwill at that gig, if you follow!)
[deleted]
It also doesn't matter if you are actually the one taking the test.
>That's a $550 opportunity cost
The typical cost of hiring a programer is way higher than that, more like $30k I'd guess so they could always try paying you $550 to do something semi real? I'm not experienced but I've got a friend who hires remote workers and he says the only way to tell if they are good is to actually hire them to do a small job.
The typical cost of hiring a programer is way higher than that, more like $30k I'd guess so they could always try paying you $550 to do something semi real? I'm not experienced but I've got a friend who hires remote workers and he says the only way to tell if they are good is to actually hire them to do a small job.
"A work-hire test attracts the best programmers. It doesn't repel them."
Not really. The best programmers have other stuff to do besides your make-work silliness.
"Get them to show you they can do the work. Nothing else matters."
This is even more silliness. Suppose you have a diverse team, and the a candidate comes up, and passes the test, but is Donald Trump. Are you then going to say that only the work matters?
Not really. The best programmers have other stuff to do besides your make-work silliness.
"Get them to show you they can do the work. Nothing else matters."
This is even more silliness. Suppose you have a diverse team, and the a candidate comes up, and passes the test, but is Donald Trump. Are you then going to say that only the work matters?
Yes to this 100x. I actually did this last year with outstanding results. We were looking to bring on paid interns. We narrowed all the apps down to 5 and paid each $50 to complete real stuff that we use in our environment. 2 out of the 5 completed the work within an hour, 1 took 3 hours and the other 2 returned uncompleted work. We hired the 3 that completed the work and the one that took 3 hours ended up being the best out of them. This person also had very little prior experience but what I liked was that she stuck with the task and not only found the bug but improved some other code within the app.
All 3 ended up being very valuable and 2 of them stayed on well beyond their internship.
Oh, and these projects were done from home before we ever brought them in for an interview and we hired them before ever meeting them.
All 3 ended up being very valuable and 2 of them stayed on well beyond their internship.
Oh, and these projects were done from home before we ever brought them in for an interview and we hired them before ever meeting them.
For purposes of discussion, let's take it as a given that a work-hire tests are the best way to screen candidates.
The effort required to administer an on-site work-hire test is non-zero, therefore I cannot administer such a test to every applicant.
I therefore need a way to determine who to bring on-site, in order to administer such a test. I cannot phone screen every single applicant due to the cost involved.
That process could also be a work-hire test of some sort (e.g. a remote coding project), but regardless of what has been said on this thread, many good applicants will drop off at this step. I know this empirically, because I've experienced it, many, many times.
Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants, who often have multiple offers from multiple companies due to the competiveness of the current hiring market. It also disproportionately drives away passive candidates, who are often the best candidates, because the best candidates are often not looking for work (since they are good, people who have worked with them previously want to work with them again, and they get poached).
So I need some method of sourcing and filtering candidates down that is non-intrusive to both our development team AND the applicant. This is the reality. This simply has to happen in a startup's hiring pipeline.
Currently, most companies do this by looking at resumes. That is obviously sub-optimal.
Any suggestions for alternatives?
EDIT: spelling.
The effort required to administer an on-site work-hire test is non-zero, therefore I cannot administer such a test to every applicant.
I therefore need a way to determine who to bring on-site, in order to administer such a test. I cannot phone screen every single applicant due to the cost involved.
That process could also be a work-hire test of some sort (e.g. a remote coding project), but regardless of what has been said on this thread, many good applicants will drop off at this step. I know this empirically, because I've experienced it, many, many times.
Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants, who often have multiple offers from multiple companies due to the competiveness of the current hiring market. It also disproportionately drives away passive candidates, who are often the best candidates, because the best candidates are often not looking for work (since they are good, people who have worked with them previously want to work with them again, and they get poached).
So I need some method of sourcing and filtering candidates down that is non-intrusive to both our development team AND the applicant. This is the reality. This simply has to happen in a startup's hiring pipeline.
Currently, most companies do this by looking at resumes. That is obviously sub-optimal.
Any suggestions for alternatives?
EDIT: spelling.
http://www.stackoverflowcareers.com/blog/2014/05/20/getting-...
Try segmenting potential hires into different categories and using different strategies for each group. You should also clearly communicate the process, so they don't get the wrong idea.
>Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants
Is this before or after the phone screen? If they think the work-hire test is going to be in addition to a phone screen and an on-site whiteboard session, they'll drop. If they're senior devs, you should be able to tell from their resumes. Do a phone screen, and if they pass, explain that they can either do a work-hire test or a whiteboarding session. Explain that the work-hire test should be doable in 4 hours, so they don't envision a week long project. Also explain that it's a substitute for the whiteboard portion of the on-site. People who tend to hate whiteboard coding will choose the work-hire test and vice versa.
If you're trying to find diamonds in the rough among junior talent, sending out a first-pass work-hire test might work. You'd still get better results if you explained that it was short and a substitute for the onsite whiteboard session.
Try segmenting potential hires into different categories and using different strategies for each group. You should also clearly communicate the process, so they don't get the wrong idea.
>Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants
Is this before or after the phone screen? If they think the work-hire test is going to be in addition to a phone screen and an on-site whiteboard session, they'll drop. If they're senior devs, you should be able to tell from their resumes. Do a phone screen, and if they pass, explain that they can either do a work-hire test or a whiteboarding session. Explain that the work-hire test should be doable in 4 hours, so they don't envision a week long project. Also explain that it's a substitute for the whiteboard portion of the on-site. People who tend to hate whiteboard coding will choose the work-hire test and vice versa.
If you're trying to find diamonds in the rough among junior talent, sending out a first-pass work-hire test might work. You'd still get better results if you explained that it was short and a substitute for the onsite whiteboard session.
I do. I was going to bail from this thread, but it sounds like you see the great potential that this idea can have, if it can work. The truth is that it works. Okay then, one last try:
Set up a system that can spin up a droplet for a remote candidate. Any time a candidate expresses interest in your company, spin up an instance and email them a link to it.
What does the link do? That depends on your company. Are you making an iOS app? Then the link takes them to where they can download source code for a fake, hypothetical iOS app. It says "X, Y, and Z bugs exist. Find them and fix them. Then add a feature: here is a clear description of what to add."
When the candidate is done doing this, they zip up their code and send it back to you.
If it sounds way more effective to look at that than to look at resumes, it is. If it sounds like it will repel candidates, well... Two things. First, if you're chasing a specific developer, then that isn't really the normal hiring process. You want them already. This pipeline is for everyone else. It makes no sense to subject them to a work hire test when you're actively seeking them out.
Here's the other point. The type of candidates you will find with this method will shock you. They will be so skilled that it won't matter whether they're called a senior or fresh out of college. You'll know immediately that you want them.
Everything I've described up to this point is a remote process. There is no on-site work hire test. By the time they come on site, you're mainly checking they can show up, and telling them about your company. You're no longer trying to filter them based on ability; they already demonstrated it.
Let's say your company's website is the primary focus, not an iOS app. Ok. The link will take the candidate to a hypothetical, fake website built with a similar framework. Again, it will have multiple bugs and a missing feature. Tell them what the bugs are, and tell them what the feature needs to do. Then have them send you their code when they're done.
I feel like at this point no one will even try to do this. You can think of so many reasons not to try: it takes too much work, it will scare too many people off, it will... Etc.
These reasons turn out to be largely fake or mistaken. Try it. Invest the resources to build this pipeline, tell HN when it's ready, and you win.
If this sounds prohibitive or unlikely, remember how counter-intuitive the most effective techniques in life are. Penicillin was discovered by accident. It sounds pretty unlikely that it would work. Same deal here.
I've explained this as clearly as I can. It's up to everyone else to either try it or to watch others win after they try it. Because the filter I've explained is the only way to let talent find you.
The type of people you'll discover will range from passive people who found the process amusing, to well-off senior developers who are demonstrating why you should pay them X equity or Y salary, to high school dropouts who turn out to be one of the most valuable people that join your team.
I'm not even going to touch the topic of what tech companies currently do. It doesn't matter. I've described what works, and if whoever reads this suppresses their instincts and builds this, they will discover it's practically the key to winning.
Set up a system that can spin up a droplet for a remote candidate. Any time a candidate expresses interest in your company, spin up an instance and email them a link to it.
What does the link do? That depends on your company. Are you making an iOS app? Then the link takes them to where they can download source code for a fake, hypothetical iOS app. It says "X, Y, and Z bugs exist. Find them and fix them. Then add a feature: here is a clear description of what to add."
When the candidate is done doing this, they zip up their code and send it back to you.
If it sounds way more effective to look at that than to look at resumes, it is. If it sounds like it will repel candidates, well... Two things. First, if you're chasing a specific developer, then that isn't really the normal hiring process. You want them already. This pipeline is for everyone else. It makes no sense to subject them to a work hire test when you're actively seeking them out.
Here's the other point. The type of candidates you will find with this method will shock you. They will be so skilled that it won't matter whether they're called a senior or fresh out of college. You'll know immediately that you want them.
Everything I've described up to this point is a remote process. There is no on-site work hire test. By the time they come on site, you're mainly checking they can show up, and telling them about your company. You're no longer trying to filter them based on ability; they already demonstrated it.
Let's say your company's website is the primary focus, not an iOS app. Ok. The link will take the candidate to a hypothetical, fake website built with a similar framework. Again, it will have multiple bugs and a missing feature. Tell them what the bugs are, and tell them what the feature needs to do. Then have them send you their code when they're done.
I feel like at this point no one will even try to do this. You can think of so many reasons not to try: it takes too much work, it will scare too many people off, it will... Etc.
These reasons turn out to be largely fake or mistaken. Try it. Invest the resources to build this pipeline, tell HN when it's ready, and you win.
If this sounds prohibitive or unlikely, remember how counter-intuitive the most effective techniques in life are. Penicillin was discovered by accident. It sounds pretty unlikely that it would work. Same deal here.
I've explained this as clearly as I can. It's up to everyone else to either try it or to watch others win after they try it. Because the filter I've explained is the only way to let talent find you.
The type of people you'll discover will range from passive people who found the process amusing, to well-off senior developers who are demonstrating why you should pay them X equity or Y salary, to high school dropouts who turn out to be one of the most valuable people that join your team.
I'm not even going to touch the topic of what tech companies currently do. It doesn't matter. I've described what works, and if whoever reads this suppresses their instincts and builds this, they will discover it's practically the key to winning.
I think what you're filtering for here is 'initiative'.
I don't hire programmers, but have been a hiring manager, running fairly technical business teams now for 10+ years, and have found that initiative is often the deciding factor in any given employee's success.
There are other ways to select for it, and clues you start to pick up on over the years, but once you've figured out how to gauge relative levels of initiative across different people, I've found it makes hiring/resourcing questions quite a bit easier.
I don't hire programmers, but have been a hiring manager, running fairly technical business teams now for 10+ years, and have found that initiative is often the deciding factor in any given employee's success.
There are other ways to select for it, and clues you start to pick up on over the years, but once you've figured out how to gauge relative levels of initiative across different people, I've found it makes hiring/resourcing questions quite a bit easier.
I really like what you've been advocating in this discussion.
We've evolved the same process in my own startup - in the last 2 months we've hired 5 remote programmers in Vietnam and India by giving them 2 rounds of remote work-sample tasks (a simple web app), then ending off with a text or voice interview. We ended up retaining 2 out of 5 of them (both Vietnamese, incidentally) who demonstrated a higher level of ability after they started.
The retention rate is low, so we've been tightening up the process. What we've found is that we probably needed to raise the bar a little by asking candidates to design and architect a feature (DB-backend-frontend) during the chat interview. That would have given us a better insight into their code structuring and teamwork/communication skills.
We've just brought on a 3rd hire (Vietnamese again) who passed our improved interview, and I have a good feeling that the process works very well to weed out candidates who don't have the needed level of ability and scrupulousness.
The best of our hires didn't attend college or have much relevant experience, but was clearly very capable and possessed great initiative. We're really glad to have managed to hire him. Another guy is finishing his 3rd year of college.
In summary, I think remote work-sample tests are fantastic, and I hope you're right that they're the key to winning :)
We've evolved the same process in my own startup - in the last 2 months we've hired 5 remote programmers in Vietnam and India by giving them 2 rounds of remote work-sample tasks (a simple web app), then ending off with a text or voice interview. We ended up retaining 2 out of 5 of them (both Vietnamese, incidentally) who demonstrated a higher level of ability after they started.
The retention rate is low, so we've been tightening up the process. What we've found is that we probably needed to raise the bar a little by asking candidates to design and architect a feature (DB-backend-frontend) during the chat interview. That would have given us a better insight into their code structuring and teamwork/communication skills.
We've just brought on a 3rd hire (Vietnamese again) who passed our improved interview, and I have a good feeling that the process works very well to weed out candidates who don't have the needed level of ability and scrupulousness.
The best of our hires didn't attend college or have much relevant experience, but was clearly very capable and possessed great initiative. We're really glad to have managed to hire him. Another guy is finishing his 3rd year of college.
In summary, I think remote work-sample tests are fantastic, and I hope you're right that they're the key to winning :)
Work-hire test works for positions that requires failry narrow skill sets. You need iOS 2D game developer or nodejs to MongoDB plumber or single page JS app developer? Sure it would work beautifully. However most companies are not looking for such very narrow skill sets. Companies look for people who are generalists at heart and can be specialized in given area with little ramp up on demand . One week you might write build script and other week debugging Rails and yet another week fixing javascript in UX. When doing these tasks, it's not expected that you already know all these tools and platforms. You will have some ramp up time of 1 day to a week. But the key is that you should be able to move around stack, across projects and get shit done given reasonable ramp up times.
Also a lot of experienced programmers are generalists as well. You might have been C++ system guy in your past life, worked on JavaScript couple of years back and now working on Hadoop backend. You may not remember all the nitty gritty details of past platforms and tools but you can ramp up on demand.
So this 2 hour work-hire test that narrowly focuses on specific tools and platform won't work for vast majority of programmers who haven't branded themselves in to one narrow area. Also remember that a lot of programmers at places like Google, FB and Microsoft work in highly proprietory environment with their own internal build system, platforms and tools. They are likely not familiar with everything that's latest and in fashion. However they are very smart people, can change gear easily and, most importantly, ramp up on demand very quickly.
Yet another big issue is that work-hire test usually fail to measure hardcore computer science problem solving abilities. Sure, you are good at fixing some iOS bugs but can you figure out how to do driving directions on maps or may be scale email system to 100 million users? Now I do agree that lot of jobs don't require hard core CS but many do. And for a startup, it's usually impossible to tell if your future 6 month down the line will hing on having someone with hard core CS skills.
Also a lot of experienced programmers are generalists as well. You might have been C++ system guy in your past life, worked on JavaScript couple of years back and now working on Hadoop backend. You may not remember all the nitty gritty details of past platforms and tools but you can ramp up on demand.
So this 2 hour work-hire test that narrowly focuses on specific tools and platform won't work for vast majority of programmers who haven't branded themselves in to one narrow area. Also remember that a lot of programmers at places like Google, FB and Microsoft work in highly proprietory environment with their own internal build system, platforms and tools. They are likely not familiar with everything that's latest and in fashion. However they are very smart people, can change gear easily and, most importantly, ramp up on demand very quickly.
Yet another big issue is that work-hire test usually fail to measure hardcore computer science problem solving abilities. Sure, you are good at fixing some iOS bugs but can you figure out how to do driving directions on maps or may be scale email system to 100 million users? Now I do agree that lot of jobs don't require hard core CS but many do. And for a startup, it's usually impossible to tell if your future 6 month down the line will hing on having someone with hard core CS skills.
If you want generalists, you won't really be able to test them properly by asking questions at random: All you are hoping for is that they share the same background as you do. The moment it's you asking the question, and they can't really check sources, you have already lost.
As far as hardcore computer science abilities, a test still won't help, because what you are really testing is how far people are from college: Generalist cs is touched in college, but there are entire sections of computer science that someone with 10 years of experience might not have had to touch. I've had to do pretty specific CS stuff for work, but to get any of that done, I started with weeks of research, and then add my own spin to our specific situation top. You can't test the ability to do that by just checking if someone has memorized Raft, or black red trees, or any other random problem. I don't have a lot of CS algorithms memorized: that's why there's the internet, and why I have Knuth in my shelf.
You want to check for hard cs, ask the candidate to choose his favorite CS topic, and ask for am impromptu presentation on that. anything else is just going to fail at finding candidates that have different backgrounds than you, and that's PRECISELY the people you want to hire.
As far as hardcore computer science abilities, a test still won't help, because what you are really testing is how far people are from college: Generalist cs is touched in college, but there are entire sections of computer science that someone with 10 years of experience might not have had to touch. I've had to do pretty specific CS stuff for work, but to get any of that done, I started with weeks of research, and then add my own spin to our specific situation top. You can't test the ability to do that by just checking if someone has memorized Raft, or black red trees, or any other random problem. I don't have a lot of CS algorithms memorized: that's why there's the internet, and why I have Knuth in my shelf.
You want to check for hard cs, ask the candidate to choose his favorite CS topic, and ask for am impromptu presentation on that. anything else is just going to fail at finding candidates that have different backgrounds than you, and that's PRECISELY the people you want to hire.
> Imagine how mistaken that would sound if you substitute "startup founders" for "programmers."
Isn't that pretty common among incubators and VCs? It's not the only factor, but for first-time founders, being from Stanford is a large plus when it comes to getting in the door. If you already have a track record then of course they just go by that. But when it's your first company, I don't think the "startup ecosystem" is any less reliant on these kinds of signalling credentials to filter the large volume of people who want funding.
Isn't that pretty common among incubators and VCs? It's not the only factor, but for first-time founders, being from Stanford is a large plus when it comes to getting in the door. If you already have a track record then of course they just go by that. But when it's your first company, I don't think the "startup ecosystem" is any less reliant on these kinds of signalling credentials to filter the large volume of people who want funding.
And the vast, vast majority of startups fail.
So.
So.
How do you do a work-hire test for someone who already has a job, and is not allowed to work on another company's stuff?
If all of an applicant's code is owned by their current employer would "whiteboard" style code also be prohibited in an interview? I guess I'm wondering where the line is drawn.
> The problem you're working on can be fake
I'm assuming if it was a fake problem, it wouldn't be something the other company could actually use.
I'm assuming if it was a fake problem, it wouldn't be something the other company could actually use.
It's not about what they could use. It's about what they own and where it's going. If your employment agreement states that any code you write belongs to your employer and that you're not allowed to share company code with others, then a work-sample test essentially asks candidates to violate their current employment agreement.
Employment agreements like that are certainly frustrating. I've had experience with a few.
One thing to realize is that your employer can't really retaliate. The hypothetical iOS app I mentioned is set up for one purpose: to let candidates show they can do work the company is looking for. Not only will the code be thrown away, but it wouldn't make any sense to use it.
One thing to realize is that your employer can't really retaliate. The hypothetical iOS app I mentioned is set up for one purpose: to let candidates show they can do work the company is looking for. Not only will the code be thrown away, but it wouldn't make any sense to use it.
Taking that interpretation would mean any interview where you write code would violate your employment agreement.
I would say that if the new company is not in the same section of the industry, than enforcing that agreement is entirely unreasonable.
This also depends on how clear the company is about the hiring process. A lot of companies have started using the coding projects before the resume screen, and then also throwing in an all-day whiteboard session. So when someone's been burned before, they're going to do a 180 when a company replies, "Do this project."
>The filters that companies and recruiters use mostly trend in a meaningful direction. There are a higher percentage of good programmers among MIT grads than SUNY Potsdam grads.
Uh are you sure about that? Google's experience seems to be that academic achievement is not a good predictor. And they know a thing or two about hiring.
http://qz.com/180247/why-google-doesnt-care-about-hiring-top...
Uh are you sure about that? Google's experience seems to be that academic achievement is not a good predictor. And they know a thing or two about hiring.
http://qz.com/180247/why-google-doesnt-care-about-hiring-top...
Many successful people who've built and exited massive start-ups have suggested that it's worthwhile on the start-up side to spend 25% of your time on hiring when you're actually hiring as so you can easily get above 10 hrs a week given a full time role on this and have that be a good result. Optimizing to minimize the cost of hiring an early engineer is definitely solving the wrong problem, given the early engineers are almost as crucial to success as founders. Unfortunately, hit rate is also often the wrong variable from the company end: if you interview an academic programmer to confirm their product programming skills you generally get someone better with a larger skill set than if you focus in the category you want for the skills you want (early-stage you generally want breadth over depth for many roles). It clearly sucks for people on the receiving end of the low hit rate interview, but I'd caution start-ups against optimizing their process for the wrong things.
I talked to the CEO of a high-growth unicorn once and he said his job description is basically a glorified recruiter. Pretty much everything he does is related to getting the right people on board his startup.
My data as an investor supports your point. For a lot of young startups -- especially those with <=5 people -- people often spend >=10 hours per week on recruiting. Not every person at the company will spend that much time, but a lot of founders spend a huge chunk of their week on recruiting.
Absolutely. At my last startup I was VP of Engineering and at one point I tracked my time and was spending 45% of my week on recruiting activities. But that was necessary, both to protect my team's time and to grow. You can't hire good people without putting in the time to find them, talk to them, and convince them to join if you like them. And that effort can't be outsourced to a recruiter, either, if you want it to be productive.
Interviewing is ridiculously important for any small company. The problem is most people have little idea how to do anything except look for people like them.
Precisely. It's a flaw (shortcut) in the human brain, with effects far beyond programming interviews. This is why structuring interview evaluation is so important
Fortunately, the solution to the problem is super cheap.
$20 buys you a copy of "The Who" book, which is a proven, scalable system with specific questions to ask at each step of the interview process....
$20 buys you a copy of "The Who" book, which is a proven, scalable system with specific questions to ask at each step of the interview process....
That would be true if you could show that candidate "types" are actually meaningful distinctions and not just the founder's first impression based on limited data. I think that's a stretch.
[deleted]
I've made the mistake in the past of overcommitting myself to interviewing with multiple companies at once. The time commitment wasn't the worst part, the real factor I didn't for see is that interviewing is stressful and mentally exhausting. On top of the interview itself, there's the hours of studying you have to put in. It's extremely hard to do while doing your full time job.
Now I have a rule that I will interview with ONE company at a time. Consequently, I am very careful about picking which companies I will interview with.
Now I have a rule that I will interview with ONE company at a time. Consequently, I am very careful about picking which companies I will interview with.
>On top of the interview itself, there's the hours of studying you have to put in.
Yikes, are people really doing this, or feel like they must?
If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on. I also expect to be asked how I might approach a given problem within my area of work. I can't imagine studying that - I'm paid to do this stuff every day.
So are we talking about stuff that isn't related to my area of work, like brain-teasers and random algorithm questions?
Yikes, are people really doing this, or feel like they must?
If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on. I also expect to be asked how I might approach a given problem within my area of work. I can't imagine studying that - I'm paid to do this stuff every day.
So are we talking about stuff that isn't related to my area of work, like brain-teasers and random algorithm questions?
Yes, people are really doing this. It's stupid, but to not do so puts you at a competitive disadvantage against other candidates. Competition for programming jobs is fierce.
It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.
It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.
>Yes, people are really doing this. It's stupid, but to not do so puts you at a competitive disadvantage against other candidates. Competition for programming jobs is fierce.
I'm suspecting that this is a "Valley" thing, would that be wrong?
>It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.
If someone has years of experience in this field, and a strong portfolio, why would they need to remember how to do quicksort? They probably haven't done it since their university days. That shouldn't even remotely be the focus of an interview for someone who has done real work in this industry.
I'm suspecting that this is a "Valley" thing, would that be wrong?
>It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.
If someone has years of experience in this field, and a strong portfolio, why would they need to remember how to do quicksort? They probably haven't done it since their university days. That shouldn't even remotely be the focus of an interview for someone who has done real work in this industry.
It's not a "Valley" thing. It's a tech. company thing. I've never interviewed in the Bay Area, but pretty much every interview I've had has asked me to write algorithms on a whiteboard.
>If someone has years of experience in their field and a strong portfolio
Well, the problem is that quite a lot of programmers don't have portfolios outside of work. I certainly don't. I mean, I have a Github, true, but there's not really anything on there except for a bunch of half-finished experiments. Honestly, I don't have the energy to spend 8 hours a day immersed in programming, and then come home and spend one to two hours more building up my portfolio. Maybe that makes me a "bad" programmer, by some definitions.
>If someone has years of experience in their field and a strong portfolio
Well, the problem is that quite a lot of programmers don't have portfolios outside of work. I certainly don't. I mean, I have a Github, true, but there's not really anything on there except for a bunch of half-finished experiments. Honestly, I don't have the energy to spend 8 hours a day immersed in programming, and then come home and spend one to two hours more building up my portfolio. Maybe that makes me a "bad" programmer, by some definitions.
>It's not a "Valley" thing. It's a tech. company thing. I've never interviewed in the Bay Area, but pretty much every interview I've had has asked me to write algorithms on a whiteboard.
The last time I had to write anything on a whiteboard in an interview, it was a data model relating to the work I'd be doing. I felt it was relevant to the process, at the time. If it weren't I'd feel like my valuable time (as well as theirs) was being wasted. But I suppose this comes down to what a company wants. If they just want people who are generally smart, and can be ramped up on the company's tech stack, fair enough. But some companies need to hire people who can hit the ground running. Much of my contracting has been done on such a basis.
>Well, the problem is that quite a lot of programmers don't have portfolios outside of work. I certainly don't. I mean, I have a Github, true, but there's not really anything on there except for a bunch of half-finished experiments. Honestly, I don't have the energy to spend 8 hours a day immersed in programming, and then come home and spend one to two hours more building up my portfolio. Maybe that makes me a "bad" programmer, by some definitions.
Your portfolio need not be only Github work. Barring an NDA, you can certainly discuss your professional work. In fact, I want to be asked about it during my interviews, as it forms the basis of my experience (which in theory is a big part of why I'm there in the interview room!).
The last time I had to write anything on a whiteboard in an interview, it was a data model relating to the work I'd be doing. I felt it was relevant to the process, at the time. If it weren't I'd feel like my valuable time (as well as theirs) was being wasted. But I suppose this comes down to what a company wants. If they just want people who are generally smart, and can be ramped up on the company's tech stack, fair enough. But some companies need to hire people who can hit the ground running. Much of my contracting has been done on such a basis.
>Well, the problem is that quite a lot of programmers don't have portfolios outside of work. I certainly don't. I mean, I have a Github, true, but there's not really anything on there except for a bunch of half-finished experiments. Honestly, I don't have the energy to spend 8 hours a day immersed in programming, and then come home and spend one to two hours more building up my portfolio. Maybe that makes me a "bad" programmer, by some definitions.
Your portfolio need not be only Github work. Barring an NDA, you can certainly discuss your professional work. In fact, I want to be asked about it during my interviews, as it forms the basis of my experience (which in theory is a big part of why I'm there in the interview room!).
It's not a "Tech company thing" it's a "junior engineer who doesn't know how to interview" thing. It is an indicator of a low quality company. Seriously. This is my opinion after 25 years of interviews.
Ask the candidate "Tell me about a project you're passionate about". Find out why. Get them to explain a hard problem they solved. Get them to teach it to you so you understand it.
Find the candidate that can do that and that gives you a good answer and you find a candidate who is passionate about something and can communicate it and understood it well enough to relate it in detail to you on the spot. That's the one to hire.
not the one who memorized quick sort... the former can implement a new quicsort.... the other one will spend all his time on stack overflow asking others to do his work.
Ask the candidate "Tell me about a project you're passionate about". Find out why. Get them to explain a hard problem they solved. Get them to teach it to you so you understand it.
Find the candidate that can do that and that gives you a good answer and you find a candidate who is passionate about something and can communicate it and understood it well enough to relate it in detail to you on the spot. That's the one to hire.
not the one who memorized quick sort... the former can implement a new quicsort.... the other one will spend all his time on stack overflow asking others to do his work.
>It's not a "Tech company thing" it's a "junior engineer who doesn't know how to interview" thing. It is an indicator of a low quality company.
I guess Google, Microsoft, Amazon, Facebook and Dropbox are all low quality companies, then.
I guess Google, Microsoft, Amazon, Facebook and Dropbox are all low quality companies, then.
I've worked for two of those, beat one in the market, and have a low regard of the quality of engineering at the other two... so yeah, low quality companies. Or at least low quality hiring processes.
One problem that seems pervasive on hacker news is Cargo Cultism. Just because one of those companies does something does not mean that it's a good thing. Some of those companies have really capricious and arbitrary hiring policies.
Don't get starry eyed. Don't confuse a household name for quality. And don't mindlessly copy the broken system of a fortune 500 company for your startup.
I'm an engineer, I'm not just pulling this out of my ass. I've been conducting thousands of interviews over the past decades and had to manage the people I hired with my process.
One problem that seems pervasive on hacker news is Cargo Cultism. Just because one of those companies does something does not mean that it's a good thing. Some of those companies have really capricious and arbitrary hiring policies.
Don't get starry eyed. Don't confuse a household name for quality. And don't mindlessly copy the broken system of a fortune 500 company for your startup.
I'm an engineer, I'm not just pulling this out of my ass. I've been conducting thousands of interviews over the past decades and had to manage the people I hired with my process.
Why not do both?
Where have you interviewed that hasn't asked you to implement X algorithm by memory?!? I'd love to interview there!
[deleted]
There's a bit of hyperbole here, though I am largely in agreement based on my interviews. In my interviews experience, it is unlikely that you'd be asked to implement quick sort, but that's because you'll be asked a question that requires realizing that a the question reduces to quick sort (this is how companies can avoid hiring people who just memorize solutions). For instance, instead of being asked to create all permutations of a string and all its substrings, you'll be asked a question that involves analyzing a set that needs to be permuted a similar way (this is my example, not from an actual interview, but I'd say it would count as about a medium level difficult question). If you don't know quick sort cold (or, in the case of my example, how to print all permutations of a string), there's no way you'd be able to program something that requires modifying and adapting these algorithms in 45 minutes at a whiteboard.
And yeah, again YMMV, but you definitely do need to largely solve the problem, so speed absolutely does matter here.
The really frustrating thing about all this is that if the experience causes you to go back, study algorithms, buy cracking the coding interview, and getting incredibly good at these questions, your next interview will involve… detailed questions about ruby syntax, followed by another interview with questions about how the JVM works, followed by another interview with questions about how MapReduce works[1].
Not saying this is good or bad, just that this is how it is, at least at the harder interviews.
Based on the final paragraph, it looks like triple byte does see the market opportunity here. The frustrating moving target of interview questions could correlate very well with what type of programmers a company is looking for. Considering that every interview requires a day (or more) off and a stressful and mentally taxing series of in-person exams, there's only so much one candidate can take before giving up and just staying in his or her job (assuming the candidate is currently employed). So if a company becomes aware of how to align candidate type with interview path, if you can line up with the algorithms style interviews, the person can slowly learn until getting a job offer, rather than experiencing a reset button. I wish them luck with this, because they'd be adding real value to a developer's job search, which isn't something devs typically expect from a recruiter.
And yeah, again YMMV, but you definitely do need to largely solve the problem, so speed absolutely does matter here.
The really frustrating thing about all this is that if the experience causes you to go back, study algorithms, buy cracking the coding interview, and getting incredibly good at these questions, your next interview will involve… detailed questions about ruby syntax, followed by another interview with questions about how the JVM works, followed by another interview with questions about how MapReduce works[1].
Not saying this is good or bad, just that this is how it is, at least at the harder interviews.
Based on the final paragraph, it looks like triple byte does see the market opportunity here. The frustrating moving target of interview questions could correlate very well with what type of programmers a company is looking for. Considering that every interview requires a day (or more) off and a stressful and mentally taxing series of in-person exams, there's only so much one candidate can take before giving up and just staying in his or her job (assuming the candidate is currently employed). So if a company becomes aware of how to align candidate type with interview path, if you can line up with the algorithms style interviews, the person can slowly learn until getting a job offer, rather than experiencing a reset button. I wish them luck with this, because they'd be adding real value to a developer's job search, which isn't something devs typically expect from a recruiter.
>"It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook."
If at an interview they asked/expected that of me, it would promptly disinterest me in working for them. And I'd probably tell them that right there.
Optimizing for memorization of specific algorithms (of sorting even?) instead of problem-solving and domain-knowledge is quite a weird/perverse incentive. I'm surprised it's gotten this far, if it is true. The places I've interviewed generally ask prior experience, talk about solutions and approaches, and theoretical OO-questions of the fizz-buzz level just to be sure.
If at an interview they asked/expected that of me, it would promptly disinterest me in working for them. And I'd probably tell them that right there.
Optimizing for memorization of specific algorithms (of sorting even?) instead of problem-solving and domain-knowledge is quite a weird/perverse incentive. I'm surprised it's gotten this far, if it is true. The places I've interviewed generally ask prior experience, talk about solutions and approaches, and theoretical OO-questions of the fizz-buzz level just to be sure.
It's quite difficult to come up with really good, unique interview questions. It's quite a bit easier to walk into the room, say "write a function that returns all the permutations of a string" and watch the candidate squirm. That's why most companies do that, it has nothing to do with trying to find candidates who can do the work at hand.
It sounds like you don't live in the Valley.
I interviewed for jobs recently, and I studied my ass off for 6+ weeks, every night doing different coding questions, and spending weekends learning new things and coding algorithms for 6-8 hrs a a day.
It paid off, I got multiple job offers, and am pretty happy with the end result.
I interviewed for jobs recently, and I studied my ass off for 6+ weeks, every night doing different coding questions, and spending weekends learning new things and coding algorithms for 6-8 hrs a a day.
It paid off, I got multiple job offers, and am pretty happy with the end result.
>It sounds like you don't live in the Valley.
Indeed, I don't. I even asked, in one of my replies, if this was a "Valley" thing.
I'm ok with being asked to code or write things out during interviews - that is, if it is pertinent to the job I'll be performing. If I'm expected to do complex DB queries, for example, it is reasonable to see if I can write one. If I've been doing it for years, I should be able to handle such a task.
>I interviewed for jobs recently, and I studied my ass off for 6+ weeks, every night doing different coding questions, and spending weekends learning new things and coding algorithms for 6-8 hrs a a day.
But this... this seems more appropriate in the context of a university exam than a job in real-world software development. As I said in elsewhere in this thread, I can understand asking such questions of a prospective junior developer, as they won't have much experience, and the CS 101 material may be fresher in their mind.
Indeed, I don't. I even asked, in one of my replies, if this was a "Valley" thing.
I'm ok with being asked to code or write things out during interviews - that is, if it is pertinent to the job I'll be performing. If I'm expected to do complex DB queries, for example, it is reasonable to see if I can write one. If I've been doing it for years, I should be able to handle such a task.
>I interviewed for jobs recently, and I studied my ass off for 6+ weeks, every night doing different coding questions, and spending weekends learning new things and coding algorithms for 6-8 hrs a a day.
But this... this seems more appropriate in the context of a university exam than a job in real-world software development. As I said in elsewhere in this thread, I can understand asking such questions of a prospective junior developer, as they won't have much experience, and the CS 101 material may be fresher in their mind.
It doesn't matter what you think is appropriate. This is the reality in Silicon Valley and probably other places now too. If you tried to interview here without preparing you would be eaten alive.
Not all study is programming. I will usually spend a few hours looking into a company, their product/s, the founders, key employees, competitors, etc.
Data structures and algorithms mostly. Most companies will ask you to solve those types of questions.
>If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on.
Oh. Well you are in for a big surprise if you interview at 90% of tech companies.
>If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on.
Oh. Well you are in for a big surprise if you interview at 90% of tech companies.
Maybe where you are (and how unfortunate). But in a decade-plus of doing this, I haven't been asked things like that since I was trying to find my first job in software development. At that point, asking CS 101 questions made sense, since I didn't have much in the way of products shipped, and so forth.
How unfortunate why? Is it unreasonable to ask a candidate to know CS101? I would never work for a company that didn't ask engineer candidates those questions.
>How unfortunate why? Is it unreasonable to ask a candidate to know CS101?
Not at all. For a junior position. But that's a difference of opinion with which we may have to live. For more experienced candidates, I'd be far more interested in what they've done to apply their knowledge in real-world scenarios. I need them to be able to do more than hypotheticals.
>I would never work for a company that didn't ask engineer candidates those questions.
And that's fine. Small point to add: I see at least one regional difference, with regards to the terms being used - I never see software developers called "engineers" unless they have an engineering degree. Maybe that's just my part of Canada, I don't know. Perhaps it is more of a protected term here.
Not at all. For a junior position. But that's a difference of opinion with which we may have to live. For more experienced candidates, I'd be far more interested in what they've done to apply their knowledge in real-world scenarios. I need them to be able to do more than hypotheticals.
>I would never work for a company that didn't ask engineer candidates those questions.
And that's fine. Small point to add: I see at least one regional difference, with regards to the terms being used - I never see software developers called "engineers" unless they have an engineering degree. Maybe that's just my part of Canada, I don't know. Perhaps it is more of a protected term here.
It is a protected term here (in Canada), and it is not in the US.
For example, in 2001, Microsoft apparently agreed that in Canada, they would only use the acronym "MCSE", and not spell it out, because holding an MCSE does not make you an engineer.
I think it's amusing and cute that American developers call themselves engineers. It's not like they take on the ethical responsibilities that engineers do. But when in Rome, speak Romansh. Or however that goes.
For example, in 2001, Microsoft apparently agreed that in Canada, they would only use the acronym "MCSE", and not spell it out, because holding an MCSE does not make you an engineer.
I think it's amusing and cute that American developers call themselves engineers. It's not like they take on the ethical responsibilities that engineers do. But when in Rome, speak Romansh. Or however that goes.
Yes, I hadn't really interviewed seriously for a while and it was essential to go back and re-review all the basics of trees, lists, sorting, searching etc.
Problem is there is such a wide variety of questions its hard to be prepared across the board ...
Problem is there is such a wide variety of questions its hard to be prepared across the board ...
I interview with whomever actually responds to me. :|
"We’ve seen that most engineers only have the stomach for a limited number of interviews. Investing time in the wrong companies carries a high opportunity cost."
Yet it's amazing how many companies treat candidates' time as basically worthless, and infinitely replenishable.
Yet it's amazing how many companies treat candidates' time as basically worthless, and infinitely replenishable.
Yeah, the "two week trial period" (or one week, or week-of-evenings, or whatever) is a non-starter for the experienced programmer who doesn't really need a job. And these are the folks that you want to attract.
High bars can really turn out to be self-sabotage.
High bars can really turn out to be self-sabotage.
> the "two week trial period" (or one week, or week-of-evenings, or whatever)
Good God, is this actually a thing? I mean, a probationary period after hire is one thing, but if somebody actually had the gall to tell me I'd have to spend a week or two working for them before they decided whether or not I was actually working for them, I believe I'd walk out on the spot.
Good God, is this actually a thing? I mean, a probationary period after hire is one thing, but if somebody actually had the gall to tell me I'd have to spend a week or two working for them before they decided whether or not I was actually working for them, I believe I'd walk out on the spot.
I've long felt that a lot of software companies are keener on interviewing than they are on actually hiring. There's got to be a breaking point somewhere where too much time spent interviewing is actually a net loss even if you end up finding good hires, and I wouldn't be surprised if many companies are beyond that threshold.
The company I'm at doesn't employ any magic voodoo in our hiring methods, but we somehow manage to find great people without being a revolving door for interviews. Many places are proud to say that they only make offers to 1% of the people they bring on-site, but I'm proud to say that our ratio is probably more like 25% or even 50%.
The company I'm at doesn't employ any magic voodoo in our hiring methods, but we somehow manage to find great people without being a revolving door for interviews. Many places are proud to say that they only make offers to 1% of the people they bring on-site, but I'm proud to say that our ratio is probably more like 25% or even 50%.
> companies serious about interviewing but not serious about hiring
I've been watching a friend interview with their 'dream company' over the last month. It's been quite an exhaustive process. Four rounds of interviews: a phone-screen, a take-home test that took a weekend, an all-day in-person, and a half-or-full-day remote session. They've moved beyond interview step #2 and have secured a date for interview step #3.
The way you've phrased it here is exactly what I have internalized from watching this process unfold but have been unable to articulate so succinctly. Suffice it to say, I'm not looking forward to my next job hunt.
I've been watching a friend interview with their 'dream company' over the last month. It's been quite an exhaustive process. Four rounds of interviews: a phone-screen, a take-home test that took a weekend, an all-day in-person, and a half-or-full-day remote session. They've moved beyond interview step #2 and have secured a date for interview step #3.
The way you've phrased it here is exactly what I have internalized from watching this process unfold but have been unable to articulate so succinctly. Suffice it to say, I'm not looking forward to my next job hunt.
>> have 10 days a year vacation (pretty standard)
Wait, what?
Is it really this bad in the States?
Wait, what?
Is it really this bad in the States?
In my experience in the Bay Area, jobs fall into one of three categories:
1) No paid vacation at all
2) 15-25 days of vacation a year
3) "Unlimited vacation," which is usually a hip facade for 1 or 2.
1) No paid vacation at all
2) 15-25 days of vacation a year
3) "Unlimited vacation," which is usually a hip facade for 1 or 2.
2) 15-25 days of vacation a year
Really? 25 days is 5 weeks; I feel like the standard for PTO is 10-15 days, and often it's 10 days, but you get bumped up to 15 after you work at a place for a year or two.
3) "Unlimited vacation," which is usually a hip facade for 1 or 2.
Is that really true? I have very limited first-hand experience; only two of my employers have offered unlimited vacation. For one of them, it was as you describe. For my current company... well, by the end of this calendar year, I think it'll add up to a little over 5 weeks, which is fairly unusual by US standards.
Really? 25 days is 5 weeks; I feel like the standard for PTO is 10-15 days, and often it's 10 days, but you get bumped up to 15 after you work at a place for a year or two.
3) "Unlimited vacation," which is usually a hip facade for 1 or 2.
Is that really true? I have very limited first-hand experience; only two of my employers have offered unlimited vacation. For one of them, it was as you describe. For my current company... well, by the end of this calendar year, I think it'll add up to a little over 5 weeks, which is fairly unusual by US standards.
With any vacation allocation, there are really two numbers to think about: 1) the technical number of PTO days you have been given; 2) the number of PTO days you actually feel at liberty to take. Often, though not always, #2 < #1. When this is the case, employees will "bank" PTO days and get paid for them.
As a response, many companies are switching to "unlimited" plans. These look good to the uninitiated. But the real impetus for an "unlimited" plan is that it frees the company from having to guarantee -- or pay out for -- a minimum number of days for each employee. It's not really about lifting the ceiling; it's about lowering the floor.
I'm sure there are companies out there who really do have, and make every effort to honor, "unlimited" vacation plans. But I believe these companies are the exception to the rule.
As a response, many companies are switching to "unlimited" plans. These look good to the uninitiated. But the real impetus for an "unlimited" plan is that it frees the company from having to guarantee -- or pay out for -- a minimum number of days for each employee. It's not really about lifting the ceiling; it's about lowering the floor.
I'm sure there are companies out there who really do have, and make every effort to honor, "unlimited" vacation plans. But I believe these companies are the exception to the rule.
My girlfriend worked for a startup in Seattle that offered "unlimited vacation", mainly because they didn't want to pay out employees that stock-piled unused vacation days.
In reality, it was nowhere near "unlimited vacation" as everything still needed to be approved, and it was very common for vacation requests to not be approved for a variety of business reasons. She probably ended up with ~20-25 days off per year, including stat holidays, which is the same as you'd get at Google or Microsoft.
In reality, it was nowhere near "unlimited vacation" as everything still needed to be approved, and it was very common for vacation requests to not be approved for a variety of business reasons. She probably ended up with ~20-25 days off per year, including stat holidays, which is the same as you'd get at Google or Microsoft.
For very young companies, it's also typically a case of "we don't know how to write a handbook and policies, so we'll just wing it, make up our attendance policy as we go along, and approve people's vacations on a case-by-case basis".
Since it's a young company, most employees are indespensible, and without any written guarantee saying "you have X days of vacation a year", everyone is too afraid to even ask for any time off.
I worked for one of those. I'm glad I got out. Unfortunately, I landed at a company that's ridiculously stingy with PTO (10 vacation days, 8 holidays, 7 sick days -- this is slightly mitigated by the fact that you can make up hours you miss without using PTO, so I've done things where I leave early one day but stay late the next), however because company policy requires that employees take all our vacation days every year, at least I know what their expectations are. I took a vacation this year because I knew I had the days for it and so I just filled out our standard form and gave it to my boss, knowing it would be accepted. On the contrary, I didn't take a single vacation during my time at my previous employer, and in fact I never even asked for one, because we were bouncing from crisis to crisis, and I could just imagine my boss saying "are you crazy?".
Since it's a young company, most employees are indespensible, and without any written guarantee saying "you have X days of vacation a year", everyone is too afraid to even ask for any time off.
I worked for one of those. I'm glad I got out. Unfortunately, I landed at a company that's ridiculously stingy with PTO (10 vacation days, 8 holidays, 7 sick days -- this is slightly mitigated by the fact that you can make up hours you miss without using PTO, so I've done things where I leave early one day but stay late the next), however because company policy requires that employees take all our vacation days every year, at least I know what their expectations are. I took a vacation this year because I knew I had the days for it and so I just filled out our standard form and gave it to my boss, knowing it would be accepted. On the contrary, I didn't take a single vacation during my time at my previous employer, and in fact I never even asked for one, because we were bouncing from crisis to crisis, and I could just imagine my boss saying "are you crazy?".
I just had my company go over and put this in the manual I basically took 3 days in the last two years i was like yeah we need to fix this.
It depends on the company. Some companies love the old "yes meaning no" trick.
"Can I take three weeks off in July?"
"Absolutely! But we might penalize you on your performance review."
"Can I take three weeks off in July?"
"Absolutely! But we might penalize you on your performance review."
One place I know of that, in an odd way, gives 25 is Intel, at least if you stay a while. You start at 15 days, get bumped to 20 after some years, and then every 7 years you get an 8-week sabbatical on top of that. That adds effectively another ~5.7 days/year, but taken as a bloc.
Come to the Uk, 20 days is minimum, 25 is fairly common, plus 8 bank holidays. Sick days are extra, not taken out of holiday.
Usual disclaimers about not every company etc.
Usual disclaimers about not every company etc.
I feel like the standard for PTO is 10-15 days, and often it's 10 day
Just my experience, but yeah, what I've seen is a 15 day minimum, and I don't explicitly filter out places that offer less.
Perhaps it's the type of companies I go for? If I recall correctly, Google, FB, Amazon, MS etc. all offer 15+ days for new hires, and most other large companies try to at least match them.
Just my experience, but yeah, what I've seen is a 15 day minimum, and I don't explicitly filter out places that offer less.
Perhaps it's the type of companies I go for? If I recall correctly, Google, FB, Amazon, MS etc. all offer 15+ days for new hires, and most other large companies try to at least match them.
10-15 days is definitely the norm.
Yup. 10 days paid time off is the de-facto standard for just about every company based in this country.
Some people negotiate additional PTO as part of their compensation package but I don't need to tell HN that engineers are notoriously bad at doing this.
Some people negotiate additional PTO as part of their compensation package but I don't need to tell HN that engineers are notoriously bad at doing this.
> 10 days paid time off is the de-facto standard for just about every company based in this country.
Not to mention that tech industry firms are reputed to be more generous than what is otherwise common, that sounds really low even outside of the tech industry; its lower than any company I've seen, and lower than what most sources I've seen indicate is common. [0]
[0] e.g., http://www.bls.gov/news.release/ebs.t05.htm and http://www.salary.com/time-off-paid-time-off-from-work/
Not to mention that tech industry firms are reputed to be more generous than what is otherwise common, that sounds really low even outside of the tech industry; its lower than any company I've seen, and lower than what most sources I've seen indicate is common. [0]
[0] e.g., http://www.bls.gov/news.release/ebs.t05.htm and http://www.salary.com/time-off-paid-time-off-from-work/
What's probably happening here is there are company-selected vacation days being left out of the number. You get to choose 10, but another 10 are picked by the company.
I worked as a programmer at a big boring company which did this - 10 days of company holidays, 10 days of you-get-to-choose. It's a month off total, but you only have control over 2 weeks, so it's presented as 10 vacation days.
I worked as a programmer at a big boring company which did this - 10 days of company holidays, 10 days of you-get-to-choose. It's a month off total, but you only have control over 2 weeks, so it's presented as 10 vacation days.
> What's probably happening here is there are company-selected vacation days being left out of the number.
The first source I linked provides actual averages for paid holidays, paid vacation, and paid sick leave.
10 paid vacation days is dead average for professional, technical, and related employees -- with only one year of service, and low for such employees with more service.
The first source I linked provides actual averages for paid holidays, paid vacation, and paid sick leave.
10 paid vacation days is dead average for professional, technical, and related employees -- with only one year of service, and low for such employees with more service.
Much less standard for SV engineers. I don't know of any tech company with 10.
Everywhere I've worked has had "unlimited" vacation policies. I've actually taken about 4 weeks per year.
Not in my experience for what it's worth. Every software dev position I've held in the last 10 or so years offered 4 weeks.
It's typical. Often you get 15 days/year with several years at a company. National holidays usually don't count.
I was at a start-up once where we got a new CEO who essentially canceled a week of "whole company time off" at Christmas. If you wanted that time off, it came out of your vacation. He didn't care . . . and soon after that, I didn't care, either :-)
[Didn't help that he was really scarce in the office that week...]
I was at a start-up once where we got a new CEO who essentially canceled a week of "whole company time off" at Christmas. If you wanted that time off, it came out of your vacation. He didn't care . . . and soon after that, I didn't care, either :-)
[Didn't help that he was really scarce in the office that week...]
Yes, it is. Even worse than the fact that getting 2 weeks off is considered a pretty good amount of time, there's often lots of subtle pressure (that manifests itself implicitly in project planning) to not use it all at once.
This pressure isn't universal, but I'd say the majority of the companies I've worked for hardly anyone ever took more than a week off in a go, and when they did it was the topic of uncomfortable conversation with managers kind of acting like the person taking the time off was doing something wrong (even if just kind of half-joking about it).
It really is an entirely weird situation, for all the talk of meritocracy and such the day-to-day reality is you are pressured not to take real PTO (paid time off) and instead just do the Office Space thing where you're at work almost every day even if there are periods of time where you aren't really doing anything productive for a large chunk of most days.
This pressure isn't universal, but I'd say the majority of the companies I've worked for hardly anyone ever took more than a week off in a go, and when they did it was the topic of uncomfortable conversation with managers kind of acting like the person taking the time off was doing something wrong (even if just kind of half-joking about it).
It really is an entirely weird situation, for all the talk of meritocracy and such the day-to-day reality is you are pressured not to take real PTO (paid time off) and instead just do the Office Space thing where you're at work almost every day even if there are periods of time where you aren't really doing anything productive for a large chunk of most days.
Not to mention, people come to work sick all the time, so they don't use up their precious PTO days.
It varies tremendously from company to company. 10 days is not unheard of, but for example at my job, new employees get 12 vacation days plus 15 holidays. I've been there 9 years and get 21 vacation days a year plus the same 15 holidays (my long-tenured coworkers and I often struggle to use all of our vacation; we tend to take a lot of Fridays off to stay under the six-week cap). By contrast, many low-wage jobs get no paid vacation.
My company starts at 10, then after 4 years you get 15, then after 11 years you get 20. This is in addition to 12 holiday days off a year, plus unlimited accumulation of 1 sick day per month, which can be taken any time you feel "sick".
So you start with 22 working days off including holidays, plus generous sick time. Not perfect, but could be worse.
So you start with 22 working days off including holidays, plus generous sick time. Not perfect, but could be worse.
I don't know about Silicon Valley, but in Colorado it's almost never that bad for software jobs.
In 12 years I don't recall any jobs with fewer than 15 days. My current job is "unlimited", and I took nearly 25 days one year.
In 12 years I don't recall any jobs with fewer than 15 days. My current job is "unlimited", and I took nearly 25 days one year.
Colorado is culturally much more in tune with work-life balance. Especially in Denver imo. No one brags about working 80 hours a week as that makes you sound like a loser who doesn't ski/hike/bike enough.
Same here in Portland. The companies I've been involved with here tend to take pride in their employees being active. I could see this changing as the Valley types continue to move in, however.
Yes it is. In most companies it's common to start with 10 days and then increase by 5 days with every few years of experience. Some do more; starting with 15 days is generous.
But also remember it's business days. So 10 days = 2 weeks.
But also remember it's business days. So 10 days = 2 weeks.
[deleted]
My current place (not in the Bay Area) gives 18 days after 4 years (I forget what it is before that).
It's pretty third world out there.
And yet the USA is the richest country in the world, with a culture steadily dominating and extinguishing all other cultures. There is a McDonald's in Red Square right now.
You don't make an omelet without enslaving some chickens their entire lives, keeping them in barely one cubic foot of space from birth to death so they can push out eggs at maximal productivity, killing them as soon as they're no longer at peak performance, and of course, breaking the eggs.
In other words, you get what you pay for.
You don't make an omelet without enslaving some chickens their entire lives, keeping them in barely one cubic foot of space from birth to death so they can push out eggs at maximal productivity, killing them as soon as they're no longer at peak performance, and of course, breaking the eggs.
In other words, you get what you pay for.
And now we can serve breakfast all day. Take that world!
That's definitely my perspective. I've been doing this for a very long time and it's evolved to the point where I actually start hyperventilating when thinking about interviews, at least the technical ones. I'm looking now and I don't think I can force myself through more than a few cycles before falling back to marketing/product management to avoid it.
Interesting that you think of product management as a "fallback" case. I've found getting hired as a product manager infinitely more difficult than getting hired as an engineer. For every company that says they are looking for a product person, there are at least 20 that say they are looking for engineers. Of course, the main point of my original comment still applies: "looking" definitely does not equal "hiring" in today's tech job market.
I think that I expressed that poorly. I've shifted to sales/marketing/product management but in my heart of hearts, I still think of myself as an engineer - an engineer who's been profoundly alienated from my means of production by this awful culture.
I agree with you that getting hired as a product manager isn't easy but, almost without exception (even at places like Amazon), the process is actually respectful, which makes a world of difference.
I agree with you that getting hired as a product manager isn't easy but, almost without exception (even at places like Amazon), the process is actually respectful, which makes a world of difference.
You forgot the part where, for every $100k you earn, a vacation day that you spend interviewing costs you $240 after taxes because you don't get that paid out when you quit. Or get to use it vacationing, which I value rather higher than $240/$100k since I get so few of those days.
So it's an expensive, stressful, crappy experience. Weird I don't want to do it speculatively, eh?
So it's an expensive, stressful, crappy experience. Weird I don't want to do it speculatively, eh?
I found my current job through a recruiter, I think I will find all subsequent jobs through one as well for this reason. Applying for a position is fundamentally an act of sales, so it behooves you to either be a salesman yourself or to hire someone to do it for you. Otherwise you're throwing yourself at the mercy of people's deep-seated fears and prejudices.
I think that recruiters do make sense (clearly). I hope that we can use our position as recruiters to be better than most companies at figuring out who's a good programmer, and better than most candidates at figuring out which companies are good places to work (we're candidate constrained, so we have no incentive to send people to bad companies)
True, but also consider that you're the product in this case, and the salesman (in many cases) doesn't care who he makes the sale to. It may be better to first research and shortlist companies that you want to target, and then find a recruiter who has them as a client? Never done that myself, so don't know how practical it might be.
Ultimately it comes down to how many expectations you're placing on the company you work for. If you're one of those who vets the company harder than the company vets prospects, then by all means cut out the middleman and do the legwork yourself. A hired gun is just going to get in the way.
If your job is just a vehicle to enable your lifestyle, like mine, then you'll be able to establish a set of criteria and only work with a recruiter that respects those criteria.
If your job is just a vehicle to enable your lifestyle, like mine, then you'll be able to establish a set of criteria and only work with a recruiter that respects those criteria.
That's why it's helpful to find and maintain relationships with the good recruiters. Really good recruiters are a very rare extremely valuable thing. They know how to find companies that are a good match and understand the time investment on both sides on the hiring spectrum. They are also good at identifying qualifications and requirements to avoid wasting time when it shouldn't be.
Good recruiters very much care about their reputation, because a sale isn't always a sale when either side ends up unhappy.
Good recruiters very much care about their reputation, because a sale isn't always a sale when either side ends up unhappy.
Yes, but did you hire the recruiter?
I think they are usually hired by the companies, or "loyal" to the companies, because that is were the money come from.
Would be a fun experiment to hire somebody to sell yourself. Then again, maybe that is what is usually called a "personal coach"?
I think they are usually hired by the companies, or "loyal" to the companies, because that is were the money come from.
Would be a fun experiment to hire somebody to sell yourself. Then again, maybe that is what is usually called a "personal coach"?
Recruiters, in the States at least, typically work for large recruiting shops that have many relationships with many employers. They'll contact you to try to fit a particular job, but are more than willing to match you to other jobs if you don't like that one or if it doesn't fit.
I cycled through like three recruiters before finding one with a job I was interested in. If you really like working with a particular recruiter, what you might do is look for jobs yourself and then forward those listings on to the recruiter, so he can do his thing. It's not how most recruiters are used to operating, and it's not something I've done, but I think it could work based on my previous experiences.
In my experience, recruiters are far more 'loyal' to job hunters than they are to employers, at least in tech fields. Hunters have nothing but options in who they go through and how they conduct a search. Whereas the requirements of companies are usually fixed and often are completely irrational. It's often easier to work with and influence a job seeker than it is to talk sense into an employer.
I cycled through like three recruiters before finding one with a job I was interested in. If you really like working with a particular recruiter, what you might do is look for jobs yourself and then forward those listings on to the recruiter, so he can do his thing. It's not how most recruiters are used to operating, and it's not something I've done, but I think it could work based on my previous experiences.
In my experience, recruiters are far more 'loyal' to job hunters than they are to employers, at least in tech fields. Hunters have nothing but options in who they go through and how they conduct a search. Whereas the requirements of companies are usually fixed and often are completely irrational. It's often easier to work with and influence a job seeker than it is to talk sense into an employer.
You actually take vacation days for interviews? I either call in sick or come in late. I usually provide a plausible excuse, like having to take my cat to the vet. Or maybe my foot is bothering me, and I had to wait to get an appointment.
Just the other week, I ran out for a meeting with a potential new employer in the middle of the day. All I said was I "had to run an errand." If I was less checked out, I would've made up a real excuse and told them I needed to get a blood test.
Most people are totally non-confrontational. You're not going to get called out on your little white lies. Obviously you can't use the same excuse 10 weeks in a row, so mix it up a bit.
Just the other week, I ran out for a meeting with a potential new employer in the middle of the day. All I said was I "had to run an errand." If I was less checked out, I would've made up a real excuse and told them I needed to get a blood test.
Most people are totally non-confrontational. You're not going to get called out on your little white lies. Obviously you can't use the same excuse 10 weeks in a row, so mix it up a bit.
You obviously have the luxury of being in an area with lots of potential employers. Some of us are not that lucky.
wow, I had no idea that there is no paid vacation time in US. The only country in the world. What about unpaid time off? Now I know why I hear about burnout from US developers.
EDIT: After few minutes with Google.
> USA: There is no statutory minimum. It is left to the employers to offer paid vacation days as part of the compensation and benefits package.[67] According to one survey, 98% of employers offer at least some paid leave to their employees; full-time employees earn between 6 and 20 vacation days at 86% of employers surveyed.[68] About 96% of surveyed employers give their employees paid time off during public holidays,[68] typically 6 per year.[69] Some employers offer no vacations at all.[68] The average number of paid vacation days offered by private employers is 10 days after 1 year of service, 14 days after 5 years, 17 days after 10 years, and 19 days after 20 years
> European Union legislation mandates that all 28 member states must by law grant all employees a minimum of 4 weeks of paid vacation
> Sweden: Employees are entitled to 25 work days of annual leave. Sweden also has 11 public holidays and a few that may or may not be half days.
EDIT: After few minutes with Google.
> USA: There is no statutory minimum. It is left to the employers to offer paid vacation days as part of the compensation and benefits package.[67] According to one survey, 98% of employers offer at least some paid leave to their employees; full-time employees earn between 6 and 20 vacation days at 86% of employers surveyed.[68] About 96% of surveyed employers give their employees paid time off during public holidays,[68] typically 6 per year.[69] Some employers offer no vacations at all.[68] The average number of paid vacation days offered by private employers is 10 days after 1 year of service, 14 days after 5 years, 17 days after 10 years, and 19 days after 20 years
> European Union legislation mandates that all 28 member states must by law grant all employees a minimum of 4 weeks of paid vacation
> Sweden: Employees are entitled to 25 work days of annual leave. Sweden also has 11 public holidays and a few that may or may not be half days.
There is no mandated minimum level of paid vacation time in the US. Most companies do offer some paid vacation time, but it varies from company to company (and even employee to employee, depending on negotiation skills).
As far as unpaid time off, culturally, the amount of paid vacation time you get at a company is assumed to be the maximum amount of time off you can take in the normal course of matters without putting your job at risk. Normally people only ask for unpaid time off if there's some exigent event that they have to take care of (health issues, family issues, etc.).
As far as unpaid time off, culturally, the amount of paid vacation time you get at a company is assumed to be the maximum amount of time off you can take in the normal course of matters without putting your job at risk. Normally people only ask for unpaid time off if there's some exigent event that they have to take care of (health issues, family issues, etc.).
Well, "no government-mandated minimum of paid vacation days" is a more appropriate description of your observation, judging from your EU-findings.
This is exactly why I decided to resign from my last job instead of looking for work while in it (in addition to the crippling stress that caused me to look in the first place). There simply isn't enough time to find the right fit if you don't really quite know what you're looking for - even being remote on a very open schedule the time it took to take recruiting calls, do resume and code test work was very high. Granted, I already had an offer outstanding when I decided to do that, so I was reasonably sure I would be able to bridge the gap to my next job using savings I had accrued. Now I've found an interesting job paying MUCH better than I was expecting which will in the near term greatly overmatch the investment of some of my savings in the time to look.
I was thinking on this and thought I should start a company that:
a. Pre-screens candidates on off-hours since they are likely already employed with a focus on keeping it brief out of respect for their time. b. Similarly match interviews at off-hours and perhaps moderate them to also not waste anybody's time.
I am sure there are many people that would not like this but if hiring is difficult and they want to make it rigorous I wonder if this could fit a niche. I personally am more than happy to go to an interview after work or on the weekend at a coffee shop so it doesn't cut into my job hours.
a. Pre-screens candidates on off-hours since they are likely already employed with a focus on keeping it brief out of respect for their time. b. Similarly match interviews at off-hours and perhaps moderate them to also not waste anybody's time.
I am sure there are many people that would not like this but if hiring is difficult and they want to make it rigorous I wonder if this could fit a niche. I personally am more than happy to go to an interview after work or on the weekend at a coffee shop so it doesn't cut into my job hours.
I'm also interested in this. Please email me at [email protected] to discuss in private. Others are also welcome to contact me there about this.
20 to 25 days in Western Europe. And working 32h gives you huge flexibility.
You can start shifting that extra day around for these occasions, leaving your vacation days for actual vacation ( which is 80% as is the pay ofcouse ).
You can start shifting that extra day around for these occasions, leaving your vacation days for actual vacation ( which is 80% as is the pay ofcouse ).
It's not surprising. A lot of lawyers will tell you that passing the bar was one of the more grueling things they've had to do. Here's a blog post about a guy who did it with 100 hours of study.
http://blakemasters.com/post/37113468298/pass-the-ca-bar-exa...
The bar exam is three grueling days. 100 hours of study is two and a half weeks of full time work.
If you interview at three tech companies, I don't think it's at all over the top to say you might study for a few weeks in total, especially if you are rusty, and the interviews are often quite grueling as well and do last all day….
Ok, I'm stretching, I won't put one iteration of interviews at bar exam levels, but we are starting to get there. Now keep in mind, we do this over and over and over in our field. And while the bar is tough, at least you know roughly what will be tested - tech interviews are often a completely moving target. And while the bar does have continuing education requirements, you don't have to do the 3 day massive study thing over and over (unless, in some cases, you move to a new state).
I really do think this is a severe problem in our industry that causes higher levels of attrition than we realize. I suppose it could be one of those "tragedy of the commons" type things, where each company benefits from long and difficult interviews, but the cumulative result is either 1) people not wanting to enter the field, or 2) people giving up on interviewing for new jobs and staying with their existing employer even if they are burned out, or 3) people quitting and going into a different field or role entirely where they can escape this hazing.
I also think this is something hiring managers should realize before saying that there is a a shortage of programmers. Your own interview processes may be contributing substantially to this "shortage".
Oh, one last thing - excellent article, thank you for writing it! Absolutely fascinating, and it explains a great deal.
http://blakemasters.com/post/37113468298/pass-the-ca-bar-exa...
The bar exam is three grueling days. 100 hours of study is two and a half weeks of full time work.
If you interview at three tech companies, I don't think it's at all over the top to say you might study for a few weeks in total, especially if you are rusty, and the interviews are often quite grueling as well and do last all day….
Ok, I'm stretching, I won't put one iteration of interviews at bar exam levels, but we are starting to get there. Now keep in mind, we do this over and over and over in our field. And while the bar is tough, at least you know roughly what will be tested - tech interviews are often a completely moving target. And while the bar does have continuing education requirements, you don't have to do the 3 day massive study thing over and over (unless, in some cases, you move to a new state).
I really do think this is a severe problem in our industry that causes higher levels of attrition than we realize. I suppose it could be one of those "tragedy of the commons" type things, where each company benefits from long and difficult interviews, but the cumulative result is either 1) people not wanting to enter the field, or 2) people giving up on interviewing for new jobs and staying with their existing employer even if they are burned out, or 3) people quitting and going into a different field or role entirely where they can escape this hazing.
I also think this is something hiring managers should realize before saying that there is a a shortage of programmers. Your own interview processes may be contributing substantially to this "shortage".
Oh, one last thing - excellent article, thank you for writing it! Absolutely fascinating, and it explains a great deal.
Imagine going on a date and after the fourth time being like "I still don't know if I like you, need more tests". I tend to get impatient with companies who ask for yet another round of interviews because I think either they like me or they don't.
Maybe the issue is too risky to employ somebody? In my country a lot of laws protect employees, so it might be difficult to get rid of bad hires (although in the first 6 months I think it is easy, as they count as probation period).
Maybe the issue is too risky to employ somebody? In my country a lot of laws protect employees, so it might be difficult to get rid of bad hires (although in the first 6 months I think it is easy, as they count as probation period).
The USA does not have this excuse. It is easier to fire someone here than anywhere else in the developed world.
I'm down to 2 days out of my 10. I used to take a day if they had a big "tech screening" over the phone but now I'm adamant about doing them after hours.
>Almost no one passes all their programming interviews
But there is always someone who will, and many companies are more than happy to pass on all candidates until the find someone who days. I was super happy that my interviewer yesterday said we were skipping the whiteboard section.
>Almost no one passes all their programming interviews
But there is always someone who will, and many companies are more than happy to pass on all candidates until the find someone who days. I was super happy that my interviewer yesterday said we were skipping the whiteboard section.
Of course, if one plans things well, one has the leeway to leave one job and take a few weeks off before finding another...
Not everyone is comfortable with the unknown of not having a job lined up. Even the most technically skilled developers may not pass all of their interviews and some companies, especially the bigger ones, can take a huge amount of time.
What you say is true to a degree; if you have plenty of money saved up then you can spend a lot of time unemployed but this ultimately looks poorly on your resume at some companies and most people live closer to paycheck to paycheck than anything else.
What you say is true to a degree; if you have plenty of money saved up then you can spend a lot of time unemployed but this ultimately looks poorly on your resume at some companies and most people live closer to paycheck to paycheck than anything else.
I would never leave a job before finding a new one. Too much uncertainty especially in today's rough hiring market. You'd want at least 6 months of living expenses saved up to burn while you job search, probably more, and most people don't have that.
I don't think you could pay me enough to work for a company that only offered 10 days a year vacation on principle.
This is probably it. I bit the bullet and scheduled 2 weeks off, and filled up those days with onsite interviews. It sucked to have to take those many vacation days but ultimately worth it.
I've found in the past that companies are pretty willing to work with me and let me split interview day between two days. It's worth asking.
But just to undermine that point, I've also learned that it's quite complex to try to juggle multiple job interview processes with a day job, especially if you want to be able to make a choice with multiple offers on the table. It ended up working out for me this past time, but next time I'm ready to make a move (hopefully not for years!), I may just resign first, so I'd be able to devote my full attention to making the right move.
But just to undermine that point, I've also learned that it's quite complex to try to juggle multiple job interview processes with a day job, especially if you want to be able to make a choice with multiple offers on the table. It ended up working out for me this past time, but next time I'm ready to make a move (hopefully not for years!), I may just resign first, so I'd be able to devote my full attention to making the right move.
> Let's say you are working already and have 10 days a year vacation (pretty standard).
Until my current gig, I was never once allowed vacation time.
Until my current gig, I was never once allowed vacation time.
A good example of why working at a place with such restrictive PTO is a trap. But, around here we like to have philosophical discussions about how unlimited vacation time is the real trap. I dunno, guys. It seems to work pretty well for me.
I ask for five weeks/year, even if it means I have to forgo some pay. I have yet to be told no.
I don't think you've ever experienced the passive aggressiveness that comes with using "unlimited" vacation time.
I don't think you've ever experienced the passive aggressiveness that comes with using "unlimited" vacation time.
Yup. Before I went into independent consulting, five weeks was a non-negotiable point for me. And I largely went into consulting specifically to take more time off. Life's too short.
Exactly. EXACTLY!
I'm not going to lay on my death bed and wish I had another couple lines of code committed.
I'm not going to lay on my death bed and wish I had another couple lines of code committed.
...Are you looking? ;) Email's in my profile.
That's why I went into consulting as well: six weeks off a year was priceless to me. But I've recently accepted a permanent role again, with less time off than I've had in years, simply because of the huge salary.
It's a little humbling to realize that I had a price, after all.
It's a little humbling to realize that I had a price, after all.
Six weeks? Next year I'm taking twelve. ;) Maybe more. I've always wanted to aimlessly travel a little.
Taking a perm role for a big salary isn't a bad thing, either. That money can be turned into more time off (as long as you don't die first, but that's the gamble, right?). I'd personally rather take it up front while I'm young, but the other way around does work too.
Taking a perm role for a big salary isn't a bad thing, either. That money can be turned into more time off (as long as you don't die first, but that's the gamble, right?). I'd personally rather take it up front while I'm young, but the other way around does work too.
Or just start off with a proper number of days. Two weeks seems so short, especially if you get sick. 15 days total seems about right.
Was just having this conversation -- is there any precedent for offering different teams and/or differing levels of tenure different vacation packages? My husband used to work at Groupon and said it was really challenging to give all entry-level sales people unlimited vacation because they tended to abuse it. However, unlimited vacation may work well for more tenured positions or even for different types of teams (engineering / design?) We thought this might be too tricky to administrate / unfair, but it does seem that it can be a useful and underabused perk for some and a disaster for others.
In big companies, doing it by tenure with the company is common. A typical schedule is something like: start at 2 weeks/yr, and get an extra week/yr for every 5 years you stay with the company, topping out at 6 weeks/yr. That model has run into trouble as people change jobs more, and is uncommon in the Valley where people change jobs even more than that. Some companies have ditched it, while others will negotiate giving you credit for past jobs, e.g. I believe if Exxon hires you away from a 20-year career with BP, they'll often give you equivalent seniority at Exxon for benefits purposes.
It's definitely done. A traditional method is that the longer you've been at a place, the more vacation you earn. Another technique I've seen is to have a divide, eg "VP and above get an extra 5 days per year."
Facebook, Google, etc commonly use the contractor technique, where anyone you want to work for you but not give benefits becomes an independent contractor, or works for a vendor. Eg, the cooks in the Facebook kitchens.
Facebook, Google, etc commonly use the contractor technique, where anyone you want to work for you but not give benefits becomes an independent contractor, or works for a vendor. Eg, the cooks in the Facebook kitchens.
Yeah - I've seen tiered vacation days based on seniority, but I'm wondering specifically about giving some folks unlimited and others a prescribed number of days. That seems to straddle an almost philosophical issue.
If it's possible to abuse it then it's not really unlimited. Why not just decide what is appropriate and put it in the contract, so everyone agrees how much vacation they can take?
Also there's no reason everyone has to receive the same amount. Indeed that would be very unusual.
Also there's no reason everyone has to receive the same amount. Indeed that would be very unusual.
Another great thing about the country I work in ATM: 5 weeks "paid" vacation each year (of course this means salaries are slightly lower, but nice anyway)
Edit: And, you are supposed to use them. Not making sure your employees spend their holiday days can land at least the company if not the employee as well in legal hot water.
Edit: And, you are supposed to use them. Not making sure your employees spend their holiday days can land at least the company if not the employee as well in legal hot water.
I know a guy that was a CTO I the valley( I think he may have reported to Vint at one point) and in the UK and he commented that he got the same amount of work even though the UK firm was ex civil service and had 5 + weeks leave
The problem is to my boss "unlimited" might mean 15 days and to me it might mean 4 month. If we come in with wildly different ideas about what is OK, we're both going to end up very unhappy.
Or you could have a straightforward discussion with him/her about your expectations.
The real issue with unlimited PTO is that many people are so conflict-adverse (except on the internet) that they cannot initiate basic conversations about how much vacation time they think is reasonable. And instead of taking responsibility for communicating their expectations like adults, they stew in resentment against their employer for shifting that responsibility onto them.
If your employer balks at your idea of reasonable time off, then you might think about switching employers. But if you balk at the idea of having some input into your employer's expectations of you, then you need to take more responsibility, or move to a company with a less collaborative culture.
The real issue with unlimited PTO is that many people are so conflict-adverse (except on the internet) that they cannot initiate basic conversations about how much vacation time they think is reasonable. And instead of taking responsibility for communicating their expectations like adults, they stew in resentment against their employer for shifting that responsibility onto them.
If your employer balks at your idea of reasonable time off, then you might think about switching employers. But if you balk at the idea of having some input into your employer's expectations of you, then you need to take more responsibility, or move to a company with a less collaborative culture.
Why are you positioning this like it's the employee's fault? I've had a gig with "unlimited" vacation time where my boss was very quietly stewing that he thought I was taking too much time. Never said anything to me until two weeks before I left.
It is in all cases management's job to set these expectations, and their fault when they're not understood on both ends of things. That's why they're management. (And why "unlimited" policies are stupid.)
It is in all cases management's job to set these expectations, and their fault when they're not understood on both ends of things. That's why they're management. (And why "unlimited" policies are stupid.)
The whole reason you have policy and leadership is to handle these kinds of situations though. People are conflict averse, especially when they are not in a position of power over the person they need to talk with.
I agree you and your manager should talk and agree on what number of days is reasonable. That's why you should have a number and not "unlimited".
Edit: What I really meant..
Poor choice of words on my part. Take it in this context: "Person X doesn't have a stomach for hard engineering problem Y".
"Doesn't have the stomach for" now can be interpreted as a synonym for:
* Is not capable of
* Is not smart enough for
* Is not hard working enough for (!)
In the current environment I definitely shouldn't have brought up gender.
Poor choice of words on my part. Take it in this context: "Person X doesn't have a stomach for hard engineering problem Y".
"Doesn't have the stomach for" now can be interpreted as a synonym for:
* Is not capable of
* Is not smart enough for
* Is not hard working enough for (!)
In the current environment I definitely shouldn't have brought up gender.
The thing about looking to be offended is that you can find it everywhere without really even trying. Being offended by that phrase definitely qualifies.
You do, of course, have the natural right be offended by anything. That doesn't mean people have the responsibility to not offend you. In fact, in America, home of HN, we explicitly have the right to offend you.
You do, of course, have the natural right be offended by anything. That doesn't mean people have the responsibility to not offend you. In fact, in America, home of HN, we explicitly have the right to offend you.
This kind of nonsense comment has got to stop. It's reaching the point of ridiculousness.
Edit: Was originally some kind of nonsense about the expression "doesn't have the stomach for" being "a jab at masculinity" or something.
Edit: Was originally some kind of nonsense about the expression "doesn't have the stomach for" being "a jab at masculinity" or something.
I guess I've not seen that many westerns, but I really was not aware that the stomach was a gendered organ.
[deleted]
I'm an "enterprise" programmer because I write in Java... I'm also older than the average age of a start-up employee (late twenties). I've never written a line of Ruby, and I've never written object oriented JavaScript or used Node.js.
However, I'm a really good programmer. I just happen to write the majority of my code in Java. If tomorrow we decided to use a new language, I could pick it up in a few days... I have a feeling the "enterprise" thing is just veiled age-ism. Anyone can feel free to correct me if I'm wrong, but at this point, it's literally impossible to learn every new technology. And anyone whose worth their salt should be able to learn a new environment and programming language without too much trouble.
I have a feeling that the enterprise thing is just a way for these employers to screen out the older, more experienced programmers.
This will probably get this throwaway banned, but Michael O'Church (who I am not) writes a lot about this on his blog. I tend to agree with him.
However, I'm a really good programmer. I just happen to write the majority of my code in Java. If tomorrow we decided to use a new language, I could pick it up in a few days... I have a feeling the "enterprise" thing is just veiled age-ism. Anyone can feel free to correct me if I'm wrong, but at this point, it's literally impossible to learn every new technology. And anyone whose worth their salt should be able to learn a new environment and programming language without too much trouble.
I have a feeling that the enterprise thing is just a way for these employers to screen out the older, more experienced programmers.
This will probably get this throwaway banned, but Michael O'Church (who I am not) writes a lot about this on his blog. I tend to agree with him.
Author here. Ageism is real, and we'll be analyzing it in a future post. But in this case I don't think it's ageism. I think it's big-company-ism. Startups define themselves in opposition to big companies, and take signs of big company culture as strong negatives (which may or may not be justified statistically, I honestly don't know). But there are great programmers at big companies in any case, and startups should figure out how to hire them.
Startups should realize that this is a thoroughly idiotic notion, and should abandon it ASAP. The one thing that large software companies do well is SHIP PRODUCTS. A good software engineer is someone who can ship a product, even if its ill-defined or not feature-complete. This is a virtue. Small companies, especially startups, have a horrible track record for shipping software that in any way resembles its product plan.
At my startup, candidates from large companies are immediately prioritized in the hiring queue. This strategy has always paid off; there is a high correlation between large company experience and good software engineering practices.
At my startup, candidates from large companies are immediately prioritized in the hiring queue. This strategy has always paid off; there is a high correlation between large company experience and good software engineering practices.
Which large companies have you worked for? I've worked in both environments and seen way more failed projects on the enterprise side.
However when an enterprise ships something, the shipped product tends to be more stable. There's tradeoffs to be made and large companies often prioritize stability and their reputation over time to market and spending money.
As a startup, I would look for people who have less specialized experience and are able to cover as many of my bases as possible. Can the developer field a page at 2am and login to the production environment to fix a problem? Can the developer help my sales people with a desktop support issue while the lone IT guy is on vacation? Can the developer make the product work on a single AWS micro instances until we get some sort of traction/funding?
The theme here is a scrappy, do-whatever-it-takes mindset that's often missing in the enterprise where people learn to CYA lest the bureaucracy come down on them for cutting corners.
However when an enterprise ships something, the shipped product tends to be more stable. There's tradeoffs to be made and large companies often prioritize stability and their reputation over time to market and spending money.
As a startup, I would look for people who have less specialized experience and are able to cover as many of my bases as possible. Can the developer field a page at 2am and login to the production environment to fix a problem? Can the developer help my sales people with a desktop support issue while the lone IT guy is on vacation? Can the developer make the product work on a single AWS micro instances until we get some sort of traction/funding?
The theme here is a scrappy, do-whatever-it-takes mindset that's often missing in the enterprise where people learn to CYA lest the bureaucracy come down on them for cutting corners.
The big problem I see with this idea is that scrappy, do-whatever-it-takes people almost never write clean code, checkin cleanly, test properly, and practice good product design. I value these things more than "rugged individualism". Furthermore, if your software team is doing sales, that's a really bad allocation of talent. Even the tinyest of startups should have dedicated roles for the other dimensions of your business (e.g. Sales, Support, HR, CTO). You pit 2 teams against one another with the goal of producing a great product, and one team has a wide spectrum of talent, the other has great software engineering discipline, I would bet on the latter team every time.
>good software engineering practices
Definitely aware of several hot startups that don't seem to value this at all. Well it's a tradeoff that they are hopefully consciously making.
Definitely aware of several hot startups that don't seem to value this at all. Well it's a tradeoff that they are hopefully consciously making.
How does that jive with the statistic in the article that engineers that have worked at companies like Google, Microsoft, Apple, Facebook, and Amazon pass interviews 30% more of the time. These are all very big companies.
If startups are so opposed to big companies, shouldn't having these on your resume be seen as being negative?
If startups are so opposed to big companies, shouldn't having these on your resume be seen as being negative?
Funny thing is, despite Ageism, supposedly there is a massive "shortage" of developers.
Hiring manager here, and after many interviews with enterprise programmers, I do find myself putting more and more of them into the "no" pile right off the bat.
The problem is that those candidates, in my experience, tend to throw up way more red flags than others - their code is extremely verbose, they rattle off factory patterns like they're reading a textbook without any inkling what sort of problems they're actually solving, they parrot popular opinions without being able to articulate the reasoning behind them, they're not comfortable with developing a new feature without extensive documentation, and they miss the forest for the trees when it comes to things like testing and code organization.
Enterprise programmers usually leave me with the impression that they're heavily indoctrinated into one specific mode of thought, and that they would struggle to break out of it.
The problem is that those candidates, in my experience, tend to throw up way more red flags than others - their code is extremely verbose, they rattle off factory patterns like they're reading a textbook without any inkling what sort of problems they're actually solving, they parrot popular opinions without being able to articulate the reasoning behind them, they're not comfortable with developing a new feature without extensive documentation, and they miss the forest for the trees when it comes to things like testing and code organization.
Enterprise programmers usually leave me with the impression that they're heavily indoctrinated into one specific mode of thought, and that they would struggle to break out of it.
Most of this is fixable by driving YAGNI into their heads.
Beyond that, I would claim that most people startups look for (recent graduates) have no ability to understand the reason behind popular opinions. Because they don't have the experience to do so. They might be able to parrot it though.
Interestingly, I'm used to working in a pretty fluid environment without a lot of specs. But we recently started developing something with very tight rules and an extremely picky end user. It's much less efficient without a set of specs, which the project managers didn't have the constitution to make since we aren't used to doing so. As a result I basically have to constantly go back to them on things, which isn't very productive.
Beyond that, I would claim that most people startups look for (recent graduates) have no ability to understand the reason behind popular opinions. Because they don't have the experience to do so. They might be able to parrot it though.
Interestingly, I'm used to working in a pretty fluid environment without a lot of specs. But we recently started developing something with very tight rules and an extremely picky end user. It's much less efficient without a set of specs, which the project managers didn't have the constitution to make since we aren't used to doing so. As a result I basically have to constantly go back to them on things, which isn't very productive.
It's funny you say that. I can't name one factory pattern off the top of my head... Never needed to learn one. I should clarify -- I'm in my late twenties, and I've spent my entire career (10 years) writing Java code. I don't understand how that negatively hiring managers against me.
Have you worked at multiple jobs over those 10 years? As a hiring manager (working with only the limited data you've provided here) I'd be concerned that you value stability very highly, and you might be thrown by the rate of change (in requirements, tools used, business goals, desired feature set, etc) that is typical of a startup. Long tenure at a single job suggests you enjoy getting deeply specialized and developing mastery of a stable set of tools, which is needed at a certain stage of company but not at most early-stage startups.
Is that true of you? I.e. would you be frustrated by 3-4x/year significant churn in your technological tooling and top-level business goals? Would you be excited to learn a few new toolsets? If so, why haven't you done that on your own?
Is that true of you? I.e. would you be frustrated by 3-4x/year significant churn in your technological tooling and top-level business goals? Would you be excited to learn a few new toolsets? If so, why haven't you done that on your own?
Wow. Really? Why is stability a concern? Much of engineering is making solid decisions and fucking sticking with them rather than changing to the latest toolset because that's what hacker news says is the best today. Are you trying to build a product and company, or a blog post?
Stability is a concern because startups are not stable. In 6 months time Apple could open source something that makes your last 5 years of work irrelevant in a night. If you can't ship in 6 months you're company will probably have shut up shop in 12 because someone already ate your lunch.
If it's a choice between stability (via proper testing, architecture, etc.) and staying operating, stability loses every time.
No matter what happens the tech world is a different place in a year. You have to adapt regardless so properly thought out code will get thrown out just as easily as 4am hacks.
If it's a choice between stability (via proper testing, architecture, etc.) and staying operating, stability loses every time.
No matter what happens the tech world is a different place in a year. You have to adapt regardless so properly thought out code will get thrown out just as easily as 4am hacks.
"Would you be excited to learn a few new toolsets?"
I suspect by the 3rd or 4th time in the same year with people who haven't worked out what it is they are trying to achieve my level of excitement might be wearing a bit thin.
I suspect by the 3rd or 4th time in the same year with people who haven't worked out what it is they are trying to achieve my level of excitement might be wearing a bit thin.
Is this really true of the startup world? What possible business reason could there be for swapping your stack / tooling 3-4x per year?
Do you mean learning something new 3-4 times per year that is unrelated to large architectural changes?
In terms of 'on your own'--I don't know, maybe this person has a life outside of writing code?
Do you mean learning something new 3-4 times per year that is unrelated to large architectural changes?
In terms of 'on your own'--I don't know, maybe this person has a life outside of writing code?
My opinion is learning design patterns are very important to being a really good programmer.
Patterns (and Anti-patterns) are an extremely useful part of software development, specifically because they help engineers be more efficient at solving problems with code.
Factory, funny enough, is the name of a design pattern.
And for good measure, DRY Violation is a good anti-pattern to pick up (though I suspect you know that already even if you can't name it).
Patterns (and Anti-patterns) are an extremely useful part of software development, specifically because they help engineers be more efficient at solving problems with code.
Factory, funny enough, is the name of a design pattern.
And for good measure, DRY Violation is a good anti-pattern to pick up (though I suspect you know that already even if you can't name it).
Well sorry to be crude, but it just signals that you're all talk. You say you're a great programmer, and could learn to program in Ruby in a few days, yet in 10 years you've never done it, even though you are apparently applying for jobs that are interested in that skill.
If you can't even bother with learning the language that's requested in the advert in a few days, why should a hiring manager be interested in you?
I'm also in my late twenties, and have been programming for money for over 10 years and I also like to brag about how I'm a great programmer and am fluent in over a dozen programming languages, but you bet that if I'd go for a job that requests Node.JS experience (I wouldn't), I'd brush up on my Node.JS and make sure my resume lists it as a core competency. You can't just go around saying you're a great programmer and expect people to believe it from ten years of Java experience.
If you can't even bother with learning the language that's requested in the advert in a few days, why should a hiring manager be interested in you?
I'm also in my late twenties, and have been programming for money for over 10 years and I also like to brag about how I'm a great programmer and am fluent in over a dozen programming languages, but you bet that if I'd go for a job that requests Node.JS experience (I wouldn't), I'd brush up on my Node.JS and make sure my resume lists it as a core competency. You can't just go around saying you're a great programmer and expect people to believe it from ten years of Java experience.
> Well sorry to be crude, but it just signals that you're all talk.
We ask people to avoid this kind of personal slight in HN comments because it inevitably lowers the discussion. You can make a substantive point without resorting to that, so please do.
We ask people to avoid this kind of personal slight in HN comments because it inevitably lowers the discussion. You can make a substantive point without resorting to that, so please do.
Who ever said I was interviewing for a job? I was commenting on the state of the industry as a whole. Read some of the comments (and the article). The article mentioned that one person who multiple companies thought was the best they have ever seen got rejected from the first company he interviews with because he didn' write tests. Hiring is so subjective.
This comment in particular really illustrates the sad state of our industry, and why I don't usually write comments on the Internet and why I wrote this under a throwaway account. Thanks for making my point:
To repeat: "You're all talk." "If you can learn Ruby in a few days why haven't you done it yet over the last 10 years?"
Here's why: I made well over 400K this year at my job. I am not jumping through hoops killing myself to learn new things I may not even need. My time away from work is too precious to me.
By the way, I am paid 400K because I am a really good programmer and problem solver and can use whatever tools I need to to get the job done. It doesn't matter if I've never used the language before. I will figure it out.
Plus: most places won't even talk to me because I make more than what they are willing to pay. Oh wait; I guess this is all talk too.
PS: If patio11 is reading this comment, I will happily verify these facts with him via my real personal email. To prove that this comment isn't just "all talk". I really hate the Internet sometimes.
This comment in particular really illustrates the sad state of our industry, and why I don't usually write comments on the Internet and why I wrote this under a throwaway account. Thanks for making my point:
To repeat: "You're all talk." "If you can learn Ruby in a few days why haven't you done it yet over the last 10 years?"
Here's why: I made well over 400K this year at my job. I am not jumping through hoops killing myself to learn new things I may not even need. My time away from work is too precious to me.
By the way, I am paid 400K because I am a really good programmer and problem solver and can use whatever tools I need to to get the job done. It doesn't matter if I've never used the language before. I will figure it out.
Plus: most places won't even talk to me because I make more than what they are willing to pay. Oh wait; I guess this is all talk too.
PS: If patio11 is reading this comment, I will happily verify these facts with him via my real personal email. To prove that this comment isn't just "all talk". I really hate the Internet sometimes.
I'm slightly busy this week with the impending launch of Stockfighter and would prefer to not be HN's designated notary public, as I'm just another geek here, but if you want to chat about career stuff my inbox is always open. (Offer good for anybody.)
FWIW I have _zero_ difficulty believing "finance company pays talented programmers $400k" and equally zero difficulty believing "startup folks mystified how this could possibly happen when that programmer hasn't even installed NodeJS."
FWIW I have _zero_ difficulty believing "finance company pays talented programmers $400k" and equally zero difficulty believing "startup folks mystified how this could possibly happen when that programmer hasn't even installed NodeJS."
Well with this kind of compensation, wherever you live, if you needed to find a new job I guess you could probably survive a month or two without a paycheck, learn a new language and do a pet project, contribute to open source.
Of course when you work full time, 60h/week, and don't want to resign from current job while seeking a new one, it's pretty hard, but I can assure you it's as hard for anyone else working full time.
Learning new tech stack in spare time is not easy, and you can't and shouldn't learn all of them, 'cause in a few years half of the stuff you learn today will be obsolete.
Of course when you work full time, 60h/week, and don't want to resign from current job while seeking a new one, it's pretty hard, but I can assure you it's as hard for anyone else working full time.
Learning new tech stack in spare time is not easy, and you can't and shouldn't learn all of them, 'cause in a few years half of the stuff you learn today will be obsolete.
I should work in finance.
Yes. You should if you want to make a lot of money...
If you only care about money.
BTW, making $400k in finance is not particularly high. Nor is it evidence that you're a great programmer. Finance companies have to pay huge premiums to attract and retain people.
Just about any programmer can make 2x working on Wall Street. Very few good programmers are willing to work for these finance companies. It doesn't seem like you've thought much about why that is.
BTW, making $400k in finance is not particularly high. Nor is it evidence that you're a great programmer. Finance companies have to pay huge premiums to attract and retain people.
Just about any programmer can make 2x working on Wall Street. Very few good programmers are willing to work for these finance companies. It doesn't seem like you've thought much about why that is.
Finance companies do have incredible technical and regulatory challenges that require good programmers. There are a number of strong programmers who work in finance and are indeed attracted to some of the challenges around finance. I have worked across a number of banks and each has had its own challenges and I have worked with talented and motivated programmers working to solve these.
I'd be really interested to know the rough details of your work situation. Sounds like you've got a pretty good thing going.
What sort of company do you work for? Is it a government contractor? I've known many highly paid people in that line of work that are not fit for startups.
All I'm willing to say here is that I work in financial services.
Actually, one of the reasons why I mentioned patio11 above was because it would interesting to talk to him about this kind of stuff given he's also trying to change how tech companies hire talent.
I've thought about trying his star fighter project, but it's another example of "invest a lot of time on the side in doing something tangentially related to work that may be construed as fun, and you can maybe get an interview from it".
That's what has been illustrated in a lot of the comments on this thread. "Why not learn Ruby?" "Why not contribute to OSS on the side?" "Why not keep up with new technologies?" It's work, that's why. Sure, it can be fun and fulfilling but I already spend 55-60 hours a week doing this stuff, and I have other interests. Am I really expected to do all of this stuff on the side just to get a job at a highly desirable place like a YC startup?
Let's use star fighter as an example. I already work in financial services. To some people who work on apps and user interface design and have never worked in financial services before, I could get the appeal of working on something new... But to me, star fighter is just doing my job outside of work hours in an attempt to get another job. I would rather keep solving problems at my own company, and increase my value to them in the process...
...but that means I'll just write more "Enterprise" Java, and not learn new things! It's a catch-22.
Actually, one of the reasons why I mentioned patio11 above was because it would interesting to talk to him about this kind of stuff given he's also trying to change how tech companies hire talent.
I've thought about trying his star fighter project, but it's another example of "invest a lot of time on the side in doing something tangentially related to work that may be construed as fun, and you can maybe get an interview from it".
That's what has been illustrated in a lot of the comments on this thread. "Why not learn Ruby?" "Why not contribute to OSS on the side?" "Why not keep up with new technologies?" It's work, that's why. Sure, it can be fun and fulfilling but I already spend 55-60 hours a week doing this stuff, and I have other interests. Am I really expected to do all of this stuff on the side just to get a job at a highly desirable place like a YC startup?
Let's use star fighter as an example. I already work in financial services. To some people who work on apps and user interface design and have never worked in financial services before, I could get the appeal of working on something new... But to me, star fighter is just doing my job outside of work hours in an attempt to get another job. I would rather keep solving problems at my own company, and increase my value to them in the process...
...but that means I'll just write more "Enterprise" Java, and not learn new things! It's a catch-22.
If you're making $400k, but you don't really love your job, my suggestion would be to save as much money as you can, to the point that you can become financially independent. Then you can start your own startup if you want; or take a year off, half to relax and half to learn some new stuff, and get a different job, if that's what you want.
I'd be very grateful if I can talk to you about your journey / career path. Could you shoot me an email (mailshanx at yahoo dot co dot in)? I'll be immensely grateful if do :)
I'm not saying you're all talk, I said you signal you're all talk. If you don't have issues getting a job, why are you posting about the state of hiring here? It makes no sense. You've got replies trying to understand if there's ageism that's dragging you down, but you have a 400k job.
edit: I am sorry I offended you. I really did not mean to say that you are all talk, I thought we were talking about how Java programmers should apply to SV jobs and was trying to give you a hiring side perspective, but I guess I am a bit tired and I misread your point.
edit: I am sorry I offended you. I really did not mean to say that you are all talk, I thought we were talking about how Java programmers should apply to SV jobs and was trying to give you a hiring side perspective, but I guess I am a bit tired and I misread your point.
Hmm, maybe these "signals" you're reading are not actually good predictors of either skill or marketability.
benihana(1)
>Enterprise programmers usually leave me with the impression that they're heavily indoctrinated into one specific mode of thought, and that they would struggle to break out of it.
That's been my impression as well, both coming from the enterprise and interviewing people from that domain. The most deleterious thing I've noticed is a lot of them, like GP, are convinced they're really good programmers and the reason they can't break out of the Enterprise is because startups are biased against some arbitrary and unimportant part of their identity (like their age), not their actual abilities and attitude. I say this as a guy who's likely half a decade older than a guy in his late 20s who thinks he's too old to work at a startup.
That's been my impression as well, both coming from the enterprise and interviewing people from that domain. The most deleterious thing I've noticed is a lot of them, like GP, are convinced they're really good programmers and the reason they can't break out of the Enterprise is because startups are biased against some arbitrary and unimportant part of their identity (like their age), not their actual abilities and attitude. I say this as a guy who's likely half a decade older than a guy in his late 20s who thinks he's too old to work at a startup.
Valve calls this "beaten wife syndrome" and apparently it often goes away after a while (if not, they fire the new hire).
The first time I read your post I missed the parenthetical in the first paragraph, and was inclined to agree with you. Then I looked again and saw "(late twenties)", and had to laugh.
On the one hand, you're right, you can't learn everything. On the other, to be able to realistically claim that you can pick up new languages quickly, you should already know three or four different kinds of languages. If all you know is Java, you probably are farther away than you think from picking up a very different language like Ruby. I would encourage you to do some study on the side. Your late twenties is far too early to let yourself get pigeonholed.
On the one hand, you're right, you can't learn everything. On the other, to be able to realistically claim that you can pick up new languages quickly, you should already know three or four different kinds of languages. If all you know is Java, you probably are farther away than you think from picking up a very different language like Ruby. I would encourage you to do some study on the side. Your late twenties is far too early to let yourself get pigeonholed.
>I'm also older than the average age of a start-up employee (late twenties)
I took this to mean that the average startup employee is in their late twenties, and he is somewhat older than that
I took this to mean that the average startup employee is in their late twenties, and he is somewhat older than that
Oh, you must be right. Silly of me.
Actually, it seems your first understanding was actually correct: https://news.ycombinator.com/item?id=10698634
I am pigeonholed.
Sure I know other languages: Shell Scripting, Perl, HTML/CSS/JS, Groovy, SQL, C#, etc, but 80 percent of the code I write is in Java. I'm at a Java shop and have golden handcuffs. It's Java or bust for me.
Sure I know other languages: Shell Scripting, Perl, HTML/CSS/JS, Groovy, SQL, C#, etc, but 80 percent of the code I write is in Java. I'm at a Java shop and have golden handcuffs. It's Java or bust for me.
Don't doubt yourself. There are a lot of great companies hiring Java developers; you don't have to worry yourself about the standard YCombinator group.
> I just happen to write the majority of my code in Java. If tomorrow we decided to use a new language, I could pick it up in a few days...
The languages in your list are:
* declarative: HTML, CSS, Groovy (for Gradle), SQL
* scripting: Shell, Perl, JS, Groovy (for testing)
* Java-clones: C#
I found it difficult to pick up Clojure and Haskell "in a few days" when all I had was experience in those types of languages. In fact, mastering each of those languages requires a change in thinking that can only occur over a much longer time.
The languages in your list are:
* declarative: HTML, CSS, Groovy (for Gradle), SQL
* scripting: Shell, Perl, JS, Groovy (for testing)
* Java-clones: C#
I found it difficult to pick up Clojure and Haskell "in a few days" when all I had was experience in those types of languages. In fact, mastering each of those languages requires a change in thinking that can only occur over a much longer time.
I agree with you about Clojure in particular.
I did do some non trivial work in Lisp in a graduate class, but its not the same as using it all day. I don't believe I would seek out an opportunity where a Lisp dialect was the programming language of choice, anyway...
(I found ML to be easier to work with than Lisp. I guess it's technically not a pure functional language though).
I did do some non trivial work in Lisp in a graduate class, but its not the same as using it all day. I don't believe I would seek out an opportunity where a Lisp dialect was the programming language of choice, anyway...
(I found ML to be easier to work with than Lisp. I guess it's technically not a pure functional language though).
Neither is Lisp a pure functional language, though it might have been taught that way in your class.
I'm also working mostly in Java recently, and our project has a small amount of Scala (left over form and engineer long since gone). I am finding it really hard, on the rare occasions when I need to work on the Scala part, to get my head around it. I know I need a week or two to "get" Scala - but I just can't justify the time.
[deleted]
The parent could be stating that late twenties is the average age of startup founders, not that that they are in their late twenties themselves.
I do agree with you that someone who claims to pick up new languages in a week should already have picked up a few languages. The grandparent says they only do the _majority_ of their programming in Java, so perhaps they have that covered. I'd love to know what the other languages they've chosen are, and their dissimilarity to Java.
I don't know how to evaluate their claim that they're a really_good programmer, given that it's a throwaway account. But then, given the data of this article, I guess no one does.
I do agree with you that someone who claims to pick up new languages in a week should already have picked up a few languages. The grandparent says they only do the _majority_ of their programming in Java, so perhaps they have that covered. I'd love to know what the other languages they've chosen are, and their dissimilarity to Java.
I don't know how to evaluate their claim that they're a really_good programmer, given that it's a throwaway account. But then, given the data of this article, I guess no one does.
I've written a lot of code in both Ruby and C#. Like a parent, I love both of them for completely different reasons.
From a pure language standpoint, Java and C# are _really_ well-designed tools. I call them "Cathedral Languages" after esr's "Cathedral and the Bazaar" -- both were designed by highly-qualified teams of experts who had the privilege of spending years designing them, after already spending collectively many lifetimes doing language design. For examples of what I'm talking about, look at C#'s implementation of generics. Look at the quality of .NET or Java's multi-generational mark-and-sweep garage collector implementations. Ruby has a lot of warts. It's slow. MRI/REE are children's toys compared to the CLR or JVM. Ruby's implementation of coroutines (blocks vs. procs vs. lambdas) is a huge mess, its concurrency story is terrible, it has nothing like .NET's async/await...I could go on, but I feel the point is made.
However...
It's easy, when using .NET and Java, since they're such "batteries-included" languages, to get into the mindset that "I'll never need another tool", which is _manifestly_ untrue. I am a committed polyglot programmer and I am appalled how frequently I encounter "cultural ignorance" within the big enterprise language communities. So I think the issue is more cultural (O'Church writes about this), one of trying to avoid "Java Shop Politics", with the associated ManagerFactorySingletonImpls, needing to write about 100 lines to get a single thing done, etc. The problem is the cultural baggage that many enterprise developers bring with them, not the language itself.
In my current project, I'm doing small-program development in .NET for a Windows LOB project. It's pretty refreshing. I get all the benefits of UNIX-style systems design, i.e.. small composable program elements, services, Git (TFS? are you kidding me?), proper CI/CD, and command-line automation, alongside the maturity of not having to deal with breaking changes on point releases of OSS libs, a thoroughly-documented, consistent BCL (.NET Framework 4.5), high-quality runtime, and generally less "hipster" culture. I'd highly recommend it.
From a pure language standpoint, Java and C# are _really_ well-designed tools. I call them "Cathedral Languages" after esr's "Cathedral and the Bazaar" -- both were designed by highly-qualified teams of experts who had the privilege of spending years designing them, after already spending collectively many lifetimes doing language design. For examples of what I'm talking about, look at C#'s implementation of generics. Look at the quality of .NET or Java's multi-generational mark-and-sweep garage collector implementations. Ruby has a lot of warts. It's slow. MRI/REE are children's toys compared to the CLR or JVM. Ruby's implementation of coroutines (blocks vs. procs vs. lambdas) is a huge mess, its concurrency story is terrible, it has nothing like .NET's async/await...I could go on, but I feel the point is made.
However...
It's easy, when using .NET and Java, since they're such "batteries-included" languages, to get into the mindset that "I'll never need another tool", which is _manifestly_ untrue. I am a committed polyglot programmer and I am appalled how frequently I encounter "cultural ignorance" within the big enterprise language communities. So I think the issue is more cultural (O'Church writes about this), one of trying to avoid "Java Shop Politics", with the associated ManagerFactorySingletonImpls, needing to write about 100 lines to get a single thing done, etc. The problem is the cultural baggage that many enterprise developers bring with them, not the language itself.
In my current project, I'm doing small-program development in .NET for a Windows LOB project. It's pretty refreshing. I get all the benefits of UNIX-style systems design, i.e.. small composable program elements, services, Git (TFS? are you kidding me?), proper CI/CD, and command-line automation, alongside the maturity of not having to deal with breaking changes on point releases of OSS libs, a thoroughly-documented, consistent BCL (.NET Framework 4.5), high-quality runtime, and generally less "hipster" culture. I'd highly recommend it.
I work in an enterprise environment though my skill set is mostly on the admin side. Ageism may play a part in the bias against enterprise workers, but other factors exist as well - whether justified or not.
1) Over-specialization - the vogue for startups is to hire full-stack engineers, which to me reads as a desire to have one person perform the work of three. The constraints of a startup environment may justify such desires.
2) Risk-aversion - many of us in enterprise environments groan about all of the meetings, deferments of decisions to superiors / domain experts, and other risk-avoidance strategies, but in the end we like our butts covered just like everyone else.
3) Tolerance / preference for a certain amount of friction - some might call this a lack of urgency or an excess of complacency. Consider the problem of selecting a platform for your new project. In most enterprise environments, the decision has already been made for you - what is on the approved product / vendor list? Another is how to get a person who reports to a different chain of command to do their job.
All of these factors and others seem to exist at odds with the startup culture, which is a general term for the composite self-image of a startup's founders. Generally, they see themselves as pirates who plunder market share from the lumbering galleons of large enterprises, at least until they sell.
1) Over-specialization - the vogue for startups is to hire full-stack engineers, which to me reads as a desire to have one person perform the work of three. The constraints of a startup environment may justify such desires.
2) Risk-aversion - many of us in enterprise environments groan about all of the meetings, deferments of decisions to superiors / domain experts, and other risk-avoidance strategies, but in the end we like our butts covered just like everyone else.
3) Tolerance / preference for a certain amount of friction - some might call this a lack of urgency or an excess of complacency. Consider the problem of selecting a platform for your new project. In most enterprise environments, the decision has already been made for you - what is on the approved product / vendor list? Another is how to get a person who reports to a different chain of command to do their job.
All of these factors and others seem to exist at odds with the startup culture, which is a general term for the composite self-image of a startup's founders. Generally, they see themselves as pirates who plunder market share from the lumbering galleons of large enterprises, at least until they sell.
I think a lot of companies want to hire people who also have programming as a hobby. It seems if this was true it would be very unlikely that someone would be a seasoned great programmer who only ever programmed in one language. I'd be curious why this candidate never wanted to try other styles/approaches.
I never understood why that was a prerequisite. I program for 60 hours a week. So what if I don't want to do it on the weekends too.
Depending on your situation, maybe you could try to push some new technologies to your current company? (could be hard, depends what company, I guess you work in finance, well that's double hard then)
Anyway, personal anecdote: I know a guy who was a Java programmer for almost a decade, in a Java-heavy corporate environment. The company's been also investing in frontend for a while. Being bored with Java development, he learnt JS, and started following angularjs (stackoverflow, github issues etc.) in his spare time (a bit in the morning, a bit in the evening, just regularly), and within a year, with the support of a senior manager, basically became a "free-electron" angular evangelist inside the company.
The transition was pretty fluent, now he works on angular-related stuff full-time.
Anyway, personal anecdote: I know a guy who was a Java programmer for almost a decade, in a Java-heavy corporate environment. The company's been also investing in frontend for a while. Being bored with Java development, he learnt JS, and started following angularjs (stackoverflow, github issues etc.) in his spare time (a bit in the morning, a bit in the evening, just regularly), and within a year, with the support of a senior manager, basically became a "free-electron" angular evangelist inside the company.
The transition was pretty fluent, now he works on angular-related stuff full-time.
Unfortunately, tinkering in your off-hours is a key way for programmers to keep their skills current. The industry changes rapidly and the skills that were most marketable over the past 10 years are not the same as those that will be most marketable over the next 10. If you're not changing jobs constantly, the rate of tech change at your workplace is unlikely to be enough to keep your skills marketable. So you need to tinker.
This is one reason why people 40+ with kids tend to migrate into management. Their technical skills are getting rusty and having kids decimates your ability to take on major tinkering projects that help you learn new skills. However, their people skills are evergreen and even sharpened by their experience as parents.
This is one reason why people 40+ with kids tend to migrate into management. Their technical skills are getting rusty and having kids decimates your ability to take on major tinkering projects that help you learn new skills. However, their people skills are evergreen and even sharpened by their experience as parents.
Why is this not true in other professions? Why don't hospitals give preference to surgeons who like to dissect frogs in their spare time or build better scalpels on their garage workbench?
I know you are being rhetorical but to those that don't know it's because surgeons have a proper profession that protects surgeons from management/lobbyists/politicians etc bossing them around.
Software developers don't have such protection and any mention of such a thing will get you blackballed within the industry by employers and ostracized by peers as most have bought in to the narrative that cooperating is bad for the individual.
However, my SO is a physician and they spend A LOT of time on skill mastery beyond med school and residency, however, their keeper is their profession, not their employer which is a major difference.
Software developers don't have such protection and any mention of such a thing will get you blackballed within the industry by employers and ostracized by peers as most have bought in to the narrative that cooperating is bad for the individual.
However, my SO is a physician and they spend A LOT of time on skill mastery beyond med school and residency, however, their keeper is their profession, not their employer which is a major difference.
> However, my SO is a physician and they spend A LOT of time on skill mastery beyond med school and residency, however, their keeper is their profession, not their employer which is a major difference.
I spend a lot of time outside my job on skill mastery as well. I do not do it in ways or domains that translate into pretty Github portfolios.
I spend a lot of time outside my job on skill mastery as well. I do not do it in ways or domains that translate into pretty Github portfolios.
I think average surgeon's skills are probably pretty sharp (pun intended), however, in my experience the knowledge of a regular small-town GP's indeed usually is not very up-to-date.
Regarding the OP's question: new hip languages and frameworks evolve way faster than human body, and "it works" is more important in medicine than "iterate and fail fast" (hopefully:)
My personal theory is also that partially the high expectations are due to open source / hacker ethos (there's generally no medical open source movement, or in any profession outside of IT AFAIK, at least on such scale). The cycle goes like this:
- some folks want to do something cool for fun and/or to get some fame for showing it to the public, or get famous for inventing a known lib/framework
- companies see they're smart and hire them
- other companies follow the trend, and require open source contributions or at least building space shuttle over the weekend
- a number of devs don't want to lag behind, so they join the bandwagon, and they create even more cool stuff and even more open source MVC frameworks
- now, the cycle reinforces itself, everyone is doing cool stuff and contributing to opensource, if you don't, you're excluded
edit: fixed typos
Regarding the OP's question: new hip languages and frameworks evolve way faster than human body, and "it works" is more important in medicine than "iterate and fail fast" (hopefully:)
My personal theory is also that partially the high expectations are due to open source / hacker ethos (there's generally no medical open source movement, or in any profession outside of IT AFAIK, at least on such scale). The cycle goes like this:
- some folks want to do something cool for fun and/or to get some fame for showing it to the public, or get famous for inventing a known lib/framework
- companies see they're smart and hire them
- other companies follow the trend, and require open source contributions or at least building space shuttle over the weekend
- a number of devs don't want to lag behind, so they join the bandwagon, and they create even more cool stuff and even more open source MVC frameworks
- now, the cycle reinforces itself, everyone is doing cool stuff and contributing to opensource, if you don't, you're excluded
edit: fixed typos
I don't think software is all that exceptional in this regard. Any profession has certain visible achievements that distinguish its world-class members. For software, it's cool open source projects; for chefs, it's creating a great restaurant; for doctors, it's publishing influential novel research.
In each of these fields, the visible achievement isn't exactly the same as great performance in the field. You can get unlucky in scientific research and end up with nothing publishable; you can cook mediocre food but market it really well; or you can create the latest trendy build system instead of just mastering Gnu Make.
The misleading thing may be the assumption that most successful open source software projects are done by unpaid hackers on their own time. Perhaps that used to be the case, but many of the hot open source projects in recent history -- from Rails to Docker to React to Swift -- are built on the clock by successful programmers employed at big and small companies. But software is unusual in that serious contributions can be made by people without any institutional support.
In each of these fields, the visible achievement isn't exactly the same as great performance in the field. You can get unlucky in scientific research and end up with nothing publishable; you can cook mediocre food but market it really well; or you can create the latest trendy build system instead of just mastering Gnu Make.
The misleading thing may be the assumption that most successful open source software projects are done by unpaid hackers on their own time. Perhaps that used to be the case, but many of the hot open source projects in recent history -- from Rails to Docker to React to Swift -- are built on the clock by successful programmers employed at big and small companies. But software is unusual in that serious contributions can be made by people without any institutional support.
Good point. This is possible for surgeons because medicine is a stricter hierarchy of professions that software: you decide to become a surgeon or a nurse or a PA early in your career, compete for that privilege, and don't change. Advanced specialist doctors often work in teaching hospitals and devote a large chunk of their time to research; at lower-level medical professions, you might get continuing education credits. These tiers are well established over many years in the industry and the schools that train the next generations of participants.
I'd say that top achievers in the software industry can also command similar benefits, but the mechanism is different. Instead of leveraging a credential into research and leveraging cool research stories into grant funding, software people get to do what they want by leveraging hard work, luck, and great stories about what they can do into great jobs or investor dollars. There are pros and cons to each system, but one big virtue of the less structured software world is that it tends to respond to market opportunity a lot more efficiently than something like medicine.
I'd say that top achievers in the software industry can also command similar benefits, but the mechanism is different. Instead of leveraging a credential into research and leveraging cool research stories into grant funding, software people get to do what they want by leveraging hard work, luck, and great stories about what they can do into great jobs or investor dollars. There are pros and cons to each system, but one big virtue of the less structured software world is that it tends to respond to market opportunity a lot more efficiently than something like medicine.
Doctors are already required to perform continuing education beyond their normal work duties (ie still meet their quotas). These requirements have actually been getting more and more onerous over the years. My mother works in primary care, and the house always has medical related magazines and journals all over the place.
So if you are in medicine, you are required to at least go through the motions of keeping up on things.
So if you are in medicine, you are required to at least go through the motions of keeping up on things.
Because surgeons are already workaholics with insane work/life balance issues, perhaps? Same for many other professions.
What? Doctors have to do a crazy amount of education in off-work hours.
I find my singleness/childlessness to be a MAJOR strategic advantage in the modern workplace. Because I can travel more and take on clients outside of the HQ area, I provide a value that other people can't. Still moved into management, but I can also stay on top of new technologies and remain agile.
Indeed so what, but do you program on weekends anyway? At least sometimes? Earlier in the thread you complained about golden handcuffs. That indicates there's something you'd rather be doing than your work, but the pay is too good to leave. I scratch my own itches with occasional weekend or night coding and usually it's for the fun of it, learning or keeping up with the trends can be a side benefit but not the goal. Often I work with one-off projects like coding a game using a new engine in a functional language. If I didn't need or like money as much I might just do these fun projects all the time. I think this personality of programming-as-hobby is pretty common in the field, and when we run into people who program strictly on the job and never any other time, who started programming only in college when they decided to get a degree and only did work for assignments or internships before getting hired, they may be really talented programmers on the job (which is why you can say "so what") but something feels off culturally. It'd be like meeting a guitarist who rocks with the best of them on stage while being paid but never plays off-the-clock or seems to have any interest in the instrument or the scene or the genres of play beyond their ability to make money. https://news.ycombinator.com/item?id=7423626 makes the point well that for many programmers, we're just potheads whose potheadery became valuable.
60? Isn't that already your weekends?
Requiring programming in off-hours is pretty nuts, but in general if you're in a huge-stability big-corp programming job you're not going to be changing tools often and that will have consequences when you want to be hired at a startup.
I think age-ism is part of it.
However, being an Enterprise dev myself (kind of), I feel that Startups don't think Enterprise devs "move" fast enough. They are too busy abstracting things and trying to get to the holy grail of the "perfect" architecture. Startups don't necessarily care about that right away, but enterprise devs have been steeped in it.
However, being an Enterprise dev myself (kind of), I feel that Startups don't think Enterprise devs "move" fast enough. They are too busy abstracting things and trying to get to the holy grail of the "perfect" architecture. Startups don't necessarily care about that right away, but enterprise devs have been steeped in it.
Yeah well, that depends on whether you're used to working on a mature project with lots of structure and process (and usually, customers) or something newer where you're more in POC mode.
I'd favor someone who could do either but I guess if you have to pick one or the other I'd take "hack and ship" over "let's make it perfect", especially considering the second probably has lots of great options at BigCo.
I'd favor someone who could do either but I guess if you have to pick one or the other I'd take "hack and ship" over "let's make it perfect", especially considering the second probably has lots of great options at BigCo.
> If tomorrow we decided to use a new language, I could pick it up in a few days...
If all you've written is OO code, this is probably false bravado.
Chances are you're not going to be productive in Prolog or APL in a few days without some prior exposure to those concepts.
If all you've written is OO code, this is probably false bravado.
Chances are you're not going to be productive in Prolog or APL in a few days without some prior exposure to those concepts.
I'll just point out (as a much older engineer than you), that this article is HIGHLY skewed to YC Companies, that have self-selected as not solving hard technical problems.
As a founder, being in YC is probably great.
As an engineering employee, it doesn't seem all that compelling to work for a YC company compared to a non-yc company. None of the benefits of being a YC founder seemingly apply to an employee of a YC company.
This feels like serious echo-chamber nonsense that has little applicability outside the world of startups (and more likely YC startups).
Glassdoor just listed the top companies to work for. https://www.glassdoor.com/Best-Places-to-Work-LST_KQ0,19.htm
Airbnb (YC company). First job i found on their careers page (note, required a lot of clicking...):
https://www.airbnb.com/careers/departments/position/90884
Back End: We write lots of micro-services, primarily with Java 8. Our APIs are RESTful and use the minimal Dropwizard framework, and we take advantage of Kafka, Spark, Hadoop for processing volumes of data.
And Zillow (not I skipped Facebook,Google, and Linkedin, and went to Zillow as it's the first Seattle based company listed).
http://www.zillow.com/jobs/openings?j=oXn70fwb
Strong experience with Java, Objective-C or C++
As a founder, being in YC is probably great.
As an engineering employee, it doesn't seem all that compelling to work for a YC company compared to a non-yc company. None of the benefits of being a YC founder seemingly apply to an employee of a YC company.
This feels like serious echo-chamber nonsense that has little applicability outside the world of startups (and more likely YC startups).
Glassdoor just listed the top companies to work for. https://www.glassdoor.com/Best-Places-to-Work-LST_KQ0,19.htm
Airbnb (YC company). First job i found on their careers page (note, required a lot of clicking...):
https://www.airbnb.com/careers/departments/position/90884
Back-end, Front-end, Full Stack and Machine Learning engineers.
Strong proficiency in any of: C/C++, Java, Python, Ruby-on-Rails
Exposure to architectural patterns of a large, high-scale web application
Rigor in A/B testing, test coverage, and other web best practices
Back End: We write lots of micro-services, primarily with Java 8. Our APIs are RESTful and use the minimal Dropwizard framework, and we take advantage of Kafka, Spark, Hadoop for processing volumes of data.
And Zillow (not I skipped Facebook,Google, and Linkedin, and went to Zillow as it's the first Seattle based company listed).
http://www.zillow.com/jobs/openings?j=oXn70fwb
Strong experience with Java, Objective-C or C++
The difference in skillset and mindset in a large organization vs a startup is pretty huge. A large organization values stability and conformity (your software must work within usually a much larger picture), whereas in a startup the organization values speed and flexibility (large business changes or new data may come in at any point). The challenge when coming in from a big company is convincing people you can "hack" it to get things done quickly while still bringing the monolith of process and organizational knowledge from the big company.
age-ism for somebody in the late twenties? That sounds, ... dunno, exaggerated or even ridiculous.
I'd expected age-ism to start at the 50s or maybe 40s, but then I'm not in Silicon Valley either :-)
I'd expected age-ism to start at the 50s or maybe 40s, but then I'm not in Silicon Valley either :-)
Can not find it now but apparently the average age of a developer in Facebook is way below 30 (27 IIRC).
I guess it could be true that in some startups if you're 29 and everyone is 22 you're not perceived a "cultural fit" (my evidence on it is purely from HN threads though)
I guess it could be true that in some startups if you're 29 and everyone is 22 you're not perceived a "cultural fit" (my evidence on it is purely from HN threads though)
More likely it's just an inability to judge the programming skills of someone writing in a language you are unfamiliar with. My guess is that most YC founders don't write in C# or Java. Whether it behooves them to screen those applicants out is another question.
> I've never written a line of Ruby
I say this exact same thing on my Linkedin profile: "I have never written a line of Ruby... but I bet you can make me if it comes to that."
I say this exact same thing on my Linkedin profile: "I have never written a line of Ruby... but I bet you can make me if it comes to that."
Anybody who expects you to know every new technology is a fool. The most important thing is being able to teach yourself the new technology and figure out its kinks.
[deleted]
[deleted]
> However, I'm a really good programmer.
How do you know?
How do you know?
Plead see previous comment about my compensation. I don't think a company would pay someone that much unless they were really good.
I don't expect any job actually programming pays more than that, even if you are literally doing 1 1/2 jobs (60 hrs/wk). Only way to get that kind of pay and work for someone else is as an executive and a higher up VP/CTO/CIO etc.
Keep that job and don't spend all that money in one place. You might be one of those folks who can retire while they are (relatively) young.
Keep that job and don't spend all that money in one place. You might be one of those folks who can retire while they are (relatively) young.
That's actually the plan... And then maybe join a SV start up because money doesn't matter anymore...
Going to be tough to do as an enterprise Java developer though. =P.
Going to be tough to do as an enterprise Java developer though. =P.
Naw, just learn a new language or two when you quit.
Haskell is a particularly good choice. After fighting with Java generics for decades I found it really nice to work with a real type system.
Also, go is trivial for an experienced Java programmer to master.
Haskell is a particularly good choice. After fighting with Java generics for decades I found it really nice to work with a real type system.
Also, go is trivial for an experienced Java programmer to master.
So... I worked with over 50 engineers prepping for their first SF/Silicon Valley tech interviews. And I worked at Groupon, interviewed at a bunch of YC companies (including one where I took a job).
In my experience pretty much nobody is taking Ben Horowitz's advice from The Hard Thing About Hard Things—hire based on strength instead of a perceived lack of weakness. Instead everyone seems to be looking for candidates who fill out all the boxes and have zero thumbs down in interviews. That coupled with extreme risk aversion means long interview cycles, and huge amounts of wasted time for some of the most talented employees and founders on the planet.
In my experience pretty much nobody is taking Ben Horowitz's advice from The Hard Thing About Hard Things—hire based on strength instead of a perceived lack of weakness. Instead everyone seems to be looking for candidates who fill out all the boxes and have zero thumbs down in interviews. That coupled with extreme risk aversion means long interview cycles, and huge amounts of wasted time for some of the most talented employees and founders on the planet.
Well, they sort of are, just not explicitly. The standard process is to have 2 to 5 interviewers, each asking their own question, and pass everyone who get at least one strong yes, and no strong noes. This ends up with a random factor, but ultimately favoring people at least one real strength. The interviewer who sees this strength will fight for them. We've seen people with high skill variance (great at one thing, bad at others) pass interviews at a higher rater than people who are just OK at everything.
Most of those interview questions, don't really have much to do with the way someone actually works. I just went through one of those SV gauntlets at a YC startup, and got a yes, but at no point I thought any of the interviews were any good: Not enough time to actually learn about the interviewer, or solve a problem that a recent graduate couldn't solve. I know some awesome people that wouldn't have passed my interview, and I know people I'd never want to work with that would have passed.
The whole thing made me see why the situation in SV is so screwed up: If we can't really ask for things that show real experience levels, and it's all about short term first impressions, set by interviewers that aren't even necessarily any good at interviewing, how can we improve?
I've always much preferred interviews that asked for the same amount of time, but where people could show a picture of their real output, instead of a little puzzle.
Imagine you are hiring a chef to man your restaurant, and what you ask him to do is get through Chopped: Give him secret ingredients, and ask to make a dish using all of them in 15-20 minutes. You'll be testing something: Some people will do better than others. But are the things you are testing really going to matter, in practice, when what a chef really has to do quickly is to execute a well known, practiced menu, along with kitchen management skills?
We don't test for the things we do at jobs, and therefore, we can't hire. Not a surprise.
The whole thing made me see why the situation in SV is so screwed up: If we can't really ask for things that show real experience levels, and it's all about short term first impressions, set by interviewers that aren't even necessarily any good at interviewing, how can we improve?
I've always much preferred interviews that asked for the same amount of time, but where people could show a picture of their real output, instead of a little puzzle.
Imagine you are hiring a chef to man your restaurant, and what you ask him to do is get through Chopped: Give him secret ingredients, and ask to make a dish using all of them in 15-20 minutes. You'll be testing something: Some people will do better than others. But are the things you are testing really going to matter, in practice, when what a chef really has to do quickly is to execute a well known, practiced menu, along with kitchen management skills?
We don't test for the things we do at jobs, and therefore, we can't hire. Not a surprise.
> no strong noes
This is the problem. It allows one interviewer with a pet peeve to torpedo an otherwise excellent hire. Where I work, whoever ends up on the wrong side of the majority needs to make a case good enough to convince the majority to switch. Being strongly in the minority is not good enough.
The culture of accepting high false negative rates leads to the "no weaknesses" hiring the GP was complaining about.
This is the problem. It allows one interviewer with a pet peeve to torpedo an otherwise excellent hire. Where I work, whoever ends up on the wrong side of the majority needs to make a case good enough to convince the majority to switch. Being strongly in the minority is not good enough.
The culture of accepting high false negative rates leads to the "no weaknesses" hiring the GP was complaining about.
I agree, but this is also a management failing, in not noticing the pattern.
I've been able to successfully hire good people by noting that some interviewers are never satisfied with any candidate. Once the pattern is clear, I either remove them from the hiring process, or politely disregard their opinion.
Hiring only with 100% consensus is a sucker's game. Some of my best hires have involved judging which "no" could be overridden safely.
I've been able to successfully hire good people by noting that some interviewers are never satisfied with any candidate. Once the pattern is clear, I either remove them from the hiring process, or politely disregard their opinion.
Hiring only with 100% consensus is a sucker's game. Some of my best hires have involved judging which "no" could be overridden safely.
Yeah, I totally agree. We actually asked YC Companies about their fire rates. The fire rate at most of the companies was under 6% (documenting a high false negative rate approach)
Isn't it kind of weird that startup culture is supposed to be all about failing fast, MVP, and pivoting, but when it comes to hiring, it has to be perfect from the start?
Hiring is a critical piece of running a startup. It's one of the few things a startup can control, so hiring choices should be as close to perfect as one can manage. Also, the hiring philosophy at most startups is closer to the 'fail fast' principle than you think. The universal piece of advice is to fire someone quickly when you realize you made a bad hire.
This seems really low in an environment where the consequences of firing are minimal in terms of legal and financial cost (even for the employee, who can probably quickly find another job in this industry). Is this rate much lower for programmers than for other functions? Do you think that's because programmers tend to be nice people and firing someone is highly confrontational?
> Almost no one passes all their programming interviews. This is true because of randomness in many interview processes (even great people are bad at some things, and an interviewer focusing on this can yield a blocking no).
Reading this is somewhat reassuring. I've been over some interviews lately and I had some trouble getting past the tech phone screen.
One particular rejection was very frustrating, because I've spend quite some time preparing for the interview. Failed the first one. Got a second chance. And I knew it was over about 5 minutes after it began. "Can you write an algorithm that would sort efficiently this k-sorted array with a complexity strictly inferior to O(n log n)?". Yeah. No. Neither my job nor my hobbies includes sorting almost sorted arrays of integers, and O(n) complexity calculations.
It really seems to me that, being hired by a tech company is just completely random. Tech interviews in general are completely random. "Just a numbers game"
Reading this is somewhat reassuring. I've been over some interviews lately and I had some trouble getting past the tech phone screen.
One particular rejection was very frustrating, because I've spend quite some time preparing for the interview. Failed the first one. Got a second chance. And I knew it was over about 5 minutes after it began. "Can you write an algorithm that would sort efficiently this k-sorted array with a complexity strictly inferior to O(n log n)?". Yeah. No. Neither my job nor my hobbies includes sorting almost sorted arrays of integers, and O(n) complexity calculations.
It really seems to me that, being hired by a tech company is just completely random. Tech interviews in general are completely random. "Just a numbers game"
It's not "completely random". It's a process biased toward false negatives with some variance.
I've managed to land some really stellar opportunities, and I've bombed several opportunities that are better, worse, and on par with my experience. Please get lucky and unlucky. The truth is, it's hard to tell which category you belong to.
It's best to just try your best and try not to get discouraged. Someone will notice if you're talented, eventually.
I've managed to land some really stellar opportunities, and I've bombed several opportunities that are better, worse, and on par with my experience. Please get lucky and unlucky. The truth is, it's hard to tell which category you belong to.
It's best to just try your best and try not to get discouraged. Someone will notice if you're talented, eventually.
Not completely random, but by my estimation being self-taught fully 40-60% of engineering organizations (trending higher as they get bigger) care much more deeply about academic CS than they do about whether you're able to ship a product. Those companies are looking for people who fit a mold (a generalized interface) so they can scale their teams out. Startups and smaller companies tend to value people who are flexible and can learn new things very quickly and are less likely to test you on alg analysis and are much more likely to throw you an unfamiliar problem and see how you solve it.
I agree, I've been far more successful with startups than with bigger organizations. The irony is, I have a Master's degree in software engineering, but I never gave (until now) too much attention to these common O(n) sorting problems. In practice, I would end up using whatever standard library's default sort function and it would be perfectly okay for most use cases.
I wish tech screens didn't rely so much on these exercises; I have limited brain space and I don't like to archive more important stuff.
I wish tech screens didn't rely so much on these exercises; I have limited brain space and I don't like to archive more important stuff.
Well, you could argue that maybe they aren't looking for somebody to use a library, maybe they're looking for someone to write a library.
At the end of the day that sort of interview process is a super huge red flag anyway.
You don't want to work with people that value that sort of knowledge over actual ability to ship good code.
Unless of course you are one of those people that cares about toy problems ofcourse, then you probably do want to work with other people like you.
You don't want to work with people that value that sort of knowledge over actual ability to ship good code.
Unless of course you are one of those people that cares about toy problems ofcourse, then you probably do want to work with other people like you.
If you're really concerned and want to change that, I had great success with one of those books of practice interview questions. It sounds cheesy, but (obvious in retrospect) simply practicing the reasoning patterns tested in that kind of interview helped me do well in them.
This is why I don't really interview my sub-contractors. If I run into someone at a meetup that I think seems smart, I ask them if they'd be interested in picking up a small project. If they accept, I... give them a small project. No resumes. No demeaning interrogation. Straight to work on something real. And I pay them.[0]
If they do well, I give them another one. If they don't, I tell them I'm sorry but I don't have any more work for them.
Thinking more deeply on the issue, I think I want to know as little about a potential candidate as possible.[1] I don't want to bias myself against them. I've had a lot of bad experiences in my career and I'm sure I'm not perfect at keeping my prejudices to myself. I want to get people into the chair as soon as possible, get them working, and judge from the work. Once I see work getting done, it's really easy to ignore everything else.
[0] I don't think I can even make someone do an "interview assignment" for free. I'd be receiving something of value--their labor--but I'd have no accounting of it for taxes and I have no desire to try to figure out how to keep track of something like that.
[1] Yeah, I'll say this probably includes whether or not they have any experience with programming. If they can't do the job, we'll find out soon enough. If they can do the job to a satisfactory degree, why do I need know how long they've been doing it before? Give people a chance to surprise you.
If they do well, I give them another one. If they don't, I tell them I'm sorry but I don't have any more work for them.
Thinking more deeply on the issue, I think I want to know as little about a potential candidate as possible.[1] I don't want to bias myself against them. I've had a lot of bad experiences in my career and I'm sure I'm not perfect at keeping my prejudices to myself. I want to get people into the chair as soon as possible, get them working, and judge from the work. Once I see work getting done, it's really easy to ignore everything else.
[0] I don't think I can even make someone do an "interview assignment" for free. I'd be receiving something of value--their labor--but I'd have no accounting of it for taxes and I have no desire to try to figure out how to keep track of something like that.
[1] Yeah, I'll say this probably includes whether or not they have any experience with programming. If they can't do the job, we'll find out soon enough. If they can do the job to a satisfactory degree, why do I need know how long they've been doing it before? Give people a chance to surprise you.
Very cool! Wish more companies approached it like this.
I'm not a java programmer (my knee jerk reaction to quickly bang out an MVP would mostly be python), but this negative attitude towards Java seems unfair. There's a lot more to the Java universe than just enterprise Java. There are companies using Java that do cool stuff at large scale, and very reliable. Netflix is heavily Java, and nobody would (at least I wouldn't) argue that their tech is dull. Even if you are looking for pure hip factor, there's things like vert.x, and all these other JVM languages, which are not Java per se, but one of the selling points of those languages is it can utilize tons of libraries in the java ecosystem if needed. The last argument against java would be its verbosity and productivity (lack of), but I'd argue Java has one of the best IDE support among all languages, which helps alleviate the problem significantly.
"Two large YC companies (both with machine learning teams) have told us that they consider interest in ML a negative signal."
I wonder why this is? Since ML/AI are currently "hot" those programmers may be trend followers? Or maybe interest in ML is correlated with being a junior programmer (those that are more senior specialized when ML/AI were not so cool and consequently are in different domains)?
I wonder why this is? Since ML/AI are currently "hot" those programmers may be trend followers? Or maybe interest in ML is correlated with being a junior programmer (those that are more senior specialized when ML/AI were not so cool and consequently are in different domains)?
Not at a YC company, but yeah my guess would be that it's hard to get the trend followers on board with other stuff. I've anecdotally seen myself a lot of candidates (esp at the recent-university/recent-MS level) who've taken some ML courses cause it's trendy and sounds interesting but (a) don't have a serious enough interest in it or knowledge of how to apply it well enough to be a good fit on our ML teams and (b) aren't open to other roles because they sound less cool or have a perception that the day to day work will be more tedious.
Author of the post. I think that this is exactly right. I don't know what motivated the companies to put that policy in place (they just told us that they had this preference). But I can speculate. There is an epidemic of interest in ML. Four out of 5 college grads we speak to list it as an interest. I think that interest has grown to the point where it's no longer any kind of signal about technical strength, and perhaps a signal that the candidates will not be flexible about what they work on.
I'd be curious to hear about the inverse. Have you found there are skills/disciplines that companies are highly interested in but no candidates are?
What about we academic programmers who have real experience and knowledge about ML. Is that still a negative sign? Or does the academic part make it worse :)
Has age, race and gender discrimination been looked at?
Totally agree with this.
Many candidates I see that have a "strong interest" in machine learning have no idea wtf machine learning really entails; they are listing it as an interest because it is a buzzword and "sounds hard". Most of them have just used scikit-learn once or twice, and have no idea about statistics.
(also not at a YC company)
Many candidates I see that have a "strong interest" in machine learning have no idea wtf machine learning really entails; they are listing it as an interest because it is a buzzword and "sounds hard". Most of them have just used scikit-learn once or twice, and have no idea about statistics.
(also not at a YC company)
Most likely because if you are doing ML and do not have a PhD (or previous experience), you are just looking at calling a library function that you do not understand. The majority of 'machine learning meetups' (not in the Bay Area), are attended by programmers that are looking to figure out how to call an R package to give them recommendations or similar items in a list (clustering).
edit I just read the other replies to this post. I believe that most startups with Machine Learning teams are doing more than just calling R-libraries; most development work that I've done for myself and teams has been for tooling and operationalizing data infrastructure (i.e. data engineering, not data science). However if you need a simple recommendation for an app then calling the library methods without 100% understanding may be enough (but calling library methods without underlying understanding is a bad trait in a programmer (e.g. calling the sort() function without understanding quicksort)).
edit I just read the other replies to this post. I believe that most startups with Machine Learning teams are doing more than just calling R-libraries; most development work that I've done for myself and teams has been for tooling and operationalizing data infrastructure (i.e. data engineering, not data science). However if you need a simple recommendation for an app then calling the library methods without 100% understanding may be enough (but calling library methods without underlying understanding is a bad trait in a programmer (e.g. calling the sort() function without understanding quicksort)).
I am a statistician working in the data sciences. I see lots of programmers show interest but do not have the depth of knowledge in mathematics and statistics. They can apply libraries and do 80% fine but do not have the educational background to side step assumptions and pitfalls.
>Most likely because if you are doing ML and do not have a PhD (or previous experience), you are just looking at calling a library function that you do not understand.
I'm assuming that's your interpretation of the industry mindset, and not a view you personally hold.
IMO it's a naive assumption, and it would be trivial to test for it in an interview.
I have an interest in ML for a specific domain, no PhD, and it wouldn't cross my mind to try to use it as a set of shrink-wrapped library functions.
I'm assuming that's your interpretation of the industry mindset, and not a view you personally hold.
IMO it's a naive assumption, and it would be trivial to test for it in an interview.
I have an interest in ML for a specific domain, no PhD, and it wouldn't cross my mind to try to use it as a set of shrink-wrapped library functions.
I can't speak on their behalf, but I can see how this would be interpreted as a negative signal. If someone is really excited about ML stuff, and you aren't going to hire him for your ML team, then I would be afraid that the person will be disappointed that the work we give him/her is less about solving complex problems and more about getting stuff done. There's also the issue that this person is probably going to jump ship the second he gets an offer to work on ML stuff.
As someone having a strong interest in math and theoretical computer science, I think their bias is fair. I think I'm a pretty good programmer, better than most I've met with similar experience, but I'll admit that I don't care as much as people who are really passionate about building stuff. They will write sloppy code sometimes, but they'll also focus on getting stuff shipped, whereas I naturally want to focus on solving interesting issues like that bug which only seems to happen 1/20 unit tests but no customer has reported.
It took me some time to learn how industry differs from university programming, and if I were recruiting, I don't know if I would want to deal with the hassle. Obviously now that I know I accept industry for what it is and make sure I do my best, even when it doesn't align with my own interests necessarily, but that takes some maturity (not that I am particularly mature), and I can see why hiring managers would rather avoid the risk when hiring and firing is very expensive and annoying.
As someone having a strong interest in math and theoretical computer science, I think their bias is fair. I think I'm a pretty good programmer, better than most I've met with similar experience, but I'll admit that I don't care as much as people who are really passionate about building stuff. They will write sloppy code sometimes, but they'll also focus on getting stuff shipped, whereas I naturally want to focus on solving interesting issues like that bug which only seems to happen 1/20 unit tests but no customer has reported.
It took me some time to learn how industry differs from university programming, and if I were recruiting, I don't know if I would want to deal with the hassle. Obviously now that I know I accept industry for what it is and make sure I do my best, even when it doesn't align with my own interests necessarily, but that takes some maturity (not that I am particularly mature), and I can see why hiring managers would rather avoid the risk when hiring and firing is very expensive and annoying.
Because ML/AI are feature enablers. They make a good product better, but they won't make a product successful. It's a signal that people are more interested in solving technical problems than solving business/product problems.
Also, a large percentage of ML/AI projects are scams. And even the people who aren't scammers tend to massively underestimate the amount of work required to make something good. It doesn't surprise me at all that interest in these technologies could be a red flag on multiple levels.
Sure there are plenty of great startups built with these technologies, but both also tend to be the 'and then a miracle occurs' of the tech industry.
Sure there are plenty of great startups built with these technologies, but both also tend to be the 'and then a miracle occurs' of the tech industry.
So Google without good AI would be still as good because of the neat interface? Self driving cars would be just as good without good AI?
I get what you mean, and it might be true for a lot of products. But there are also products were good AI is the core.
I get what you mean, and it might be true for a lot of products. But there are also products were good AI is the core.
Use cases with ML out front are rare. I would argue that "self-driving" is just a feature of an automobile; the expensive part is building and delivering a half-ton hunk of precision-engineered metal. People were buying cars long before they were self-driving; and I doubt that self-driving will add a whole lot to the cost of a vehicle. Even then, the hard part of building a business around autonomous cars is obtaining safety certification and improving public perception of autonomous driving. All the major self-driving algorithms will be largely public domain before that happens.
Likewise with Google; there were search engines long before Google. Hell, Google first appeared as the search technology powering Yahoo! long before they had their own presence. Granted; in this case ML enabled the "killer app" of generating relevant results and allowing ad targeting, but use cases where ML is as critical to the product as Google are rare. More typical are things like Netflix's recommendation engine - the value of the service is in the video library, the recommendation engine is just another avenue for content discovery. It is also being increasingly curated as opposed to automated for promotional reasons.
All of this matters. ML is great, but ML results are often so narrowly scoped that you need to identify your product scope first, then find an ML solution that helps. And even then, at small scale you can often "fake" the impact of ML via manual labor or "doing things that don't scale" (i.e. operating the service via manual labor at a loss with the hopes of adding an AI component to handle that function later in a scalable fashion). If the product doesn't resonate with the market, all the ML in the world won't help it succeed.
Likewise with Google; there were search engines long before Google. Hell, Google first appeared as the search technology powering Yahoo! long before they had their own presence. Granted; in this case ML enabled the "killer app" of generating relevant results and allowing ad targeting, but use cases where ML is as critical to the product as Google are rare. More typical are things like Netflix's recommendation engine - the value of the service is in the video library, the recommendation engine is just another avenue for content discovery. It is also being increasingly curated as opposed to automated for promotional reasons.
All of this matters. ML is great, but ML results are often so narrowly scoped that you need to identify your product scope first, then find an ML solution that helps. And even then, at small scale you can often "fake" the impact of ML via manual labor or "doing things that don't scale" (i.e. operating the service via manual labor at a loss with the hopes of adding an AI component to handle that function later in a scalable fashion). If the product doesn't resonate with the market, all the ML in the world won't help it succeed.
My experience is that programmers I've worked with who strongly identified as being interested in ML tended to be prone to wanting to build very complex ML-based systems when much simpler (albeit less sexy) solutions would suffice. Certainly this is a generalization, but I've seen it enough times to be wary.
I don't identify as an ML person and fight this type of complexity all the time. Start simple and then move complex. Starting complex is simply overkill for so many problems.
A lot of ML work is currently ad hoc. Not what you want in most software design and development. Accomplishment in ML and interest in ML are very different. With the hype these days an interest in ML is almost like an interest in making the computer magic.
I wanted to ask the same question.
Harj, is it people with ML/AI interests without experience? Does this also include PHDs? On that note, are Academic Programmers Comp Sci PHDs or from other fields?
Harj, is it people with ML/AI interests without experience? Does this also include PHDs? On that note, are Academic Programmers Comp Sci PHDs or from other fields?
Author of the post. We did not distinguish by experience level in the question that we asked about tech / product. But experience is VERY helpful in a job search, so an experienced ML/AI person would almost certainly have more interest than a product person fresh out of school. We've not seen much weight given to CS PhDs. Someone fresh out of a CS PhD program is viewed much like someone out of a BS program. Industry experience is a big help.
Hmm, I think you may find different responses based on experience level with something like ML in particular. I'm a product focused engineer (former PM) with a master's degree and an unfinished PhD in machine learning. I've also been a mentor at a 12-week boot camp where students did machine learning projects, so I totally get the "it's sexy but nobody actually bothers to understand it" argument. But with my experience level (several years real world experience and a Big Name) I think I've had more interest due to my specific background, not less.
They think ML people aren't interested in infrastructure. That's not entirely true. Many people with actual production ML experience understand and want to work on the data infrastructure because it's all to easy for someone that's not going to build products on top of it to fuck it up.
In addition to what's been said, I think that ML/AI, especially AI, attract people interested in the Big Question and aren't exactly detail people.
probably because ML is the hot new thing. People that are interested in a hot new method (especially if there "excited to learn!") instead of the results that that method can product (a better product) are prone to running down technical rabbit holes over shipping.
Maybe they are looking for more practical programmers at the moment?
As a "Product Programmer" myself, I find it highly ironic that despite the fact that there is apparently more demand for product-focused developers than technical-focused ones, the interview process for most startups is overwhelmingly technical-focused.
If you're looking for product-focused developers, please consider tuning your interview process to evaluate whether or not candidates can build great products, rather than following the herd and grilling them on obscure algorithms and data-structure problems, which has a rather high chance of weeding out the kinds of product-focused developers that you're looking for in the first place.
If you're looking for product-focused developers, please consider tuning your interview process to evaluate whether or not candidates can build great products, rather than following the herd and grilling them on obscure algorithms and data-structure problems, which has a rather high chance of weeding out the kinds of product-focused developers that you're looking for in the first place.
Maybe you only remember the super technical parts because the product-focused parts were effortless for you.
I've been in interviews where over half the questions were legit non-programming puzzles, and the rest were algorithms. Most interviews are heavy on tool-specific questions. I've had only two interviews where I've been asked to fix a bug in code and in those circumstances I wasn't able to actually run the code. Getting even remotely close to building something would be so supremely memorable that I would have a hard time believing I built an entire thing before I noticed.
I've had 10+ interviews in the last month and it's really a shit process. First of all, I'm terrible at technical interviews. There's just something about being in that "we're watching your every move" environment that makes me freeze. I found myself literally reading the same for loop line over and over again, not even trying to comprehend it, but rather zoning out on it as my brain continued to focus on what I thought the interviewer was thinking. This, of course, gets worse as the seconds tick on and I've said and done nothing. I also perform terribly when I'm given a take-home "test" with a time limit. The pressure to finish on time overwhelms my thought processes. Then you have the asinine binary tree questions for a front-end web dev position or the "tell me what's wrong with this horrible, obfuscated code". If I have to work on code like that, I don't want to work there.
I had multiple interviews where I was either being video recorded (karat.io) or on a skype call with multiple developers "evaluating" me. This is a toxic environment and I knew in the first few mintutes I didn't want to work there.
I have a portfolio full of sites that I've built and I can tell you with confidence that my portfolio didn't matter even a little bit. Not one employer looked at my github account (not that it's impressive, but that says something).
The best way to get a job is through your network. A previous freelance client was hiring and pursued me aggressively. Why would they do that if I'm a shit developer as thought by my various interviewers? The experience of "interviewing" with a company that knows my work and shows a genuine enthusiasm for having me on their team is so night-and-day different from every other interview that the decision was easy. They gave me what I asked for and treat me like a valued employee.
I had multiple interviews where I was either being video recorded (karat.io) or on a skype call with multiple developers "evaluating" me. This is a toxic environment and I knew in the first few mintutes I didn't want to work there.
I have a portfolio full of sites that I've built and I can tell you with confidence that my portfolio didn't matter even a little bit. Not one employer looked at my github account (not that it's impressive, but that says something).
The best way to get a job is through your network. A previous freelance client was hiring and pursued me aggressively. Why would they do that if I'm a shit developer as thought by my various interviewers? The experience of "interviewing" with a company that knows my work and shows a genuine enthusiasm for having me on their team is so night-and-day different from every other interview that the decision was easy. They gave me what I asked for and treat me like a valued employee.
This sounds like exactly my experience as of late with interviews, so it's nice to know I'm not alone; unfortunately, I don't have a "network" and live far away from where any "network" could be set up so I'm a little stuck in the mud.
Well, you ARE in the network right now. On HN :) networking doesn't have to be physical.
The pattern matching issue with Java or C# is interesting, since all these companies generally do want mobile. So I guess the humorous point of advice for that: replace all occurrences of Java on your CV with Android, and C# with WinPhone, and you'll probably bump your chances of getting passed the pattern matching.
Great advice! Mind if I add this to the blog post?
> "Second, companies dislike programmers with enterprise backgrounds. Our data shows that companies are less likely to hire programmers coming from Java or C# backgrounds."
This I totally understand. Enterprise software is systematically horrible in almost every way: terrible UI/UX, insane degrees of over engineering, high footprint, high cost, and usually at least two to three generations behind on every technological trend. Of those traits I can't stress over-engineering enough... it's epidemic everywhere but most of all in "enterprise" where you'll see insane things like simple web application servers that use gigabytes of RAM and XML schemas that lead to ten-page-long messages to do trivial things. (The use of XML at all is usually a smell unless the domain is very HTML-like such as word processing... and even there extending Markdown would be better in every way.)
It doesn't have to be that way. Those facts reflect the management pathologies that exist in large companies and governments where you have a lot of people managing software projects who don't know anything about software... lots of "pointy haired bosses." You also have a lot of dumb requirements in those areas that twist things out of alignment with what users actually want. Startups very often have the luxury of ignoring stupid requirements unless they have to interoperate with legacy stuff.
It's so bad that I've actually heard people advise startups to pass on some enterprise revenue if they can afford it (pass on REVENUE!) if it might lead them down an "enterprisey" path, since doing so would in the end result in a systematically inferior product. If the systematic diseases of enterprise are that extreme (and I think they mostly are), then I understand the desire that some startups might have to also systematically avoid developers with enterprise backgrounds.
That being said and while I do understand, I think this underestimates the versatility of a good developer. A good developer might have gone into an enterprise job because they need the money but they might be otherwise great at what they do. You can find some great developers by offering to rescue them from enterprise hellholes. Sometimes that alone is all they need to inspire a ton of motivation and loyalty. I mean, you just dragged them out of hades. They're gonna love you.
This I totally understand. Enterprise software is systematically horrible in almost every way: terrible UI/UX, insane degrees of over engineering, high footprint, high cost, and usually at least two to three generations behind on every technological trend. Of those traits I can't stress over-engineering enough... it's epidemic everywhere but most of all in "enterprise" where you'll see insane things like simple web application servers that use gigabytes of RAM and XML schemas that lead to ten-page-long messages to do trivial things. (The use of XML at all is usually a smell unless the domain is very HTML-like such as word processing... and even there extending Markdown would be better in every way.)
It doesn't have to be that way. Those facts reflect the management pathologies that exist in large companies and governments where you have a lot of people managing software projects who don't know anything about software... lots of "pointy haired bosses." You also have a lot of dumb requirements in those areas that twist things out of alignment with what users actually want. Startups very often have the luxury of ignoring stupid requirements unless they have to interoperate with legacy stuff.
It's so bad that I've actually heard people advise startups to pass on some enterprise revenue if they can afford it (pass on REVENUE!) if it might lead them down an "enterprisey" path, since doing so would in the end result in a systematically inferior product. If the systematic diseases of enterprise are that extreme (and I think they mostly are), then I understand the desire that some startups might have to also systematically avoid developers with enterprise backgrounds.
That being said and while I do understand, I think this underestimates the versatility of a good developer. A good developer might have gone into an enterprise job because they need the money but they might be otherwise great at what they do. You can find some great developers by offering to rescue them from enterprise hellholes. Sometimes that alone is all they need to inspire a ton of motivation and loyalty. I mean, you just dragged them out of hades. They're gonna love you.
I posted this as a comment on the original post, but will make the point here...
Large organizations are often more dysfunctional than small ones, yes, especially when it comes to building software. But that doesn't mean they aren't filled with very smart people. The fact that enterprise programmers can't get hired at startups is not, in my opinion, a reflection of the dysfunctional nature of software development at large companies, but of a mismatch in expectations about how to communicate your ability to do your job.
As an example: one pattern I’ve seen that consistently holds enterprise programmers back in startup interviews (especially in phone screens and technical screens) is the inability to effectively articulate the projects they’ve worked on. Enterprise programmers have often worked on optimizing one small part of a very large and complex system that no one person may understand completely, and in my experience, they often cannot describe that system clearly or holistically. Startups usually need people who can build a system end-to-end, and when an enterprise programmer doesn’t seem to understand their own projects, it reflects very poorly. I see this pattern way too often.
My suggestion (and obviously this is a gross generalization) is for enterprise programmers who want to work at startups to practice being able to clearly and consisely explain what they worked on and how it fit into the overall product. Startups will care more about this than showing, for example, a deep understanding of how Java's various memory pools work (even if they work in Java).
Large organizations are often more dysfunctional than small ones, yes, especially when it comes to building software. But that doesn't mean they aren't filled with very smart people. The fact that enterprise programmers can't get hired at startups is not, in my opinion, a reflection of the dysfunctional nature of software development at large companies, but of a mismatch in expectations about how to communicate your ability to do your job.
As an example: one pattern I’ve seen that consistently holds enterprise programmers back in startup interviews (especially in phone screens and technical screens) is the inability to effectively articulate the projects they’ve worked on. Enterprise programmers have often worked on optimizing one small part of a very large and complex system that no one person may understand completely, and in my experience, they often cannot describe that system clearly or holistically. Startups usually need people who can build a system end-to-end, and when an enterprise programmer doesn’t seem to understand their own projects, it reflects very poorly. I see this pattern way too often.
My suggestion (and obviously this is a gross generalization) is for enterprise programmers who want to work at startups to practice being able to clearly and consisely explain what they worked on and how it fit into the overall product. Startups will care more about this than showing, for example, a deep understanding of how Java's various memory pools work (even if they work in Java).
There is also a bias against enterprise developers in that most often their work is on proprietary systems, leaving no code artifacts to view on Github, which a lot of companies have started using in their recruiting process.
This has been a huge issue for me- I used to be very active on Github, but the past year or so I've been working either on proprietary systems that are internal to the company I'm at, or working on private projects that I don't want in public repos. So, if you were to look at just my Github profile, you'd see almost no activity. That doesn't mean I'm not constantly working, though!
> usually at least two to three generations behind on every technological trend
It's easy to refactor (or completely rewrite) for whatever the hot new fad is when you're dealing with small codebases (<100k loc) that haven't been around very long and most likely won't continue to be in use for long. That's not productive when you're working on a product that has millions of lines of code and has been in use for years (and most likely will continue to be so).
It has nothing to do with "pointy haired bosses" - believe it or not a lot of us [enterprise developers] care more about actually getting stuff done then bragging to our friends how we're playing with whatever is hip this week.
It's easy to refactor (or completely rewrite) for whatever the hot new fad is when you're dealing with small codebases (<100k loc) that haven't been around very long and most likely won't continue to be in use for long. That's not productive when you're working on a product that has millions of lines of code and has been in use for years (and most likely will continue to be so).
It has nothing to do with "pointy haired bosses" - believe it or not a lot of us [enterprise developers] care more about actually getting stuff done then bragging to our friends how we're playing with whatever is hip this week.
I think that's a valid point but it only explains a small fraction of the ugliness of enterprise software. It explains why it tends to trend a bit behind, but it does not explain why you need 2gb of RAM to run a web application server or why you need ten pages of XML vomit to add a record to a database. Those kinds of things smack of over-engineering (usually via premature generalization and "architecture astronautism") and cargo cultism among other things. When I look at those systems and code bases I always just sit there and ask "what problem does this solve? what problem does this solve? what problem does this solve?"
I also didn't mean to imply that there are no good developers in "enterprise." But I do believe that "enterprise" is to good developers what, say, a corrupt economy is to good entrepreneurs. You can operate there but it's painful and everything about it gets in the way of doing the right thing.
Also also (heh) I didn't mean to imply that all enterprises are "enterprise." That's why I put it in quotes. Some large organizations manage to avoid these pathologies. I've even seen really excellent systems emerge from government labs if the people running them are clueful. "Enterprise" in quotes refers to the pathologies that afflict big over-priced over-engineered slow clunky UX abominations. Everyone's seen them and everyone's been forced to use them... forced because nobody would ever voluntarily do so.
I also didn't mean to imply that there are no good developers in "enterprise." But I do believe that "enterprise" is to good developers what, say, a corrupt economy is to good entrepreneurs. You can operate there but it's painful and everything about it gets in the way of doing the right thing.
Also also (heh) I didn't mean to imply that all enterprises are "enterprise." That's why I put it in quotes. Some large organizations manage to avoid these pathologies. I've even seen really excellent systems emerge from government labs if the people running them are clueful. "Enterprise" in quotes refers to the pathologies that afflict big over-priced over-engineered slow clunky UX abominations. Everyone's seen them and everyone's been forced to use them... forced because nobody would ever voluntarily do so.
> You can operate there but it's painful and everything about it gets in the way of doing the right thing
Yikes, that hit close to home. Where I'm working now is very "enterprise", but when they brought me on they gave me a huge amount of autonomy and it's worked out great for them- I started fresh on new projects and was able to make them lightweight, fast, and pretty.
And then they toss at me a behemoth of an ancient, 10-year-old project with services that connect to services that connect to services (all on the same machine!) and probably uses more than 2GB of RAM for simple CRUD screens. There's no funding and it's too big and "vital" to rewrite, so they're stuck with it (probably for another 30+ years, just like they were stuck with the COBOL system it replaced)
It was around that time I started looking (and am still looking...) for a new job.
Yikes, that hit close to home. Where I'm working now is very "enterprise", but when they brought me on they gave me a huge amount of autonomy and it's worked out great for them- I started fresh on new projects and was able to make them lightweight, fast, and pretty.
And then they toss at me a behemoth of an ancient, 10-year-old project with services that connect to services that connect to services (all on the same machine!) and probably uses more than 2GB of RAM for simple CRUD screens. There's no funding and it's too big and "vital" to rewrite, so they're stuck with it (probably for another 30+ years, just like they were stuck with the COBOL system it replaced)
It was around that time I started looking (and am still looking...) for a new job.
> It's so bad that I've actually heard people advise startups to pass on some enterprise revenue if they can afford it (pass on REVENUE!) if it might lead them down an "enterprisey" path, since doing so would in the end result in a systematically inferior product.
Yes, because it's much better to have an architecturally pure product nobody uses than something generating millions in recurring revenue.
Yes, because it's much better to have an architecturally pure product nobody uses than something generating millions in recurring revenue.
It depends on the situation. It's bad to forego millions in recurring revenue, but it's not bad to forego smaller gains if you have a vibrant business in other areas and if those smaller gains require that you go down a path that will ultimately make your product a loser in the marketplace.
This is why Apple shuns "enterprise." They value user experience. Exposing UX to enterprise development priorities and methodologies is like exposing a kitten to mustard gas. Even a little bit does tremendous harm and it's definitely cruel.
Last I checked Apple was among the most valuable companies in the world. Their stuff is also heavily used in enterprise in spite of their dismissal of it. Sometimes a good product can make inroads into enterprise if it's good enough to overcome certain biases and entrenched pathologies. Some organizations have departments running their own "guerrilla IT" to support things that aren't awful vs. the awful stuff shoved down their throats by corporate IT.
The root problem with enterprise is that products are often built to artificial specifications that someone made up, not to actual specifications learned through real use and feedback or that are shaped by underlying reality. This results in a lot of superfluous complexity that does not reflect the actual complexity of the problem domain. Another major problem is that purchasing tends to be based on feature check boxes instead of actual evaluation of the product by people who will actually be using it. You'd be surprised how often a large org will make a major purchase without even consulting with those who will actually be using the product. I've also seen cases where people go so far as to pretend to use the "boat anchor" product while actually doing things using a different system purchased or built with off-normal-channels funds.
This is why Apple shuns "enterprise." They value user experience. Exposing UX to enterprise development priorities and methodologies is like exposing a kitten to mustard gas. Even a little bit does tremendous harm and it's definitely cruel.
Last I checked Apple was among the most valuable companies in the world. Their stuff is also heavily used in enterprise in spite of their dismissal of it. Sometimes a good product can make inroads into enterprise if it's good enough to overcome certain biases and entrenched pathologies. Some organizations have departments running their own "guerrilla IT" to support things that aren't awful vs. the awful stuff shoved down their throats by corporate IT.
The root problem with enterprise is that products are often built to artificial specifications that someone made up, not to actual specifications learned through real use and feedback or that are shaped by underlying reality. This results in a lot of superfluous complexity that does not reflect the actual complexity of the problem domain. Another major problem is that purchasing tends to be based on feature check boxes instead of actual evaluation of the product by people who will actually be using it. You'd be surprised how often a large org will make a major purchase without even consulting with those who will actually be using the product. I've also seen cases where people go so far as to pretend to use the "boat anchor" product while actually doing things using a different system purchased or built with off-normal-channels funds.
Apple shuns enterprise, huh? http://www.apple.com/business/mobile-enterprise-apps/
I've worked for startups and I've worked for enterprise apps, and at least the enterprise apps I've worked on actually got used by a good number of people. Some of the startup apps I worked on completely failed to find their audience precisely because someone in charge was making it all up as they went along and didn't base anything on what customers actually wanted.
I tried to do the best I could in that situation, and sometimes managed to convince myself that the apps would find their audience, but the artificial specifications can exist equally in both domains.
And the startup arena was the only place where I saw the client/producer completely flip flop on how a feature should be designed multiple times in a single week, based on whatever article they read or dream they had the night before, and then get all pissed why I wasn't already halfway done with their brand new vision they just told me two minutes ago.
It can go both ways. At least the enterprise apps had a mechanism where the users could provide feedback, and had a definite audience and need that needed fulfilled.
I've worked for startups and I've worked for enterprise apps, and at least the enterprise apps I've worked on actually got used by a good number of people. Some of the startup apps I worked on completely failed to find their audience precisely because someone in charge was making it all up as they went along and didn't base anything on what customers actually wanted.
I tried to do the best I could in that situation, and sometimes managed to convince myself that the apps would find their audience, but the artificial specifications can exist equally in both domains.
And the startup arena was the only place where I saw the client/producer completely flip flop on how a feature should be designed multiple times in a single week, based on whatever article they read or dream they had the night before, and then get all pissed why I wasn't already halfway done with their brand new vision they just told me two minutes ago.
It can go both ways. At least the enterprise apps had a mechanism where the users could provide feedback, and had a definite audience and need that needed fulfilled.
> The root problem with enterprise is that products are often built to artificial specifications that someone made up, not to actual specifications learned through real use and feedback or that are shaped by underlying reality.
Sounds familiar. The previous app I worked on was so flexible and customizable via parameters, that in fact half of the bugs we've had were due to crappy configuration management process rather than actual code bugs.
Sounds familiar. The previous app I worked on was so flexible and customizable via parameters, that in fact half of the bugs we've had were due to crappy configuration management process rather than actual code bugs.
Why would this get down-voted? It's spot on. I know it hurts when it hits close to home folks, I know.
The “Product Programmer” and “Technical Programmer” profiles are identical,
except one is motivated by product design, and the other by solving hard
programming problems.
I've struggled with trying to define the difference between the great systems engineers I meet and the engineers who make great products (sometimes at the expense of all elegance under the hood).
This sums it up nicely... it's where the focus is. I'm surrounded by engineers focusing on systems programming, but I don't think of myself as similar to them, I've always been end user obsessed and customer focused. It's nice to see this difference acknowledged.
Hi Ammon/Harj, Thank you for that effort and laying it out. Very helpful.
Just so the readers don't miss the context: By definition, most companies referred here, I'm guessing, are startups. And startups will definitely want more product-focused engineers, in order to keep moving fast.
Interviewing in general, is closer to a date, than it's to a standardized test. The smaller the company is, the more pronounced that characteristic is. For even slightly larger companies, it's a different story.
When I was a Director of Engineering at Box, the engineering team was tasked with hiring 25 engineers in a single quarter. For several quarters. When hiring at that scale, it's hard to hire based on personas and elaborate preferences. At that point, process is more important. Anyone that meets a consistent process gets hired. There are always biases at resume selection, but those are only to benefit the later process, and not so much of a preference.
[About us: http://InterviewKickstart.com]
Just so the readers don't miss the context: By definition, most companies referred here, I'm guessing, are startups. And startups will definitely want more product-focused engineers, in order to keep moving fast.
Interviewing in general, is closer to a date, than it's to a standardized test. The smaller the company is, the more pronounced that characteristic is. For even slightly larger companies, it's a different story.
When I was a Director of Engineering at Box, the engineering team was tasked with hiring 25 engineers in a single quarter. For several quarters. When hiring at that scale, it's hard to hire based on personas and elaborate preferences. At that point, process is more important. Anyone that meets a consistent process gets hired. There are always biases at resume selection, but those are only to benefit the later process, and not so much of a preference.
[About us: http://InterviewKickstart.com]
When I was a Director of Engineering at Box, the engineering team was tasked with hiring 25 engineers in a single quarter. For several quarters. When hiring at that scale, it's hard to hire based on personas and elaborate preferences.
I just watched another startup in the same reference class grow at a similar speed, and I don't believe you. Suppose it takes 20 interview loops to hire one very good engineer, and each loop takes on average 10 engineer-hours. That's 200-engineer-hours per new hire, or about one engineer-month. That means if you have 100 engineers at Box (correct me if I'm way off base here, but 25 on 100 in a quarter sounds like a reasonable fast growth) you can hire 25 new engineers in a quarter while spending only 10% of your total labor recruiting.
The reason this doesn't usually work is because most engineers don't spend 10% of their time helping with recruiting. That is in my opinion an unforced error. They should.
I just watched another startup in the same reference class grow at a similar speed, and I don't believe you. Suppose it takes 20 interview loops to hire one very good engineer, and each loop takes on average 10 engineer-hours. That's 200-engineer-hours per new hire, or about one engineer-month. That means if you have 100 engineers at Box (correct me if I'm way off base here, but 25 on 100 in a quarter sounds like a reasonable fast growth) you can hire 25 new engineers in a quarter while spending only 10% of your total labor recruiting.
The reason this doesn't usually work is because most engineers don't spend 10% of their time helping with recruiting. That is in my opinion an unforced error. They should.
Not sure which part you're referring to, that doesn't work.
Average 10% spend by an engineer towards hiring is quite normal, from my experience. Obviously, it's average, so there are some who spend way more than 10%, and there are some who don't spend any. 4 out of 40 hours a week including phone-screens, on-sites and deliberations is easy to get to.
I'm sure you know, that a lot of hiring at that scale is systematized and (hence) heavy-lifting is done by non-technical recruiting people.
Average 10% spend by an engineer towards hiring is quite normal, from my experience. Obviously, it's average, so there are some who spend way more than 10%, and there are some who don't spend any. 4 out of 40 hours a week including phone-screens, on-sites and deliberations is easy to get to.
I'm sure you know, that a lot of hiring at that scale is systematized and (hence) heavy-lifting is done by non-technical recruiting people.
I'm sure you know, that a lot of hiring at that scale is systematized and (hence) heavy-lifting is done by non-technical recruiting people.
Right, this is what I'm arguing against. Doing filtering with non-technical people requires a lot of systematization and strange, low-quality filters. I suggest not doing that.
The typical response is that you need to do it because engineer time is too precious, which I disagree with.
Right, this is what I'm arguing against. Doing filtering with non-technical people requires a lot of systematization and strange, low-quality filters. I suggest not doing that.
The typical response is that you need to do it because engineer time is too precious, which I disagree with.
This was a great point: "There’s more demand for product-focused programmers than there is for programmers focused on hard technical problems." A very talented programmer from Dropbox once told me that if I wanted to attract top engineering talent, I needed to be able to show the engineer "a problem that no one else has solved yet." This totally changed the way I wrote my job descriptions and conducted interviews. Led to great outcomes, too.
Care to explain a little? Did your friend mean that talented engineers like working on novel problems and companies facing hard problems are thus more attractive?
This is interesting data.
I liked what Joel Spolsky said a long time ago. Basically that companies should want two types of engineers. 1. You want a few who are experts in the company's tech stack. 2. The bar for everyone else is just that they're smart and they get things done.
I guess the core problem is that we don't have a good objective measure of the latter. (Maybe an IQ test for smarts, if that wasn't political incorrect, but I don't know how you'd show definitively that you "get things done" in an interview.)
I liked what Joel Spolsky said a long time ago. Basically that companies should want two types of engineers. 1. You want a few who are experts in the company's tech stack. 2. The bar for everyone else is just that they're smart and they get things done.
I guess the core problem is that we don't have a good objective measure of the latter. (Maybe an IQ test for smarts, if that wasn't political incorrect, but I don't know how you'd show definitively that you "get things done" in an interview.)
IQ tests are not only politically incorrect they are illegal in the US. It is illegal discrimination to make hiring decisions based on IQ scores. You can only use a test that shows those with higher scores perform better at the job. A general IQ test can not be shown to do that. Basically you can not ask questions that test skills that would not be used in the job the candidate is applying for.
You must be able to defend the metric you use for hiring and that it is not discriminatory. If you give an IQ test that is unrelated to the job and say no one below 100 IQ will be hired you must prove that someone with 101 IQ can do the job but someone with 99 IQ can not properly do the job
You must be able to defend the metric you use for hiring and that it is not discriminatory. If you give an IQ test that is unrelated to the job and say no one below 100 IQ will be hired you must prove that someone with 101 IQ can do the job but someone with 99 IQ can not properly do the job
> It is illegal discrimination to make hiring decisions based on IQ scores. You can only use a test that shows those with higher scores perform better at the job.
There is more scientific evidence that IQ predicts job performance than for most of the more qualitative criterions that employers use in practice. The source of the illegality of using IQ tests is not legislative (intelligence is not a protected class[1]). It comes from the precedent of Griggs v. Duke Power Co., in which the IQ test was being used as a barrier for jobs where IQ was not a good predictor (not programming), and prior to thorough research on the subject. There have been hundreds of studies showing that IQ tests predict job performance (though not super strongly) at the beginning of careers, even though this fades once they have more experience. This[3] meta-analysis approaches these studies very critically, and concludes that many inflate the effect, and that it doesn't validate the IQ test (i.e. there may be non-cognitive reasons for it) but that the correlation still exists. (For what it's worth, I suspect they're right about the non-cognitive part since the correlation has become much stronger over time, particularly around the 1970s. However, when your goal is to test for something and not to explain it, correlation is good enough.)
> Basically you can not ask questions that test skills that would not be used in the job the candidate is applying for. ... You must be able to defend the metric you use for hiring and that it is not discriminatory.
No, the burden set in Griggs and later elaborated in a modification to the Civil Rights Act is not to prove that a test is not discriminatory at all. Instead for tests that are discriminatory in practice (though not obviously in design, like IQ), you must show that the test is truly indicative of job performance. If this were not the case, you couldn't ask if people went to college, due to the racial disparity in college graduates. Also you can ask things you can't prove are related to job performance if it isn't discriminatory (not that this is really useful).
> If you give an IQ test that is unrelated to the job and say no one below 100 IQ will be hired you must prove that someone with 101 IQ can do the job but someone with 99 IQ can not properly do the job
Of course you don't have to show that anyone who fails your test will 100% be worse on a case by case basis than someone who passes. If that were the case you couldn't justify pretty much any test other than "applicant is not dead or in a coma." You just need to show that it is clearly less likely. I would find it really surprising if there wasn't some kind of IQ threshold effect for programming (i.e. the closer you are to the middle of the spectrum, the better a predictor of programming performance IQ is). That would make it easy to justify using an IQ test as a predictor, especially in combination with the more general studies.
I don't think IQ would be terribly useful to weed out programmers because I suspect there are more related ways to judge applicants that would already weed out those in the region where IQ is useful, but it is not as simple as "IQ testing for a job is illegal."
[1]: https://en.wikipedia.org/wiki/Protected_class [2]: https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co. [3]: http://www.tandfonline.com/doi/full/10.1080/10888691.2014.98...
There is more scientific evidence that IQ predicts job performance than for most of the more qualitative criterions that employers use in practice. The source of the illegality of using IQ tests is not legislative (intelligence is not a protected class[1]). It comes from the precedent of Griggs v. Duke Power Co., in which the IQ test was being used as a barrier for jobs where IQ was not a good predictor (not programming), and prior to thorough research on the subject. There have been hundreds of studies showing that IQ tests predict job performance (though not super strongly) at the beginning of careers, even though this fades once they have more experience. This[3] meta-analysis approaches these studies very critically, and concludes that many inflate the effect, and that it doesn't validate the IQ test (i.e. there may be non-cognitive reasons for it) but that the correlation still exists. (For what it's worth, I suspect they're right about the non-cognitive part since the correlation has become much stronger over time, particularly around the 1970s. However, when your goal is to test for something and not to explain it, correlation is good enough.)
> Basically you can not ask questions that test skills that would not be used in the job the candidate is applying for. ... You must be able to defend the metric you use for hiring and that it is not discriminatory.
No, the burden set in Griggs and later elaborated in a modification to the Civil Rights Act is not to prove that a test is not discriminatory at all. Instead for tests that are discriminatory in practice (though not obviously in design, like IQ), you must show that the test is truly indicative of job performance. If this were not the case, you couldn't ask if people went to college, due to the racial disparity in college graduates. Also you can ask things you can't prove are related to job performance if it isn't discriminatory (not that this is really useful).
> If you give an IQ test that is unrelated to the job and say no one below 100 IQ will be hired you must prove that someone with 101 IQ can do the job but someone with 99 IQ can not properly do the job
Of course you don't have to show that anyone who fails your test will 100% be worse on a case by case basis than someone who passes. If that were the case you couldn't justify pretty much any test other than "applicant is not dead or in a coma." You just need to show that it is clearly less likely. I would find it really surprising if there wasn't some kind of IQ threshold effect for programming (i.e. the closer you are to the middle of the spectrum, the better a predictor of programming performance IQ is). That would make it easy to justify using an IQ test as a predictor, especially in combination with the more general studies.
I don't think IQ would be terribly useful to weed out programmers because I suspect there are more related ways to judge applicants that would already weed out those in the region where IQ is useful, but it is not as simple as "IQ testing for a job is illegal."
[1]: https://en.wikipedia.org/wiki/Protected_class [2]: https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co. [3]: http://www.tandfonline.com/doi/full/10.1080/10888691.2014.98...
Reading the Wikipedia link on Griggs it seems to have been about requiring a high school diploma for jobs that didn't need that as a way of keeping blacks out. That seems a different matter to wanting to hire intelligent people to programme?
Yes, that's precisely my point. Griggs (and some later ruling and legislation along the same lines) established when an employer can use a test to evaluate applicants that indirectly discriminates against a protected class. From the article:
> The Supreme Court ruled that under Title VII of the Civil Rights Act, if such tests disparately impact ethnic minority groups, businesses must demonstrate that such tests are "reasonably related" to the job for which the test is required.
For programmers (as well as many other jobs), IQ (within a certain range) could be borne out as being reasonably related. GP was claiming that it is illegal to administer IQ tests during interviews in the US, which is not true.
> The Supreme Court ruled that under Title VII of the Civil Rights Act, if such tests disparately impact ethnic minority groups, businesses must demonstrate that such tests are "reasonably related" to the job for which the test is required.
For programmers (as well as many other jobs), IQ (within a certain range) could be borne out as being reasonably related. GP was claiming that it is illegal to administer IQ tests during interviews in the US, which is not true.
>IQ tests are not only politically incorrect they are illegal in the US. It is illegal discrimination to make hiring decisions based on IQ scores.
Oh come now. Every company in the valley emphasizes "cultural fit" and that's about as subtle a dog-whistle as an '88' neck tattoo.
It's pretty obvious that nobody here cares about even the most clear-cut discrimination against protected classes (and it's not at all clear to me that less intelligent people are a protected class.)
Oh come now. Every company in the valley emphasizes "cultural fit" and that's about as subtle a dog-whistle as an '88' neck tattoo.
It's pretty obvious that nobody here cares about even the most clear-cut discrimination against protected classes (and it's not at all clear to me that less intelligent people are a protected class.)
The difference is that "cultural fit" means a different thing at every different company, so it would have to be proven to be discriminatory on a case-by-case basis. That takes too much work, so it doesn't happen very often.
IQ tests are well known to have a disparate impact on some protected classes, so you are treading on extremely thin ice to use one.
IQ tests are well known to have a disparate impact on some protected classes, so you are treading on extremely thin ice to use one.
>IQ tests are well known to have a disparate impact on some protected classes, so you are treading on extremely thin ice to use one.
Really? I mean, I know that the racists have been going on about how some races are dumber than others for as long as the idea of race has existed... but is this an idea that would be taken seriously by the courts?
Really? I mean, I know that the racists have been going on about how some races are dumber than others for as long as the idea of race has existed... but is this an idea that would be taken seriously by the courts?
Absolutely. The concept is known as disparate impact. A test which results in members protected classes being less likely to be selected is not allowed unless you can demonstrate that the test is connected to job performance. There is a famous case from the 70's where the company wasn't even allowed to require a high-school diploma: https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co.
I was expressing doubt at the idea that intelligence correlates with ethnicity.
Intelligence, perhaps not. IQ tests certainly do. And regardless of correlations with ethnicity, IQ tests would correlate with some mental disabilities, and people with those mental disabilities are also members of a protected class.
I accepted an offer at IBM a few months ago and had to take an IQ tests of sorts. It was mostly focused around pattern recognition with some algebra problems thrown in. At best it seemed only tangentially related to programming ability.. I'm not sure that attempting to measure whether a candidate is "smart" or not is a good hiring strategy.
A good analogy for this type of interviewing is like trying to judge how good someone is at basketball by measuring how tall they are. Is it related? Sure. But it certainly doesn't give you the whole picture and might not be a useful information at all. Watching them play a few games would be a better strategy.
Fortunately there a quite a few startups working on this problem. Lytmus is one in particular that I think looks very promising.
A good analogy for this type of interviewing is like trying to judge how good someone is at basketball by measuring how tall they are. Is it related? Sure. But it certainly doesn't give you the whole picture and might not be a useful information at all. Watching them play a few games would be a better strategy.
Fortunately there a quite a few startups working on this problem. Lytmus is one in particular that I think looks very promising.
The best way to show that you get things done is to have a record of things you've done to point to.
This reminds of psychological study about superstition. They studied fishing habits of South American Indian tribes; the tribes that fished in lakes, had consistent and reasonable rules about when/where to go fishing. However, the tribes that fished in the ocean, where you cannot predict the catch, had rather random and superstitious rules about when/where to go. This is due to our brains seeing patterns in randomness.
Also, it's perhaps understandable why companies don't want to reveal their preference. If you do it, you open yourself to being gamed. I think it's also better to have unreasonable requirements (looking to give genius programmers some boring product work) than be sorry. Again this happens in absence of actual test (other than wait and see) of who is a good candidate. Females do the same thing when mating.
Also, it's perhaps understandable why companies don't want to reveal their preference. If you do it, you open yourself to being gamed. I think it's also better to have unreasonable requirements (looking to give genius programmers some boring product work) than be sorry. Again this happens in absence of actual test (other than wait and see) of who is a good candidate. Females do the same thing when mating.
> This reminds of psychological study about superstition. They studied fishing habits of South American Indian tribes; the tribes that fished in lakes, had consistent and reasonable rules about when/where to go fishing. However, the tribes that fished in the ocean, where you cannot predict the catch, had rather random and superstitious rules about when/where to go. This is due to our brains seeing patterns in randomness.
Thats really interesting. Would love to read more about it if you have a source for that off hand.
Thats really interesting. Would love to read more about it if you have a source for that off hand.
It comes from this lecture https://www.youtube.com/watch?v=P_dLJ1FxGuo&list=PLRKa53-za1..., around 10 minute mark.
I had such a disappointing experience with Triplebyte. I take their automated test and everything is hunkydory. After that they gave me a very ambiguous technical interview live-coding session without an interviewer. It seemed like an unreleased feature or a trial a/b test variant. Even now I go back and they've removed every reference to a "programming challenge"!
Anyway, the problem involved writing a tree generation/traversal along with a little equation parser and a lot of string parsing (I think, at least). I was really uncomfortable because while it said "we will run this code" I didn't know what their expectations where (In what environment are they going to run the code? Is underscore ok? They said "you can't use built in eval" so do they really want me to write my own eval? Do they care if I look on stackoverflow for string parsing stuff?). I only had an hour for a difficult problem and I spent most of the time wondering what they really wanted and stressing out about little details that wouldn't consume ten seconds of thought on the job.
I've interviewed a lot and I'm pretty confident from a lot of experience whiteboarding code or typing up an answer on the spot in interviews, so this was very frustrating and I found it to be disrespectful of my time.
Anyway, the problem involved writing a tree generation/traversal along with a little equation parser and a lot of string parsing (I think, at least). I was really uncomfortable because while it said "we will run this code" I didn't know what their expectations where (In what environment are they going to run the code? Is underscore ok? They said "you can't use built in eval" so do they really want me to write my own eval? Do they care if I look on stackoverflow for string parsing stuff?). I only had an hour for a difficult problem and I spent most of the time wondering what they really wanted and stressing out about little details that wouldn't consume ten seconds of thought on the job.
I've interviewed a lot and I'm pretty confident from a lot of experience whiteboarding code or typing up an answer on the spot in interviews, so this was very frustrating and I found it to be disrespectful of my time.
> He solved hard algorithm problems like they were nothing
That's mostly practice. When I did webdev I was really shitty at algorithms because there were no algorithms in my daily work. When I did some Baduk AI programming I started being much better at algorithms since I was implementing some custom algorithms myself.
If you are interviewing someone for a web dev position, it's kind of ridiculous to screen people by their ability of merging sorted arrays or whatnot.
That's mostly practice. When I did webdev I was really shitty at algorithms because there were no algorithms in my daily work. When I did some Baduk AI programming I started being much better at algorithms since I was implementing some custom algorithms myself.
If you are interviewing someone for a web dev position, it's kind of ridiculous to screen people by their ability of merging sorted arrays or whatnot.
You highlight a very important point. Doing well on algorithms in interviews only needs some dedicated practice. It is NOT a signal for higher intellect as many people misunderstand it to be.
Well, consider that there are well documented academic studies (that I can't be bothered to look up right now) showing that most hiring processes are no better than throwing darts at a board with regards to retention rate, employee success, and every other measure of success of the HR process. The only thing that is remotely effective are IQ scores, and even then it's only a weak correlation.
So regardless of what the companies want, it's near impossible to accurately judge someone in an interview process. Even if you know what you want, it's very difficult to assess how someone is going to perform in a job through an interview process. The main benefit of interviews IMO is to help managers "buy-in" on hiring decisions.
So regardless of what the companies want, it's near impossible to accurately judge someone in an interview process. Even if you know what you want, it's very difficult to assess how someone is going to perform in a job through an interview process. The main benefit of interviews IMO is to help managers "buy-in" on hiring decisions.
Not true.
Actually work sample tests have a .29 correlation to on the job performance, followed closely by structured interview questions.
See: http://www.wired.com/2015/04/hire-like-google/
Actually work sample tests have a .29 correlation to on the job performance, followed closely by structured interview questions.
See: http://www.wired.com/2015/04/hire-like-google/
The work I'm referencing specifically called out Google as an example of an overly-complex practice that didn't result in objectively higher quality candidates. Google's overall quality of engineering talent is high because they are quick to push people out the door if they don't meet the high standards. Regardless, it's very difficult to scale Google's hiring practices, and it's overall seen as a growth limiter for them (even by people internally - it can take 3-6 months to hire one candidate).
According to the psychometrics books I have read structured interviews are as good as IQ-tests when it comes to predicting job-performance.
All types of hiring tests/interviews had some predictive power (except handwriting analysis).
All types of hiring tests/interviews had some predictive power (except handwriting analysis).
What is the point of interviewing through TripleByte and going through their interview process, if I just have to interview with the YC company again? It's something I would completely avoid. I already know that almost 100% of the companies I send my resume to will respond, so what is the point of adding another set of interviews, which as the article points out, only adds a random level of success.
Several reasons:
1) people who go through us skip the screening steps and go straight to a on-site interview at the YC companies.
2) We've sent a bunch of people to most of these companies, and have a good idea what they are looking for. We help you avoid failing interviews for the reasons mentioned in this article.
3) Perhaps you have no trouble getting responses to your resume, but a lot of (strong) programmers do. We help them.
4) We help candidates negotiate offers.
I went through the initial TripleByte process earlier this year but was rejected. I passed the initial multiple choice programming test, but I failed miserably at the 1 hour programming exercise. I actually found the problem to be one of the more difficult algorithm type problems I've encountered in an interview situation. I am curious if the problems chosen by Triplebyte are representative of the typical types of questions for YC company interviews? I can't imagine they all have identical pre-screening processes, so how do you choose representative problems?
I think there is probably value for inexperienced programmers, or people that don't know how to properly write their resume, but for experience programmers, it seems like an unnecessary extra step. Going through a bunch of interview questions from TripleByte just to skip a 45 minute phone screen is absolutely unnecessary and not worth it, especially since you will have to go through the entire onsite anyway.
As I mentioned, I had about a dozen interviews, with both YC and non-YC companies, and had no trouble getting contacted directly by any company.
As I mentioned, I had about a dozen interviews, with both YC and non-YC companies, and had no trouble getting contacted directly by any company.
I would love to see this kind of analysis (i.e. Junior Programmer vs. Child Prodigy vs. Rusty + Experienced) as it applies to hiring women. Are there biases against women with different experience and different "culture fit?" Would be a neat way to apply your data and your company contacts.
We will be doing this analysis
Former C# programmer here, in my most recent job hunt I rewrote my resume. I talked more about the value I provided for my company/customer (what the code did) rather than how I wrote the code. I'd say my results improved significantly in terms of getting my foot in the door.
I do mainly C# at my current job, so it's pretty prominent on my resume; perhaps I'll try a rewrite and focus more on what I've done rather than how I did it. Sounds like a good idea.
When I look to hire a lawyer, I'm going to evaluate potential candidates by asking them to write statutes from memory in full on a whiteboard under time pressure, because I really want to see how well they think on their feet.
As a forward thinking technology executive, I am certain this strategy is correct, because Google does it.
As a forward thinking technology executive, I am certain this strategy is correct, because Google does it.
If you are going to hire a lawyer, you should be more interested in their knowledge of case law rather than how well they memorize statutes.
We understand that our hiring process produces a lot of false negatives, and given that our applicant pool is already generally of high quality, we are able to fool ourselves into thinking that it has been a key to our ongoing success.
Perhaps more importantly, we're not going to change it because this is how Google does it.
Perhaps more importantly, we're not going to change it because this is how Google does it.
I like the ontology of programmers. Are there any other efforts to do this? Anything data driven or externally validated?
Given what a big role personas and demo/psycho-graphics play in marketing, I'm surprised that I haven't heard more about then in the context of hiring and managing.
Given what a big role personas and demo/psycho-graphics play in marketing, I'm surprised that I haven't heard more about then in the context of hiring and managing.
Yeah (author of the blog post here), I think it's a powerful idea. I don't know of any other public attempts to do this (most ideas about hiring stay locked up inside companies). I'd love to hear any ideas you have. Email me at [email protected]
You might not be able to share it, but I'd love to see a covariance analysis on that matrix. You have this hypothesis that companies hire based on some sort of culture. Is that culture random or are there types of culture? Product-focused v tech-focused. test-driven v code-review-drived. If so, the companies hiring practices should cluster.
This would be very useful for triplebyte to know. It would tell you very quickly who this or that company would like, without just throwing a bunch of candidates at them and seeing what sticks.
This would be very useful for triplebyte to know. It would tell you very quickly who this or that company would like, without just throwing a bunch of candidates at them and seeing what sticks.
Out of curiosity, on the taxonomy of programmers, is that supposed to be mostly exclusive, or can they overlap?
Not the author, but I know about ontologies generally. Non-overlapping is great, but rarely possible because whatever you're trying to organize might not divide up that way. Next best is eigenvectors. You would find the "pure types" of programer such that each real programer would a linear composition of the pure types. This is really handy for doing statistics. But you might run in to trouble if programmers don't have interaction free types. Beyond that you can use more elaborate interaction models, but those are more of an art then a science. They require a lot of domain expertise to design.
Hope that helps.
Hope that helps.
Bit of a nitpick, really, but you want a basis, not necessarily just a set of eigenvectors.
I apologize for being completely off-topic, but I find it completely ridiculous that we have to scroll past half the page to see the next highest-level comment.
Are there any plans for implementing collapsible comment threads?
Are there any plans for implementing collapsible comment threads?
FYI HackerWeb has collapsible threads:
https://cheeaun.github.io/hackerweb/#/item/10698009
It's designed for mobile web, but just zoom in and it should be fine
https://cheeaun.github.io/hackerweb/#/item/10698009
It's designed for mobile web, but just zoom in and it should be fine
I wrote a bookmarklet for this a year ago and have since been using it every day: http://www.sagargv.com/proj/flathn/
If you search, there are lots of good plugins and bookmarklets to do the job. Yeah, it would be nice to have it built-in, but people have been asking for it for years - I don't think it's likely to happen soon.
EDIT: Apparently posting really long strings without spaces breaks HN's layout now. Hunh.
Here's my bookmarklet for that:
EDIT: Apparently posting really long strings without spaces breaks HN's layout now. Hunh.
Here's my bookmarklet for that:
javascript:(function()%7Bfunction%20getScript(url,success)%7Bvar%20script=document.createElement('script');script.src=url;var%20head=document.getElementsByTagName('head')%5B0%5D,done=false;script.onload=script.onreadystatechange=function()%7Bif(!done&&(!this.readyState%7C%7Cthis.readyState=='loaded'%7C%7Cthis.readyState=='complete'))%7Bdone=true;success();script.onload=script.onreadystatechange=null;head.removeChild(script)%7D%7D;head.appendChild(script)%7DgetScript('//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js',function()%7Bif(typeof%20jQuery!=='undefined')%7Bif(!$('body').hasClass('collapsible-comments'))%7B$('body').addClass('collapsible-comments');var%20span_html='%3Cspan%20style=%5C'cursor:pointer;margin-right:10px;%5C'%20class=%5C'expand-handle%5C'%3E%5B-%5D%3C/span%3E';if(window.location.href.indexOf('item?id=')!=-1)%7B$('center%20%3E%20table%20%3E%20tbody%20%3E%20tr:eq(2)%20%3E%20td%20%3E%20table:eq(1)%20span.comhead').prepend(span_html)%7Delse%20if(window.location.href.indexOf('threads?id=')!=-1)%7B$('center%20%3E%20table%20%3E%20tbody%20%3E%20tr%20%3E%20td%20%3E%20table%20span.comhead').prepend(span_html)%7D$('.expand-handle').live('click',function()%7Bcurrent_level_width=parseInt($(this).closest('tr').find('td:eq(0)%20%3E%20img').attr('width'),10);$(this).closest('table').closest('tr').nextAll().each(function(index,el)%7Bvar%20elWidth=parseInt($('tbody%20%3E%20tr%20%3E%20td%20%3E%20img',this).attr('width'),10);if(elWidth%3Ecurrent_level_width)%7Bif(elWidth%3C=inner_level_width)%7Binner_level_width=1000;$(this).hide()%7Dif(inner_level_width==1000&&$('.comment',this).css('display')=='none')%7Binner_level_width=elWidth%7D%7Delse%7Breturn%20false%7D%7D);inner_level_width=1000;$(this).text('%5B+%5D').addClass('expand-handle-collapsed').removeClass('expand-handle');$(this).closest('div').nextAll().hide();$(this).closest('div').parent().prev().hide();$(this).closest('div').css(%7B'margin-left':'18px','margin-bottom':'5px'%7D)%7D);$('.expand-handle-collapsed').live('click',function()%7Bcurrent_level_width=parseInt($(this).closest('tr').find('td%20%3E%20img').attr('width'),10);$(this).closest('table').closest('tr').nextAll().each(function(index,el)%7Bvar%20elWidth=parseInt($('tbody%20%3E%20tr%20%3E%20td%20%3E%20img',this).attr('width'),10);if(elWidth%3Ecurrent_level_width)%7Bif(elWidth%3C=inner_level_width)%7Binner_level_width=1000;$(this).show()%7Dif(inner_level_width==1000&&$('.comment',this).css('display')=='none')%7Binner_level_width=elWidth%7D%7Delse%7Breturn%20false%7D%7D);inner_level_width=1000;$(this).text('%5B-%5D').addClass('expand-handle').removeClass('expand-handle-collapsed');$(this).closest('div').nextAll().show();$(this).closest('div').parent().prev().show();$(this).closest('div').css(%7B'margin-left':'0','margin-bottom':'-10px'%7D)%7D)%7D%7D%7D);var%20current_level_width=0;var%20inner_level_width=1000%7D)();For a blog article under a data subdomain, there's surprisingly few numbers and quantitative analysis, which is disappointing. And one matrix of survey data as the only visualization.
I get that startups do not want to reveal their competitive advantage, but there has to be some give-and-take. Taking an analysis on blind faith alone is frustrating.
I get that startups do not want to reveal their competitive advantage, but there has to be some give-and-take. Taking an analysis on blind faith alone is frustrating.
I found the detail level close to perfect. It explains a lot of my feelings towards the recruitment process.
That's confirmation bias, which is dangerous especially since a lot of people in this thread seem to have similar sentiment.
Quantitive data would confirm if the patterns are stereotypes or not.
Quantitive data would confirm if the patterns are stereotypes or not.
Well you could also read it as a rare look into what goes on on the other side of the table, couldn't you?
It is not what you know, but how you tell the story :) Human condition never changes, we are just emotional creatures and perception is reality. It is true in recruitment process, all these new fixes to recruiting are a different versions of that.
>>Ruby or Javascript. (The C# pass rate is actually much lower than the Java pass rate, but the C# numbers are not yet significant by themselves.)<<
This makes me sad. I do not know who the caricature here is, the Enterprise programmer or the YC companies.
YC Companies most likely. I've been doing C# for 3 years, none of which was in an "enterprise" company. Both were/are small software companies in a SaaS environment on the cloud (AWS/Azure).
I would laugh if a company rejected my proven ability to build giant distributed systems in the cloud because they were built in C#.
I would laugh if a company rejected my proven ability to build giant distributed systems in the cloud because they were built in C#.
Keep all these spurious rejections and arbitrary hiring processes in mind next time pg or BigTech's lobbyists bemoan the desperate shortage of great programmers.
I think the recruiting problem in technology in general is that programmers don't meet and interact with enough different types of programmers in work settings, so they really don't know what they want or what they should be looking for.
I'd suggest everyone start doing this instead:
For anyone who meets basic criteria / filters, hire them at least part time, and put them to work. If they don't make the cut 3 months later (based on some objective criteria) let them go. Then after you've done all your recruiting like this maybe 1-2 years later evaluate what your team consists of.
It's not even a question in my mind. I'm not 99% sure. I'm 100% confident the team will not look like the recruiting team originally envisioned it would look before they started hiring.
EDIT: And I'm 100% confident those teams will consist of an overall better quality of engineer, and putting out higher quality products, than they would've ended up with if they stuck with trying to find what they believe to be the right "culture fit" or some concept of what a "prototypical engineer" is / should be.
I'd suggest everyone start doing this instead:
For anyone who meets basic criteria / filters, hire them at least part time, and put them to work. If they don't make the cut 3 months later (based on some objective criteria) let them go. Then after you've done all your recruiting like this maybe 1-2 years later evaluate what your team consists of.
It's not even a question in my mind. I'm not 99% sure. I'm 100% confident the team will not look like the recruiting team originally envisioned it would look before they started hiring.
EDIT: And I'm 100% confident those teams will consist of an overall better quality of engineer, and putting out higher quality products, than they would've ended up with if they stuck with trying to find what they believe to be the right "culture fit" or some concept of what a "prototypical engineer" is / should be.
The discussion about interviews comes down to a fact that if you setup your interview as a test where you position yourself as a chooser you will attract people who need you more than you need them. The best people are going to pass as they have enough options elsewhere.
For example I would be very happy to interview for Google 2 years ago and endure the process. Today I could sit with them for an hour and talk about stuff while sipping coffee. I have more opportunities than I can pursue anyway so spending hours solving mazes like some kind of a lab rat is not something I am going to spend my time on.
I am not a top expert in what I do but I can write and ship code. People like me (and especially ones better than me) will just not show up for your "process". Either you pursue them or you won't meet them. You will only get people for whom you are so attractive an option that they are willing to donate several hours or a whole day to have a low % shot. Those will not be the best programmers as the idea of paying to get evaluated is not something people with options entertain.
For example I would be very happy to interview for Google 2 years ago and endure the process. Today I could sit with them for an hour and talk about stuff while sipping coffee. I have more opportunities than I can pursue anyway so spending hours solving mazes like some kind of a lab rat is not something I am going to spend my time on.
I am not a top expert in what I do but I can write and ship code. People like me (and especially ones better than me) will just not show up for your "process". Either you pursue them or you won't meet them. You will only get people for whom you are so attractive an option that they are willing to donate several hours or a whole day to have a low % shot. Those will not be the best programmers as the idea of paying to get evaluated is not something people with options entertain.
> The company told us they valued process more than raw ability, and he’d not written tests during the interview.
Who the hell writes tests during an interview?
Who the hell writes tests during an interview?
Or why not ask him, "Would you mind writing a few tests as well?"
Uh, yeah. That company sucks.
[edit: well, their interviewing process sucks.]
[edit: well, their interviewing process sucks.]
people who want jobs at test driven development shops.
I'd really like to know what it is about a resume or in an interview that makes someone seem like more of a 'product programmer'.
Is it the particular things they have worked on at other jobs, i.e. their experience, or is it the way they talk about what they want to build?
I'd be really interested to hear how I can make myself sound like more of a product programmer.
Is it the particular things they have worked on at other jobs, i.e. their experience, or is it the way they talk about what they want to build?
I'd be really interested to hear how I can make myself sound like more of a product programmer.
Use white space and minimal typeface variation in all your written materials.
Describe past work in terms of what was made, not tech used to make it. Relegate tech buzzwards to a minimal "skills" section of your resume.
Use the words "make," "things," and "world" liberally. Say you got into programming to make the things that you wanted to see in the world.
Have examples of things, especially small things, that a non-technical person could use or see.
Have a BFA in some quasi-technological process like stone lithography or ceramics. Describe approaching software with a similar sense of craft.
Describe past work in terms of what was made, not tech used to make it. Relegate tech buzzwards to a minimal "skills" section of your resume.
Use the words "make," "things," and "world" liberally. Say you got into programming to make the things that you wanted to see in the world.
Have examples of things, especially small things, that a non-technical person could use or see.
Have a BFA in some quasi-technological process like stone lithography or ceramics. Describe approaching software with a similar sense of craft.
Don't forget to make sure your minimal skills section includes at least one language or framework that requires a Mac to use.
Talk more about the product you built (What worked, what customers said, how was it improved overtime, what did you learn from customers using the product and talking to them), rather than going in detail about the technical requirements of the product (Used technology, improved loading time by n%, rewrote using a different framework).
And the reason why it's important is because startups fail because of bad value propositions, not lack of technical expertise.
And the reason why it's important is because startups fail because of bad value propositions, not lack of technical expertise.
As someone who describes themselves as such and has had good success - demonstrate that you care more deeply about the success of the product than "technology" itself. Code is a tool to solve those problems - focus on what has worked and not worked in coding, rather than what is cool and exciting. Its more of a mindset thing than anything - spend enough time actually being interested in business problems rather than CS problems.
If you want a product focused career path, start getting "product" in your job titles. Every employer knows I'm a product engineer because "Product Engineer" is on my resume.
Like others have said, the rest is mostly about the way you talk about what drives you. Solving hard problems is nice, but demonstrating that you can think well about building something people want is what you should aim for.
Like others have said, the rest is mostly about the way you talk about what drives you. Solving hard problems is nice, but demonstrating that you can think well about building something people want is what you should aim for.
[deleted]
This is oddly reassuring. Imposter syndrome is practically guaranteed when there is a 99% chance that you only got (or could only get) a good job by a failure of the interview process, since so many companies proclaim to only hire the top 1%.
Goes to show that there is a far-greater-than-1% chance that you're legitimately in somebody's top 1%.
Goes to show that there is a far-greater-than-1% chance that you're legitimately in somebody's top 1%.
When it comes to hiring, I think that the team is more important than the individual. As the beginning of the piece stated, it's not so much about individual characteristics as it is culture/process fit. I think the main takeaway for applicants is not to take interview rejection personally. Even if you do everything "right", you still might not be what they're looking for.
Ultimately, I don't think that individual programming ability matters that much. It's extremely rare for the technical talents of one person to turn a company around. Some people can inspire others and turn dysfunctional groups into great teams, and there's never enough of that. But said great teams are ephemeral, like sports dynasties. All a company can do is try to avoid toxic employees and hope that the magic happens.
Ultimately, I don't think that individual programming ability matters that much. It's extremely rare for the technical talents of one person to turn a company around. Some people can inspire others and turn dysfunctional groups into great teams, and there's never enough of that. But said great teams are ephemeral, like sports dynasties. All a company can do is try to avoid toxic employees and hope that the magic happens.
I totally agree with you. A good, recently published book, to read on this topic is 'Team Genius'.
"I remember the first time I interviewed for a front-end programming position and got asked how to do something in JavaScript on a white board. The specifics are vague, but it’s crystal clear how stupid it made me feel and how little it had to do with the actual job."
...
> "The only reliable gauge I’ve found for future programmer success is looking at real code they’ve written, talking through bigger picture issues, and, if all that is swell, trying them out for size."
https://signalvnoise.com/posts/3071-why-we-dont-hire-program...
...
> "The only reliable gauge I’ve found for future programmer success is looking at real code they’ve written, talking through bigger picture issues, and, if all that is swell, trying them out for size."
https://signalvnoise.com/posts/3071-why-we-dont-hire-program...
So someone programming in Java at IBM or Oracle with a mostly academic experience would be all but completely unhireable by YC companies.
Incidentally, it was precisely that kind of programmers who built Watson at IBM, possibly the most impressive software of the past decade, which is not only both academically and technically challenging, but also brilliantly packaged and marketed and probably very lucrative to boot.
The exact same is true of the Graal team at Oracle, who have made what is probably the biggest breakthrough in compiler technology in the last decade, and might well power many important technologies in the near future (Ruby, server-side JS, R) as well as commercial Oracle products.
Incidentally, it was precisely that kind of programmers who built Watson at IBM, possibly the most impressive software of the past decade, which is not only both academically and technically challenging, but also brilliantly packaged and marketed and probably very lucrative to boot.
The exact same is true of the Graal team at Oracle, who have made what is probably the biggest breakthrough in compiler technology in the last decade, and might well power many important technologies in the near future (Ruby, server-side JS, R) as well as commercial Oracle products.
So, random.
Also the company interviewing the first candidate, couldn't they just told him that they wanted testing?
Also the company interviewing the first candidate, couldn't they just told him that they wanted testing?
Indeed, it's an issue when interviewers believe that the best candidates will feel a compulsion to test their code without being prompted. I worked at a company that was big into TDD without ever having done it before, it was no problem and I wrote lots of tests, and so did everyone else on my team who didn't have a TDD background before.
On the job people will tell you if they expect tests, so why interview people in a different situation?
On the job people will tell you if they expect tests, so why interview people in a different situation?
I couldn't help noticing that "Strong Junior Programmer" stands out from the rest. It as a category suffers from juxtaposition with "Child Prodigy Programmer". The "Strong" prefix sounds like a meaningless qualifier that only serves to blunt the label of "Junior". I have to guess that the reason companies select out of this category is that the candidates are perhaps not qualified.
Either they want the candidate to be physically strong, or more likely, they're really looking for some other qualities which they can't easily summarize.
I really liked how this analysis was done. Though i dont work in recruitment i have to work with CEOs often and notice similar approaches to hiring for other job roles as well. Way too similar in fact. I'd love to meet a recruitment company that is taking the same approach as TripleByte or perhaps TripleByte will aim to address other fields at some point. Either way its exciting.
Some companies reject people based on green card status, because they don't have the resources to sponsor them. Some companies have specific salary ranges, too. Are those factors considered during your analysis? You seem to be focusing primarily on what companies want, but sometimes what they want and what they can accept are two different things. Thoughts?
We asked about visa sponsorship. We did not ask about salary. The general pattern with visa sponsorship was that small companies don't want do it, out of concern about the success rate (only 30% of H1B applications last year won the lottery). Some large companies will sponsor visas, but they set a higher bar (they have to be really excited to take on the extra work). The exception is larger companies with teams outside of the US (several YC companies have offices in Canada) to take advantage of different immigration restrictions.
Doesn't this imply that a branch development office, in a country with friendlier immigration policies, should be a high priority for almost every US-based startup?
I assume most startups want to grow their engineering headcount (there are exceptions, of course). The pickier/more-focused you are about what kinds of engineers you want to hire, the more you have to gain from casting a wider net geographically.
But if you find the perfect teammate and she can't come to your main country due to visa restrictions, or maybe even won't come because the immigration story isn't worth the trouble, then what are your options?
I'm not talking about money here, though of course that will be a factor for some people. It just strikes me that the "YC companies with offices in Canada" have a serious recruiting advantage over those without, once they need to seriously grow their teams.
I assume most startups want to grow their engineering headcount (there are exceptions, of course). The pickier/more-focused you are about what kinds of engineers you want to hire, the more you have to gain from casting a wider net geographically.
But if you find the perfect teammate and she can't come to your main country due to visa restrictions, or maybe even won't come because the immigration story isn't worth the trouble, then what are your options?
I'm not talking about money here, though of course that will be a factor for some people. It just strikes me that the "YC companies with offices in Canada" have a serious recruiting advantage over those without, once they need to seriously grow their teams.
Not really, until you have scale. It costs a lot of time/effort/money to maintain multiple offices. There is lots of waste as communications break down. You end up spending on flights/hotels just to get people on the same page. This is not to say it cannot be done, just that it takes more directed effort, which not all employees have or care for.
At larger scale, it makes a LOT of sense and is done regularly.
Some times, it can be a hiring DISadvantage, as candidates run away from jobs where they need to wake up in the early hours for a conference call and also need to jump on conference calls at 11pm.
I do this currently, we have a dev team in the Ukraine. It is worth it price-wise, but the cost not accounted for is my personal time, i'm often on conference calls during kids' bedtime story telling.
At larger scale, it makes a LOT of sense and is done regularly.
Some times, it can be a hiring DISadvantage, as candidates run away from jobs where they need to wake up in the early hours for a conference call and also need to jump on conference calls at 11pm.
I do this currently, we have a dev team in the Ukraine. It is worth it price-wise, but the cost not accounted for is my personal time, i'm often on conference calls during kids' bedtime story telling.
"The types of programmers that each company looks for often have little to do with what the company needs or does. Rather, they reflect company culture and the backgrounds of the founders. "
THIS. In other words, the good ol' boy system still exists, only under the moniker of "meritocracy."
THIS. In other words, the good ol' boy system still exists, only under the moniker of "meritocracy."
This article might help explain that: https://news.ycombinator.com/item?id=10659600
Employees these days have a paradoxical role to fill. On one hand, the value in an employee is the ability to solve a problem. On the other hand, they have to market themselves as passionate people. The only way to do so is to exclaim interest in interesting subjects which often are directly tied to company concerns.
Say a company needs good testers. I would find it very hard to sell myself as a passionate tester. Instead I would say something that's actually interesting to me like AI or machine learning.
In order for something to be interesting, it has to be somewhat unknown. How can you be interested in something you have completely mastered and know everything about. It just becomes process for you.
Say a company needs good testers. I would find it very hard to sell myself as a passionate tester. Instead I would say something that's actually interesting to me like AI or machine learning.
In order for something to be interesting, it has to be somewhat unknown. How can you be interested in something you have completely mastered and know everything about. It just becomes process for you.
[deleted]
This data needs to be related to the size and stage of the company. That YCombinator companies want UI people with application development experience reflects the YCombinator startup approach - it's all about the cool demo.
The requirements may be different in the later-stage companies. But most of the startups never get there. So looking at recruiting goals on a per-company basis from a VC pool will generate a bias towards the skills needed for the cool demo. What Lugg needs are people such as the article suggests. What Uber needs at its current scale is quite different. Uber will hire far more people than Lugg, but it's weighted the same in this model.
The requirements may be different in the later-stage companies. But most of the startups never get there. So looking at recruiting goals on a per-company basis from a VC pool will generate a bias towards the skills needed for the cool demo. What Lugg needs are people such as the article suggests. What Uber needs at its current scale is quite different. Uber will hire far more people than Lugg, but it's weighted the same in this model.
[deleted]
There is a subtle danger in only selecting candidate (people) whom think, act of look like you... the venture may end, not for a lack of talent or capability, but for a lack of ideas or questioning the normative, cultural convention.
Hire tortoises, hedgehogs and hares, introvert and extroverts, peacemakers and activists ... so long as there is respect, civility and productivity, because it's the "pulling" away from the center of gravity and institutional momentum that leads to exploring other great opportunities of venture successes that weren't originally founders' core product.
Hire tortoises, hedgehogs and hares, introvert and extroverts, peacemakers and activists ... so long as there is respect, civility and productivity, because it's the "pulling" away from the center of gravity and institutional momentum that leads to exploring other great opportunities of venture successes that weren't originally founders' core product.
I am growing less and less negative about recruiters. They can be a bit pushy, but I think that recruiters can learn how to modulate and not exaggerate. If a company wants good candidates, it will have to go to them, because the good candidates will not come to them. Good candidates are usually already too busy to bother. That leaves the company no other choice than to appoint a recruiter and try to take the initiative in contacting the good candidates anyway.
Enterprise programmer bias? Could be higher salary expectations?
So companies want people that can build and ship products, and hire for them based on their ability to solve tricky CS problems on a whiteboard?
Something seems amiss here.
Something seems amiss here.
[deleted]
Well if people really want product-motivated engineers, I'm going into the video games field. Also becoming a game designer.
I guess the ideal place for the technically motivated is in large companies like Google/Microsoft or in open source. Should we get a masters and find something more suited to our interests? I'm not sure what the answer actually is.
I guess the ideal place for the technically motivated is in large companies like Google/Microsoft or in open source. Should we get a masters and find something more suited to our interests? I'm not sure what the answer actually is.
Are you analyzing performance / satisfaction after getting hired? Would be interesting to see distribution across types.
I guess the reason that product programmers are most desirable is that most founders are product programmers themselves.
There is a good reason why startups prefer Product Programmers:
If you focus on product, then you have strong feedback loop in your design and development cycle: you regularly see how users interact with your product and improve.
If your focus is on technology, then there is almost no real feedback and you are likely to optimize something not very valuable.
If you focus on product, then you have strong feedback loop in your design and development cycle: you regularly see how users interact with your product and improve.
If your focus is on technology, then there is almost no real feedback and you are likely to optimize something not very valuable.
"interest in ML as a negative signal"
Why, though? Is it because a candidate would be too interested in other things than focusing on mundane web development? Passionate about programming doesn't square well with passionate about ML, because the latter is not so much about programming?
Why, though? Is it because a candidate would be too interested in other things than focusing on mundane web development? Passionate about programming doesn't square well with passionate about ML, because the latter is not so much about programming?
> "Reading bios of founders and applying to companies where the CTO shares your background is probably an effective job-search strategy"
My takeaway is basically that in an organization of sufficient size founders should have little or nothing to do with technical hiring.
My takeaway is basically that in an organization of sufficient size founders should have little or nothing to do with technical hiring.
> We do our interviews without looking at resumes (in order to find great people who look bad on paper)
They don't ask for a resume, but the first thing that comes up in the interview is "where have you worked in the past, and what did you do there?"
They don't ask for a resume, but the first thing that comes up in the interview is "where have you worked in the past, and what did you do there?"
So, we ask at the beginning to talk about a programming project that you've done it in past, but not about where you've worked. We don't ask for a work history until the end (by which point the notes and scoring that go into the final decision are over). We ask at the end so that we have the data to write posts like this.
Perhaps you've changed your policy? I'm pretty sure that's how my first interview started off. When I asked how that fit in with the advertising of "get a job based on something other than your resume", the response was "well, companies do care about which other companies you've worked at".
After the second interview, I was given to Harj and he asked me about work history again...
(Also, since I applied through the project track, I don't think there was much in the way of "tell us about a project you've done in the past".)
After the second interview, I was given to Harj and he asked me about work history again...
(Also, since I applied through the project track, I don't think there was much in the way of "tell us about a project you've done in the past".)
It feels like this article contains a huge amount of bias. To sum it up in a sentence... of course 'founders' all want 'product programmers'!
Ask only tenured, hands-on CTOs, and I bet that table would come out much different.
Ask only tenured, hands-on CTOs, and I bet that table would come out much different.
I am very interested in which of these companies are the outliers. What is the one company in the table that expressed a dislike for product-focused programmers? Which are the few that like academic programmers?
I can't give company names, but we've not seen much of a pattern. It really seems to have to do with the backgrounds of the founders, and who the early successful hires were. This sets an engineering culture going forward.
It's what your data "show." Not what your data "shows." I am always skeptical of the analytical competence of someone who uses incorrect language to describe their own work.
"Is `data` a singular or plural entity?" is a question you should ask yourself.
In this case their data is a collection or mass of data - and is singular. In the blog, using "the data shows that" is the proper way to write the statement.
In this case their data is a collection or mass of data - and is singular. In the blog, using "the data shows that" is the proper way to write the statement.
This may be a British/American English gaffe. Collective nouns in British English are referred to using plurals, e.g. "Apple are planning a new product," vs. the American "Apple is planning a new product."
Perhaps. I know it as a more modern linguistic split that isn't really related to the British/American divide. Regardless of the reason, many linguists would laugh someone like them out of the building. Living languages are constantly changing and while somewhat steady rules ensure there is less confusion - the majority will always win.
If the majority of people refer to collective nouns as singular than that is the correct way to use them because the "correct way" is only ever defined by the majority.
How is the pronunciation of a word decided? Majority of people saying it one way. How do people agree upon the meaning of a word? Majority of people using it to mean something. How does grammar become more lax? Majority of people speak with fewer restrictions.
i contest the moderne way of speech is to be thovght proper as he has argvede, bvt the olde way of speeking is the trve way!
If the majority of people refer to collective nouns as singular than that is the correct way to use them because the "correct way" is only ever defined by the majority.
How is the pronunciation of a word decided? Majority of people saying it one way. How do people agree upon the meaning of a word? Majority of people using it to mean something. How does grammar become more lax? Majority of people speak with fewer restrictions.
i contest the moderne way of speech is to be thovght proper as he has argvede, bvt the olde way of speeking is the trve way!
> "To that end, we’ve spent the last two months doing detailed interviews with CTOs and lead recruiters at the top 25 Y Combinator companies."
How were you determining which YC companies were top?
How were you determining which YC companies were top?
I would be interested in A/B comparison of company responses according to immigration status (i.e. whether or not a candidate needs visa sponsorship). Any data available?
In this thread people stress how it is important to learn new things.
And then how showing interest in a new thing (Machine Learning) is a red flag.
Go figure.
How does compensation play into these results? The 9 categories will have very different comp profiles
Pattern here is you are better if you start up instead of looking for a job. I've seen many and many mediocre engineers becoming employers just to spare themselves rejection.
The biggest issue in interviewing is the bad inexperienced interviewers. It's very very hard to be a good effective interviewer and in my experience even otherwise very smart programmers are not great at this. Here's few things that would help to find better match and eliminate lot of false negatives:
1. Pre-filtering should be based on candidate's public contributions at places like GitHub, StackOverflow, Wikipedia etc. Pre-conceived notions of someone being C# or academic is just simply bad.
2. Don't ask question that you didn't had to solve doing your job. It's absolutely the hardest part for interviewer to come up with great questions that distill the problem they had solved on the job in to something that can be described in 10 mins and worked on in about hour. Most interviewers are unable to do this and fall back to puzzles stolen from websites or coworkers like them. If you are not smart enough to form the great question using actual problems in your job than you have no business being an interviewer.
3. Don't do 45 minute interviews. That time is too short. Candidate has already taken a day off, there is no reason why you should limit each interview to 45 mins and make candidate rush. Countless great candidate get eliminated because they fall short of 15 mins, do longer initial chit-chat or just take one wrong turn.
4. Strongly discourage interviewers to look for exactly the right answers. Again hard to do than said. Most candidates that sail through problem have very likely practiced similar problem to death. The bad interviewer than penalize candidates who hadn't practiced that same problem VS who luckily happened to do so. Ultimately you are required to eliminate 80%-99% of candidates and this comparison is so handy that interviewers fall for it despite of knowing it.
5. Good interviewers knows the trickiest part of the problem and are willing to help out candidate without penalties. Bad interviewers considers any hints or help as sign of weakness and are mentally subtracting points. If you are an interviewer who thinks that your job is to give problem, sit back and watch the show then you are wasting everyone's time. Good interviews are lively discussion, two way conversation and in fact a collaboration.
6. Bad interviewers ask seemingly easy problem but that has chance of making a big tricky mistake or omission. Interview turns in to sport spectacle to see if gladiator candidate was able to duck the fire from the dragon that was behind him. Good interviewers make sure problems are real problem and not a competition to set up traps that everyone easily falls in to.
It's kind of bizarre that most companies claim that they have huge headcount to fill and they don't find talent while their "rejects" have already been having great jobs at great companies with nice history of career growth and compensation raises. The real problem is bad inexperienced interviewers who have been molded to ask same puzzles they had been asked and have been trained to have expectation for candidate to magically arrive at correct answer with error free compact code under 30 minutes. It's utter nonsense. The result is that most candidates now keep working on puzzles for months which has little relevance to actual problems in job and not even a remote indicator of candidate's passion or ability to take initiative or collaborate or ship something in real production consistently.
1. Pre-filtering should be based on candidate's public contributions at places like GitHub, StackOverflow, Wikipedia etc. Pre-conceived notions of someone being C# or academic is just simply bad.
2. Don't ask question that you didn't had to solve doing your job. It's absolutely the hardest part for interviewer to come up with great questions that distill the problem they had solved on the job in to something that can be described in 10 mins and worked on in about hour. Most interviewers are unable to do this and fall back to puzzles stolen from websites or coworkers like them. If you are not smart enough to form the great question using actual problems in your job than you have no business being an interviewer.
3. Don't do 45 minute interviews. That time is too short. Candidate has already taken a day off, there is no reason why you should limit each interview to 45 mins and make candidate rush. Countless great candidate get eliminated because they fall short of 15 mins, do longer initial chit-chat or just take one wrong turn.
4. Strongly discourage interviewers to look for exactly the right answers. Again hard to do than said. Most candidates that sail through problem have very likely practiced similar problem to death. The bad interviewer than penalize candidates who hadn't practiced that same problem VS who luckily happened to do so. Ultimately you are required to eliminate 80%-99% of candidates and this comparison is so handy that interviewers fall for it despite of knowing it.
5. Good interviewers knows the trickiest part of the problem and are willing to help out candidate without penalties. Bad interviewers considers any hints or help as sign of weakness and are mentally subtracting points. If you are an interviewer who thinks that your job is to give problem, sit back and watch the show then you are wasting everyone's time. Good interviews are lively discussion, two way conversation and in fact a collaboration.
6. Bad interviewers ask seemingly easy problem but that has chance of making a big tricky mistake or omission. Interview turns in to sport spectacle to see if gladiator candidate was able to duck the fire from the dragon that was behind him. Good interviewers make sure problems are real problem and not a competition to set up traps that everyone easily falls in to.
It's kind of bizarre that most companies claim that they have huge headcount to fill and they don't find talent while their "rejects" have already been having great jobs at great companies with nice history of career growth and compensation raises. The real problem is bad inexperienced interviewers who have been molded to ask same puzzles they had been asked and have been trained to have expectation for candidate to magically arrive at correct answer with error free compact code under 30 minutes. It's utter nonsense. The result is that most candidates now keep working on puzzles for months which has little relevance to actual problems in job and not even a remote indicator of candidate's passion or ability to take initiative or collaborate or ship something in real production consistently.
[deleted](1)
I suspect in addition to not having the "stomach" for an unlimited number of interviews, they don't have the vacation days to burn for them. Let's say you are working already and have 10 days a year vacation (pretty standard). With these ridiculous all-day interviews, you have the ability to waste that vacation on a maximum of 10 companies, and that's if you choose not to take any "real" vacation at all during the year.
In an environment like today, where every company is ostensibly hiring yet overly picky, a job candidate potentially will waste their entire PTO balance on interviewing with companies serious about interviewing but not serious about hiring.