I have had a similar problem - interviewed dozens of people with exactly that pattern and they were universally clueless. No idea how seemingly-good Masters programs bring in so many people with zero basic CS knowledge.
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.
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).
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.
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.
If so, I would keep the pointers in a set to mark nodes as processed but is there a more elegant solution?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(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.