Generally if you are hiring on work product skills (coding for software folks) and can show that your test is unbiased and you hire to the test, then you can avoid being found guilty of discrimination even if you hire a disproportionate number of a certain group. To be rock solid you also need to show that your applicant pool is highly diversified and has representation from all groups. Sometimes that means going out and seeking out candidates (like women or hispanics) who are self selecting to not apply. And why you really do better if you blind the resumes your HR staff sees before they sort them into phone screen and skip piles.
This is a great point and it's why I always include FizzBuzz in any interview—no matter how they were referred, how impressive their resume is, or their confidence level.
Having consistent benchmarks helps give you legal cover, but it's also essential to running a solid interview process. If you're not applying the same tests to all candidates, it's impossible to detect problems in your filters and you can easily end up making biased decisions or hiring the wrong people.
Yes, I understand that it can be annoying to have to solve such a basic problem in an interview, but it only takes a few minutes—just get it over with, it's not meant as an insult.
Personal bias also potentially factors into how you describe it (so consider presenting it written, in the same format for everyone). E.g. let's say the interviewer goes into extra detail or ask for confirmation of understanding from candidates they favour.
Passed through all the on-site interview problems and then they silently dropped me. No "we're sorry, you're not a good match." No emails, no phone calls. Nothing.
How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?
When I studied CS, data structures and algorithms was the second CS course we were expected to take, right after "introduction to programming". It would usually be taken in the second semester.
That's the last time we were tested on a long range of algorithms, except indirectly if we happened to need a given algorithm to complete our work later. In the 22 years since, I've probably needed e.g. a depth first search once, and many of the algorithms I learned I've never touched on since.
So for many, it boils down to whether or not you cared about and liked that course. I happened to love it - I read the set texts the first weekend of the course, and spent a lot of time reading up on algorithms in the years before and after. But for a lot of my class mates it was a course they had to endure to get to more interesting stuff. Many of them would go on to do very well in other subjects.
If they can't figure out a problem like FizzBuzz given a complete description, then that's a deeper problem. But a lot of algorithm questions can sound like they are on that level because we expect people to know a catalogue of algorithms that most developers don't actually need through most of their careers.
same here - almost 20 years of dev, last time I needed to implement basic cs algorithms were in college and grad school classes (and some idiotic corporate interviews where preferred way of coding is apparently using a white board).
basic knowledge of fizbuzz, dfs, bfs, quicksort, and similar things of course is needed - however asking developers actually implement them in front of you is pointless, at least as far as job performance goes.
FizzBuzz is not some arcane algorithm. You don't need to study it.
It's literally writing a loop, testing equality, and printing some output. I don't know how you could program professionally and not be able to solve FizzBuzz.
This is the same for a lot of the basic algorithms we learnt and forgot.
This, to me is the big caveat. Just as there are a lot of people who are horrible at solving stuff they should easily be able to, I've conversely seen so many horrible interviewers that under-specify the problems they ask about because they assume people should understand algorithms that would make it easier to understand, or just assume people will infer things most people wouldn't.
"Take these two variables, derpyOne and derpyTwo, and swap their values"
For the record, I'm absolutely not talking about algorithms questions. I'm talking about literal FizzBuzz. A majority of candidates cannot solve it in 15 minutes.
> How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?
It's through a combination of:
1. Tests being based on memorization, not actual knowledge or programming. If you manage to stuff enough keywords into answers, it's possible to pass.
2. Lots of group work. The 20% of students who actually know how to program finish the project while everyone else slacks off and asks for help "with this one thing."
3. Outright cheating. There's a thriving market in recycled homework and exam answers.
No, 80% of people in the 'currently looking for a job developer pool' are terrible. But you have to consider that the worse a candidate is, the longer they stay in that pool. So judging developers as a whole based just on interviews makes them look much worse than they are.
You're right that the actual population of all job applicants over time is equally qualified to the employed developers.
However, the data that I have available to me as a hiring manager is the sample of developers who actually applied to my job. In that sample, incompetent developers are much more likely to be present because a competent developer only sends out <15 applications before getting a job while the incompetent ones can send out hundreds.
At any given moment, a competent developer is more likely to be employed than an incompetent one. Hence the incompetent ones are constantly generating job applications at a much higher rate than their actual presence in the population would suggest.
For the record, this isn't merely theoretical. The last time I was looking for a job, I was able to get an offer from the second company I applied to. Meanwhile a friend of mine with barely any experience had to apply to about 50 places before getting a single offer. If you were to pull a random sample of our applications, his would be way over-represented.
> think Google came out a while ago and said that their initial hires had no correlation to the really successful people in the company after...5(?)... years.
Sure, but Google still spends a lot of time and money on interviewing because anyone they hire has to be better than the average applicant. They get huge numbers of job applicants, the majority of whom are grossly unqualified.
> The interviewing process is known to be broken, so trying to extrapolate to say that the job-seekers are less good at these metrics than the employed is erroneous.
There are lots of problems with the interview process, but I'm really including anyone who managed to get to an interview (past the phone screen) in the "competent" category. There are seriously huge number of job applicants who can't program a basic loop without extensive help.
Actually, you only have the sample of developers you interviewed for the job. How many didn't get an interview? Are you confident that your resume filter is good and that the resumes rejected were actually bad?
> Meanwhile a friend of mine with barely any experience had to apply to about 50 places before getting a single offer.
Following up my previous point, how many interviews did that yield? The discussion here is over developers who look like idiots in the interview. Confusing that with applications clouds the discussion.
More specifically, I have the sample of developers who I did a phone screen with.
I'm reasonably confident that my resume filter is "good" in the sense that it's not rejecting people prematurely. If your resume shows any hint that you'd be able to do the job (ie. any amount of programming job experience and/or a CS degree) then I'm willing to give you 15 minutes.
> Following up my previous point, how many interviews did that yield?
A dozen or so. I'm deeply skeptical that the pool of applicants would be better than the pool of interviewees.
Recent undergraduate grad here. A lot of the algorithms I've seen on technical interviews were only covered once or twice in the curriculum. Basically, one such algorithm would come up in either the data structures or algorithms class, we would then work on it for the given assignment/exam, and finally we would move on from it. Subsequent course work would barely reference it.
These things are best learned through repetition. Unfortunately, with all of the other CS coursework topics that I was being educated on, it seemed like there was little room for the repetition to take place. (At least, not in the stereotypical four year timespan assuming that the given student enters a CS program with no prior programming knowledge.)
This is bizarre to me. It's like someone signing up for a music degree having never played an instrument. Maybe you'll cram enough to pass a test on the theory, but it's useless knowledge. It's unanchored and will float away.
Engineering students are expected to have a strong maths background. If you can't do algebra and basic calculus then there's no chance of getting in.
It's completely reasonable to expect a CS student to have experience programming.
If you say so. I neither see the reason nor the advantage. Don't get me wrong: I had experience in programming before entering a CS program, but I had fellow students who never did any programming before and they did just fine, while others with programming experience failed. And I'm pretty confident that all of them who managed to stay through the introductory year were/are able to do FizzBuzz.
I'm sure that there are many more people who could complete FizzBuzz on a homework assignment, with the help of the Googles, than could do so in an interview. And there are many mid-tier MS programs that are happy to take money from international candidates and give them every opportunity to keep paying.
Absolutely. They may even have washed out at higher numbers. The applicant pool described in the complaint definitely isn't representative of US CS majors nationwide, so you can't use it to draw inferences about the quality of students overall.
On the other hand this process makes about as much sense as requiring that I know how to shift a non-synchronized manual transmission in order to pass a driving test. Nobody is implementing most of these algorithms from scratch, and if they did it would be a bad practice without having a good reason to do it.
Somewhat related anecdote, I do computational physics. I once attended "training seminar[0]" put on by the funders for using DOD supercomputers, and there was this soon-to-be-minted computer science PhD student who was also an intern. Most of the systems have pbs[1], a batch system that prioritizes jobs from users based by amount of requested time, number of nodes, etc. The seminar leader (and I have before) referred to it loosely as a queue, because it sort of is, and the CS guy kept interrupting the talk (may be two or so times) to point out that PBS really wasn't a "queue" because it didn't respect FIFO in a strict sense... I mean, sure, he did know what a queue was, but I'm pretty sure that isn't the most interesting problem you could have.
[0] there was one fact I found useful, which was where to find their docs online. Other than that, it was the sort of stuff you can find by just reading man pages and such. Waste of time but checked off a box for the internship which made the funders happy, I suppose.
So, no esoteric data structures, but you really do have to know how to use the standard ones. It tends to trip up people who might have some book knowledge of CS but don't know how to apply what they learned. There's also a difference between knowing that a tree might be useful and being able to actually write some code to build a tree.
But the thing is, the next interviewer will have different preferences - there's no standardization here.
Now they might have been useful for something, but I suspect they are just playing the numbers game and showing up to a lot of interviews until they get in. So even if say 5% of coders are useless that 5% is vastly over inflated in the interview process.
I've been in situations where those kind of people have been hired too. Their code tends to be quite bad...
I would walk out of the room, but I am happy to walk someone though most of a problem they are not getting. The goal is going from an understood problem to actual code.
Maybe they are nervous and focused too much on the minimum part of this that they lose sight of what they are trying to solve for. But be careful not to spoon feed it to them.
This is a serious question. I hate the way interviewing works at tech companies. Though I've generally done well and it helped me break into the industry as an outsider, it's a really time-consuming and wasteful process on both sides. So far, I'm leaning strongly towards Reid Hoffman's suggestion of weighting references much more strongly than interviews but it's hard to say how far one can safely go with that approach.
Only somebody who doesn't write software for a living would claim that "between 0 and 0.00001% of the time in the real world" should these techniques be readily accessible in working memory.
As for "freezing up during a stressful interview": is that not some indication of what normal workplace stresses will do to your ability to complete technical work? I certainly wouldn't want to work with somebody who is knowledgeable but will wimp out the moment you ask them a tough question on the spot.
To add to roganartu's very good point about what filtering for that says about your company, you seem to be buying into the pervasive myth that "stress" is some universal and fungible thing. The stress of an interview is not of the same nature as the stress of, say, having a key server go down and take your company down with it. It's a fool's errand to think you can manufacture stressful situations in an interview and get a read on how the candidate would perform in a real situation.
I would argue that a workplace that is continuously stressful is not healthy, and optimising your interview process to filter for this is probably not a great idea.
Additionally, I would expect that when asked a "tough question" at work that you would have both the time and resources available to find or determine the answer, things that one likely doesn't have in an interview (and certainly not to the same extent).
#include <stdio.h>
typedef struct Node Node;
struct Node {
int data;
Node * next;
};
Node * reverse_linked_list (Node * node) {
Node * prev = NULL;
Node * next;
do {
next = node->next;
node->next = prev;
prev = node;
} while ((node = next));
return prev;
}
int main () {
Node * node;
Node nodes[3];
nodes[0].data = 0;
nodes[0].next = &nodes[1];
nodes[1].data = 1;
nodes[1].next = &nodes[2];
nodes[2].data = 2;
nodes[2].next = NULL;
node = nodes;
do {
printf("%d", node->data);
} while ((node = node->next));
node = reverse_linked_list(nodes);
do {
printf("%d", node->data);
} while ((node = node->next));
return 0;
}
On the other hand, I hope you're not saying that the DOM is the only tree you ever use and in 15 years you've never needed to build your own. If so, consider that companies might be interviewing people for programming jobs that aren't like that.
Why is a web developer implementing a DFS by hand every day? I would not hire that person.
Also, in an interview it's perfectly fine to say you'd use a library, if you know one that applies. (They might ask you next how you'd do it without a library, but you still get points for knowing about it.)
The other thing to remember is that everyone is effectively grading on a curve, and with practice you get better at interviews.
But on the other hand, no. I can bounce around modelling with basic data structures (hashes, arrays, structs/objects etc) in my head like a good juggler can treat 3 balls.
I think that is normal for quite a large subset of developer work. I assume there will be some jobs that won't need those data structures, but can't think of any. (Graphics and game developers would remember more math, of course.)
The description in the GP sounds more like the (probably false) stories about the Japanese English education: People with a vocabulary of 40K words that are unable to order coffee or talk about the weather.
If so, I would keep the pointers in a set to mark nodes as processed but is there a more elegant solution?
I hate brain teaser interviews as much as the next guy, but being able to do basic operations on basic data structures is pretty much the minimum to be a developer.
In ten years of full-time professional development I have never needed to recursively walk a graph. Hell, the only data structures in the software I worked on for the first six (real-time signal processing code) didn't use any data structures other than lists, arrays, and C structs. I would not be able to answer the interview question that started this subthread, despite my track record of efficient and well-designed code.
This very comment thread is a graph which is being printed depth-first.
That's certainly not the case with the NLP code I have been working on for the past 4.5, but I have never personally needed to search the (usually) trees in a structured manner. Most of our code that searches for things doesn't care about the structure of the graph during the search; it just searches a node list. Once the node is found, structure matters. There are some algorithms that use calculations like shortest path and tree height, but I didn't write the code to actually do that.
Sometimes these questions are used to probe the meta understanding of a candidate and using Graphs/Trees/DFS are universally understood concepts that make doing that easy.
As for the algorithms typical of computer science, not really. Searching and sorting has not been much a part of what I have done. My experience is mainly in translating math into code, often into code with real-time deadlines.
DFS for an acyclic graph is about five lines of code and shows me that you A. know a programming language B. can figure out a data structure. I would argue both are needed to perform a dev job.
The point of schedulers is much more complicated than a straightforward queue, as they seek to project how best to utilize system resources into the future.
Strange he would be so pedantic. Everyone in HPC certainly does call it a queue, as you noted.
The HPC people are referring to a "job queue", rather than a "ADT queue". Those are distinct things, the ADT queue is a much more restrictive defintion, but it's not an exclusive one. HPC queues are more like priority queues with complex ranking functions (and queues of queues), just like real-life queues where people can cut by paying more money (first class airline ticket).
Ah! You're in for some surprise down the line. Fizzbuzz almost always clear out large amount of applicants.
It's sad that FizzBuzz is such a "weeding out" tool, but I guess good to know that I can still pass the first round of an entry-level technical interview!
Once you're set on that, you at least know you have a person in front of you who, on the basic level, thinks like a programmer.
So I would say 8+ years doesn't matter so much and you shouldn't worry about that, as long as your mind can still "tick" the right way.
Learning implementation details about a specific programming language is not what CS is supposed to be about (see the quote about astronomers and telescopes). In fact, if you use several programming languages at the time, I'd go as far as to call it a waste of my time - if I'm worried about overflow for a specific problem, I can get the range of data (in which programming language? which architecture?) in 30 seconds online.
I can see it being a valid question if you are working in a problem down to the bit level. But those are getting rarer, and ultimately it's what an Engineer excels at.
The second question does seem fair, though.
You're right about it being engineering, not computer science, but IMO it's reasonable to expect someone applying to a programming job (assuming this is what it was) to have at least some software engineering experience.
C and C++ offer a wide variety of arithmetic types.
Double precision is not required by the standards
(except by the optional annex F of C99, covering
IEEE 754 arithmetic), but on most systems, the
double type corresponds to double precision.
However, on 32-bit x86 with extended precision
by default, some compilers may not conform to
the C standard and/or the arithmetic may suffer
from double-rounding issues.I am actually kind of sick of the people that say these details are not important to being a good programmer. They absolutely are, knowing fundamentals of the machine, language, and environment that you are developing in is essential.
Usually, I start off with some behavioral, get-to-know-them type questions. One of these is to ask them to recall the 'best software developer' that they've ever worked with. The great majority of candidates actually say themselves which is unexpected (and a little arrogant to me - weren't we all 'junior' developers once? - didn't we all once look up to someone?). But, surely one of the best would know when to use an array and when not to or know the memory and precision impacts of the variable types that they use.
In C you kind of have to know the size of a double -- you'll call "sizeof(double)" fairly often, you'll notice the number in your code.
In most languages, you don't have a way of knowing the size of a double -- and furthermore the size a double takes in your code won't be sizeof(double) anyway, it will be much more.
Anecdotally, in European universities, bachelors are the "get in as many people as we can for the tuition fees", while masters are the "let's be as selective as we can get away with".
I assume there's an upper limit on the number of students an university can take in for the first year, determined by staff and classroom availability.
I imagine quite many would be upset if they found out they were not being held to equal standards, and would probably point to foreign students paying more as the reason.
Of course not. You find out when the head of school tells you that it is your fault that all the masters students failed the subject and that you need to fix the situation. If you are dumb enough to ignore the hint the head of school gets someone else to re-mark the exams - either way the cash keeps flowing.
(Identifying such Universities will be left as an exercise to the reader.)
If you cant get into the ivy league of your own country, usa schools are a backdoor prestige option for the wealthy.
Bodyshop contractors will do anything. I've seen cases where those companies send shill candidates to interview, claim that candidates have more experience in reality (in one case a 22 year old with a decade of Oracle Financials experience) and submitting fake resumes.
Now I have a close friend from China, and the mistery is solved: others are doing their exams/essays/assignments for them.
Keep in mind though, this is likely a huge generalisation (not all Chinese cheat and other nationalities cheat as well), and I put more than half of the blame on the universities themselves (they earn a lot of money accepting these kinds of students), but long-term, it really dilutes the value of this education in my eyes.
Ya think? Sorry man I wouldn't be profiled as a cheater like that due to race or citizenship.
Public universities in the U.S. recorded 5.1 reports of alleged cheating for every 100 international students, versus one report per 100 domestic students
[0]: http://www.wsj.com/articles/foreign-students-seen-cheating-m...
On a more anecdotal level one of my fiancee's friends was dating a guy who sold SAT answers for a while.
I have a couple of friends who teach at international high schools here in Shanghai. It takes quite a long time to get through to the students that plagiarism is not okay and is taken seriously.
By the way no one brought up race in this thread until you did.
If it is widespread it's especially unfortunate considering there's already some controversy around the high numbers of asian applicants.
Btw, I only mention race because it is a central topic of the article.
Twice we hired someone based on the phone interview and it was someone else who showed up.
The third time it was someone reading interview answers off a chat client window.
I'm mostly annoyed because it reduces the value of the phone screen and requires more face to face interviews.
Indians cheat. A lot. It is just a different culture. Students in three different groups would turn in the exact same solution to a coding assignment, and they'd all get the same grade. I was baffled at first, then furious, and finally just learned to laugh about it, while understanding that they were only screwing themselves by not learning the material.
However, it did mean that the training programs would push out a ton of students that did not know a thing about programming, and definitely should not be in the industry. But it is understandable in a place like India where a software engineer can make a lot more money and earn far more respect than many of the alternatives.
I was friends with some of them who engaged in this. After being straight up asked for help during one exam, I warned them not do it, and that this behavior would get them kicked out of school here, but it didn't matter. Most were very smart and talented, and really didn't need to cheat. But they did anyway. Cultural thing, I guess.
Visas are faked, resumes are complete rubbish and it is my suspicion that the hiring managers/committees are bribed directly or indirectly.
I know people with 0 years of experience drawing salary of $110K from a large company by showing fake 8 years of experience.
Sadly all people involved are from my home country India. It really saddens me that we arrive here as economic refugees and destroy the very system that is so welcoming to us.
If you read the suit itself, there is a lot of wiggle room for Palantir. Here is the threat (paragraph 14 B) "An order permanently enjoining Palantir and its officers, agents, successors, divisions, subsidiaries, and those persons in active concert or participation with them... "
Here is how they can easily wiggle out: (paragraph 14 D.) "An order requiring Palantir to provide complete relief to the affected class of Asian applicants.." and (paragraph 14 E.) "An order requiring Palantir to hire Asian applicants from the affected class list."
It is foolish to create one bucket called "asian" and throw in people from Vietnam, Laos, Cambodia Philippines in addition to those from China, Japan and Korea. I personally do not think that the students have time to sit around and play the "race card". They've probably moved on to other things.
I've also noticed the lack of diversity in startups that is disproportionately affecting minorities. Software being what it is is usually a trade off between many solutions that actually work in the short term. So it is actually pretty easy to hire friends of friends and so on and if they can get something to work, you'll convince yourself that you've hired the right person for the job.
Friends being friends will easily pass the "culture fit" test.
Anyway I see a lot of direct and veiled comments against interview candidates from Asian countries with reference to their accents etc. I don't think HN should be the place for such comments. Having worked in the Bay Area, I can say that an accent is the last thing on anybody's mind once you've proved competence.
I can't speak for elsewhere, as I went to university in Australia, but down here we have a MASSIVE foreign student population as a percentage - International education is currently Australia's third largest export overall - mostly from India and most parts of Asia (kinda our closest neighbours).
My personal, very anecdotal experience is that Indian students were either amazing, or very much not very good. The route seemed to be do ANY degree in India, followed by a (one year?) Masters in IT in Australia. This then legitimised their IT bonafides.
The Indian culture also has a different attitude to cheating - it is seen as much worse to fail than to be caught cheating - and I saw this play out a fair few times, to the point that in one exam 5 Indians had to be physically separated for passing paper back and forth. We also had one girl who said to her lecturer "I don't see why it matters, I'm never going to work. I just need a degree so I can go home and marry a good man".
Now, to answer the quote, the reason this continues is due to the Australian need for the foreign $$$. As a result, very few foreign students are (or is it were?) disciplined for these infractions. Several times it has been a massive scandal down here (http://www.smh.com.au/nsw/mymaster-essay-cheating-scandal-mo... although it seems common: http://www.wsj.com/articles/foreign-students-seen-cheating-m...), and many locals worry it devalues their own education.
On the flipside, the very best students in my year were foreign, and often Indian, so this was not a one-size-fits-all situation.
YMMV, but the Australian universities need for foreign student $$$ has lead to MUCH lower standards for foreign students passing than locals, at least in the past.
(yes, technically anyone from Asia is Asian, but when someone says 'asian', it doesn't evoke the mental image of a caucasian Russian who lives in Novosibirsk.)
ahh, Georgia Tech
It is possible that I'm clueless, and cannot identify clueless people.
Thanks to you, TIL that Tech is a state university. Never knew.
(Oh, by the way, Florida Tech definitely fits the aforementioned stereotype.)
Not being able to recognize cluelessness in other people might just be an understatement.
Your organization is almost certainly not like Palantir so I'm not sure where your sympathy is coming from.
Interestingly most of them fit the same profile of a bachelor's from India, 1 or 2 years at a consulting firm in India doing something that could be argued is software development and now doing a master's at a large state university. To be honest I'm not sure how they got in or are able to graduate.