My Google Interview
cforcoding.com
cforcoding.com
What's the default bytes per block in random linux distribution x version y when using filesystem z?
My response;
I'd google it.
Perhaps this is unique to the Australian branch of Google or something but I get the impression that they're much more into the whole meaningless rote memorisation of facts than is often let on.
I had a contact from another Google HR person a couple months back in Estonia, this time for a development position. I can't say I wasn't tempted but this time I turned them down flat.
I'll frame this in what I know, which is programming. I think it's entirely reasonable to ask someone how a hashtable or even a quick sort (or some other O(n log n) sort) works because programmers should be familiar with that even if 99.9% of the time (if not 100% of the time) you're using a HashMap or std::map or dict or whatever.
But number of inodes does seem somewhat esoteric.
I found it pretty ironic actually as that's exactly the kind of thing we have search engines for.
Anyway, isn't block size standard across all OS?
Apologies for sounding a little addled but it's been five years since I have been a systems administrator so it's all melted together in my memory.
-b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem (see the -T option).
I remember that Red Hat and Fedora used 1024 on my computer.
As for the distribution specific thing, maybe some distribution had their own version of /etc/mke2fs.conf (settings for mkfs, including block size).
"...Well I dunno but let's see...Filesystem Z(let's say reiserfs)...so this one's pretty good with really large files...its preferred to other ones(say ext2) for both support of larger files and better disk checking...at the time of distro x, version y, filesystem D(that you may be familiar with) hadn't even come out and was probably an improvement over Z, so I'd wager less bytes per block than filesytem D but more than...."
...or so could be a possible response...I hope I am getting my point through, though of course you're the one to have lived through the day and not me and I'm sure your reply was what you felt best, at the time.
That particular thought did only occur to me sometime later though so could be it certainly.
"I'd google it" is exactly the right answer, as far as I'm concerned. Unfortunately, it's never the answer interviewers want to hear. Regardless of whether they've asked good questions, it's invariably one of the most common responses interviewees will make when they don't know the answer. Whether or not the interviewer had a justified expectation that you should know the answer, "I'd google it" immediately gets you downranked by association with people who don't know their shit.
I assume this was an intentional approach: find an area of knowledge the candidate should understand at a high level, but probably hasn't committed the details of to memory, and see if they can reason it out.
You learn significantly more about someone when they're a bit out of their element; does their confidence evaporate, or do they work through it and come up with a reasonable solution?
And of course there are those who would answer take a best guess stab rather than appear to not know the answer which would be undesirable as well.
echo "a" > a; du -sh a; rm a
2.0K a
dumpe2fs /dev/sda1 | grep -i 'Block size'
Block size: 1024
$ du -sh /tmp/a
4.0K a
$ tune2fs -l /dev/mapper/VolGroup00-LogVol00 | grep "Block size"
Block size: 4096
I get similar behavior on the other partition:
echo "a" > a; du -sh a
8.0K a
dumpe2fs /dev/VolGroup00/LogVol00 | grep "Block size"
Block size: 4096
Though if I 'touch' the files to create them, they are the blocksize. Which seems odd, since on my AIX and HP-UX boxes that gives files of size 0.
Didn't get the job. I didn't make one mistake and I thought they liked me. I have zero clues as to why. I'm not really upset about it, it was just a very frustrating experience.
All the more reason to do your own thing :-)
I'm usually a fairly good judge of this sort of this so I usually don't need to ask. Eliciting a response may not give an accurate response (eg putting someone on the spot when their view is negative could be somewhat confronting).
Practically speaking however, time constraints tended to prohibit such chit-chat anyway.
Google started in the USA. In the USA if you give feedback, no matter how well-intentioned or apparently harmless it may be, that can be used to sue you. Even if those lawsuits are unlikely to go anywhere, they are a distraction. So no US company will give you feedback.
And that's become standardized in Google's procedures.
And unfortunately not just obvious stuff like "we didn't hire you because you're black". You can say something innocuous like, "your grasp of algorithms didn't seem strong enough" and the candidate will flash to a particular interviewer who asked an algorithm question they didn't get, and become convinced that that was who blackballed them. And can further become convinced that that person actually had it out for them for unrelated reason X.
This might be unlikely to wind up in court, but it happens often enough that it shows up in nasty blogs, rumors, etc that every large company has learned that you just don't want to go there. And none of them do.
How is that supposed to help?
The lack of feedback does suck, but I wonder if it says more about our own ability to judge our competence than about the interview process itself. As btilly points out, companies in the U.S. are almost required to not say what you did wrong, for fear of lawsuits. Plus, the hire/no-hire decision usually comes down to a visceral reaction, so the decision-makers may not even know why they decided one way or another.
Also - if you think the lack of feedback for interviews sucks, it's ten times worse when you're doing your own thing. I was an entrepreneur before Google, and we launched like 4 websites before I threw in the towel and got a job. Each one of them was met with a resounding...silence. Nobody saying we were bad, but nobody saying we were good either. We were just irrelevant. That's the way most startups go: if you're successful people will just quietly use your product and never acknowledge you, and if you're unsuccessful, people will just quietly not use your product and never acknowledge you. The only startups that get masses of haters are the ones where the founders were previously famous but royally fucked up (eg. Cuil), and the only ones that get massive acclaim are the ones that solve a hair-on-fire problem in a particularly spectacular way (eg. Google).
The lack of feedback makes me just assume every interview is a crapshoot and there's nothing I can do to try and improve.
This experience bugged me for a while. Man what I would have given to see that guy's notes about me :)
I suspect they would argue the impact of false positives (hired but don't work out) greatly outweighs the loss of false negatives (potentially great employees that can't pass through the filter). This may be true for the one company everyone and their dog wants to work for, but I wouldn't apply this kind of process to my startup.
It also feels like it might result in a surfeit of homogeneity. Genetic diversity is important; if everyone is a clone, all it takes is one pathogen to wipe out the population.
Companies that don't have a large enough pool of quality applicants to hire from need to turn that equation around: rather, they must try hard not to let the excellent applicant get away, as they may not find another.
I would agree that for the vast majority of companies, having an attitude like that is a losing proposition.
Most states in the US have "at will" employment laws meaning that its easy to fire a person after a couple of weeks if its obvious they're not working out.
So why is that bad? Well, for one thing, the questions asked usually aren't directly to being good at your job. Consider the classic "How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?" Very, very few people are going to come up with the correct answer to that question without having seen it before especially in a high pressure interview environment. Yet people ask it all the time in interviews. Why? You're just selecting for people who have had to interview a lot (got rejected a lot).
A newer style of interview that I quite like is to ask someone to write a moderate chunk of code with a laptop, access to the internet, and a few hours. At least you're measuring something that's directly related to software development.
An amusing variation on this might be to pick the next n interviewees and tell them to spend the day working on something as a team. Observe via camera or one-way glass.
While this is true, isn't quite unlikely? Why not just invest the time into becoming a /good/ developer.
>"How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?"
What do you mean by "accounting" information?
In the real-world I'd probably just brute-force it and keep around a set of elements already gone over. However I couldn't imagine ever having a need for that as I'd (and hopefully anyone I was working with) stick to the standard push_back functions available or that I created. So it shouldn't come about...
I feel I've missed something here, so care to elaborate on the answer?
It might be unlikely for people applying to google, but I can attest that people will memorize what they think are details that will make them sound like they are competent to get through an interview.
The software development industry is one where you can really make it into a position with decent pay by bullshitting, and then surf the wave of nothing-getting-done-because-of-corporate-policy for a while, while making yourself appear like a magic technology man if you really feel like it. This probably isn't going to happen as much with a company whose hiring process is filled with competent software engineers (but there's also the opposite problem...)
It sounds like hell to me, but I'm concerned with writing code and feeling intellectually fulfilled, not just with making stacks of cash.
In the real-world I'd probably just brute-force it and keep around a set of elements already gone over.
That is what is meant by accounting information - keeping track of the elements in the list you've visited.
I believe the generally accepted answer for this question is to use two iterators, one moving faster (two elements at a time) than the other (one element at a time). If there is a cycle in the list, at some point the two iterators will be pointing at the same node. Otherwise, the iterators will reach the end of the list, meaning no cycle exists.
What do you mean by "accounting" information?
The usual way to state this problem is, "How can you detect loops in a singly-linked list without modifying nodes and using O(1) data."
The answer is that you start with 2 pointers to the beginning of the list. Then follow the pattern of advancing the first twice, and the second one once. You have your answer when the first reaches the end, or the first and second point at the same spot.
There are a lot of problems with a trick like that. And it is true that if you've seen the problem before, you're going to be at an advantage. So practice a few of them to get use to the form. But there are enough such problems out there that it is significantly easier to become a good developer than to learn a broad enough selection of them to have a good chance of getting through a set of interviews off of memory.
You can get to be a better programmer, by practicing, too.
If the system is easily gamed, and they know that, and you know that then failing to game the system shows a lack of motivation.
So, perhaps they're not selecting for what you (or even they) think they're selecting for.
It's a popular meme on HN that people's intelligence and abilities are fixed from the start. In reality, they're quite plastic and improve over time when they're put to a use.
Note that outside of few companies such as Google, Microsoft, Apple and some start-ups (and even for good chunk of roles within those companies) great deal of programming involves wiring together components somebody else wrote, while working around bugs in those components. There's nothing wrong with that, in fact, if someone already solved a problem adequately enough it's your duty to build an application based on that solution rather than re-invent the wheel, this time with new and exciting bugs (I'll confess to having done that bunch of times, going as far as writing my own RNG once). If you want to understand how the "magic" of those components works (so that you could get some of the most intellectually rewarding jobs which involve creating such "magic"), you have to do that on your own time.
Thus, if you have a regular programming job specific portions of your intelligence will atrophy as they're not being used. If you've found a job that is intellectually stimulating, then you have no reason to interview elsewhere unless you're grossly underpaid, have to commute to the North Pole and write firmware for machines that torture baby seals.
When an interview candidate is truly smart e.g., can figure out a more puzzle-like problem without ever having seen them before, that's great and respectable. Give her a few extra points. When a candidate shows persistence, passion (coding in her spare time on the sort of problems you typically don't see in day to day work), curiosity (learning about skip lists just because they're... really cool) and a way to apply her intelligence (even if that's not genius level) to her field of work (being able to keep multiple levels of indirection e.g., pointers and recursion in her head) that's even better.
In my (so far, limited) experience in the industry I've noted that there are several types of programmers:
1) The "99.9th percentile" or "10x" programmers. They usually have an innate ability that was well nurtured from the beginning. There's only a handful of them, fairly equally distributed between Google (prior to it Sun, Bell Labs), start-ups, academia and quantitative finance / hedge funds. It's very visible: they'll solve problems quickly, they'll write code and get many things right the first time. They'll spot tricky concurrency issues by just looking at the code. If you manage to find one, by all means move mountains to hire them. Problem is, why would they join you? Money is not a motivating factor for them (not always out of principle: they're generally well off already) and companies bend rules for them (e.g., let them work from home or open offices in their home town if they're not local). If you want to hire them, hire all of their (respected) coworkers and friends, first. May be then (if things turn sour at their workplace) they'll consider you. The other way is to spot one amongst the crowd of interns or fresh graduates (Joel recommends that).
2) Visible poor ones. Typically very nice people, sometimes highly persistent and entrepreneurial but without the ability and/or education (self or formal) needed to succeed in an engineering discipline. They may still be smart: surprisingly, I've seen several people with advanced degrees in Mathematics and Computer Science that fit that bill (how that could happen evades me). Typically these are the people that are always on the market: who can't do fizz buzz, reverse a linked list, etc... It's trivial to filter them out. If they're really eager to be involved in software development, project/product management may be a right fit for them if they're otherwise smart and technical (see "The Russian Lit Major" by Rands for more on that). Oddly enough, I've seen people like that found profitable and sustainable small businesses (even if they weren't technology start-ups with home-run exits).
3) Everybody else. They're intelligent and educated (again, whether self or formally) enough to be <b>a programmer</b> but it either took or will take them work to be a great one. They have no genial ability, they will write code that has bugs and will have to sit down at a debugger to figure out why their code doesn't work. Odds are most people on HN fall into that category. Question is, how persistent are they at this? Do they give up after getting a cryptic error message? Have they had enough experience to avoid common causes of bugs? Are they willing to take time to improve themselves (to be able to "work magic") rather than being content to be typical enterprise developers?
People in this category are very well capable of being 95-98th percentile programmers. It just takes practice (and not just paid practice at work) in addition to dedication and passion, not just innate qualities (such some forms of intelligence), to get to that level.
They range in their current ability from "framework developers" (who don't care how something is implemented, but know a particular implementation well enough to get the job done) to what I called "95th-98th percentile" developers. Finding people on the upper end of that range (who have worked/studied their way to that place) is what programming questions should be aimed at, not just at finding general intelligence.
Majority of employees in serious technology companies (Google et al) as well as a most start-up founders (with a few exceptions of some true "10x" programmers e.g., Bill Joy of Sun) fit that bill: they persisted at and practiced something they loved for a long period of time and became great at it. There are more of these people than there are "10x" programmers and many have earned the respect of the "10x" programmers and are going to be able to attract them to your organization in a "get an already great programmer, get introduced to his genius friend" deal.
I recently was in an interview for an iPhone dev job. I was prepared to talk about Objective-C/Apple SDK since I was working with that. However, they started digging into projects I had done at my last job (in Java). I struggled. I just hadn't thought about that work for a few years, and probably came off like I was embellishing my resume. After the interview, once I caught my breath and thought about it, all the details started coming back. Needless to say I was kicking myself for not being able to recall it sooner.
Just the way my mind works....
You'd have to come up with some suitable toy problems that you could make significant progress on in a day.
Their puzzle archive: http://www.itasoftware.com/careers/puzzle_archive.html?catid...
I think the reason they don't anymore is that they're a household name. They get tons of applications without any clever tricks. In some ways, I think this is too bad, because it attracts applicants who (in JWZ's words) "want to work for a successful company instead of working to make a company successful." But there's really no way to turn back the clock and make Google hip & unknown anymore.
* How many ways are there of painting the sides of a cube using four different colors?
* Which colors would you choose?
Still, something like portfolios are a very practical way of evaluating candidates because you're looking at real, concrete things the person has actually created. A modern coder interview is more like kicking the tires on a used car and then immediately deciding if you want to buy it or not.
(Of course, if the code on a candidate's GitHub page or blog is terrible, that tells you something too...)
Another option is having an application (desktop or web) you've written that we could then discuss during the interview: why do you have that feature? how did you implement it, let's look at the code, etc.
I have never had an applicant show up with code examples or anything to demonstrate what he had done (though I did prescreen someone who managed his own OSS project. He was hired) and really it would have a big impact in the hiring decision for a number of reasons. It doesn't have to be OSS or protected company work. If you've ever done a side project for fun you're already ahead of most applicants I see.
Hire him to work for 1 week at a decent hourly wage.
If he's good, he's good.
I don't think 1 week is really enough to do anything important. For a good candidate, anyway. I'm sure a bad candidate can find lots of stuff to screw up in 1 week, especially if they're trying to "impress".
I think that physical essentials such as desk, workstation, etc, should be taken care of already. A smart company would have these items available in the chance that an amazing candidate could start immediately. It's a relatively small overhead cost on things that are going to eventually be required. With exception to the computer, the value of the items won't degrade with time so you might as well purchase them sooner than later.
I do agree that it may take some time for even a good candidate to become productive member. However, this period of time is going to happen no matter what. By having the candidate on as a consultant at first, you at least retain the option of not hiring him fulltime... which would be much a cleaner than hiring him, then firing him shortly after or dealing with a dud employee.
It's basically a "try before you buy" type of deal. No matter what car you're going to buy, it's going to take you some time to get used to it. Does that mean you shouldn't test drive them? As it stands now, the "test drive" is supposedly the interview. To me, it makes more sense to have a longer "risk free" test drive period, especially when you're going to be investing a lot into something.
Huh? Does your company hire pretty much everyone they interview?
The only thing I can think of is maybe they couldn't find interviewers for the normal time slots, and so they had to schedule one at lunch as well. Qualified interviewers are often a scarce resource at Google, mostly because of people like me who never sign up for it, and they try to avoid assigning more than two interviews/week/person to avoid burnout and let them still get actual work done. It may've been a choice between "schedule one during lunch" or "wait another week until a different interviewer is free".
This can be the traditional: wow, this person has mastered all these fields very well. But it can equally be: wow, this person did extraordinary things with this thing that I've heard good things about; or, wow: I could totally use a person like that on my team -- I think culturally this type of person is valuable; etc.
Basically, you want to figure out the selection of likely thoughts the interviewer will have about you -- choose the set of most optimal, most distance-traversing in their mind (some of which ideally differentiate you for your peers), and give them some excuse to figure those out.
It's, sadly, not completely unrelated to PUA, as our minds are trained to seek and, with cognitive dissonance, to esteem the general direction of what we've verified before.
Fwiw, same pattern as setting traps in poker. Though hopefully you're not being duplicitous, but rather smoothing out an already error-laden, discontinuous situation.
Not true one bit. I don't know a lick of C++ and never encountered it in my interviews there.
In fact, the questions I was asked there could have been easily answered in any language, as they were language-neutral and heavily on the side of pure algorithms.
Your experience may have been thrown off by having C++ on your resume, assuming you do.
Only once was a particular language required (I was asked to implement memcpy, in part because the interviewer wanted to test my knowledge of low-level C and void pointers).
That said, I did write one of my solutions in OCaml even though the interviewer did not know the language (I asked him if I could, and he got the gist of my solution).
Only experienced developers can contribute and answer question in Stackoverflow. Questions are generally hard and random.
So if Google hires only from the top 10% (say in Australia); isn't this a critical fail in the hiring process? (considering cletus with ranking 4 in sof, I can safely say he's among the top 1% or 0.5%)
The only way you can really "safely say" that someone is within the top 1% (That's a pretty elite group. That's like saying "I can safely say he'll get into Harvard.") is if you've seen a significant amount of their actual code (working with them, OSS, etc) and been consistently amazed.
And that's with something easily quantifiable. How exactly do you quantify the percentile of a programmer?
FWIW I make no such claim about being the top 1% nor do I claim SO ranking translates to the nebulous concept of a programmer's ranking. If anything, SO reputation is a function of time more than anything else. It's also an indicator of persistence but only a positive indicator (meaning lack of a SO ranking obviously doesn't mean a lack of persistence).
He set them to run in the background and wake up periodically?
(Apologies to Wes Anderson)
There are comparatively few questions that would fall under the category of computer science. I would be hesitant to say that having a lot of points on SO would automatically mean you are a genius programmer or problem solver.
Go look at Jon Skeet's top grossing answers. Only one of them is related to computer science.
They go to great lengths to ensure this is not the case. If the feedback from five different interviewers led to a 'no hire' decision, the chances are good that it was the right decision. Of course, no system is perfect. They tend to err on the side of exclusivity; it's much cheaper to decline a suitable candidate than it is to hire someone who won't work out in the long term.
That may well be the case and I can't dispute the conclusion because I am unaware of the position. Were they looking for a hardcore C++ programmer? That's not me.
This goes to my observation that feedback is important. I've applied for positions that were slim chances before but I knew they were slim going in so I could set my expectations accordingly.
As for the lottery part, 2/5 didn't know my primary language. That seems open to interpretation.
I see the same behavior with VC's -- no usable feedback. It's like in poker -- there's no game-theoretic advantage to show your cards if everyone else folds.
In many cases this is still true at the time of the hire.
In a few cases this is still true at the time the person starts on the job.
My interview experience actually involved them hammering me on the languages I said I knew but wasn't an expert in. This is likely as they were trying to find out whether I was lying (or, put kindly, overstating) on my resume. From what I've seen there are a few people who put every language down that they've ever written hello world in ;)
(disclaimer: recent intern from Google Sydney office)
But you know what? From a certain perspective, that's fine. We're currently going through a hiring phase at the startup I work for, and I'd much rather turn away people who might be ok than lock someone in who slid by. From his StackOverflow profile, cletus is a top-notch developer (or at the very least passionate and knowledgeable), it just sounds like he encountered his anti-loop. The biggest problem I see (and encountered this myself with them) is that there's no real feedback, even if your raw score was only just below the mark, where it might behoove everyone if you came back and interviewed with a little more experience and/or preparation.
I am a Googler. I mentioned explicitly that false negatives happen, and stated why they are preferable. Why, then, do you preface your comment with a disagreement?
>> If the feedback from five different interviewers led to a 'no hire' decision, the chances are good that it was the right decision.
As a recent hire at Google, I don't really think this is the case. There's not just a bias towards false negatives, there's a strong bias. It's well understood here that lots of qualified people are turned away.
And for whatever it's worth, the offer to keep your resume on file wasn't just lip service. I interviewed two years ago unsuccessfully, and was recruited a year and a half later based on the strength of that failure. It's also maybe worth mentioning that my only prior work experience was four years of desktop software development in C#, so I don't think the Microsoft thing is that much of a black mark.
This is pretty much exactly what I said. Do you think if I'd pointed out that I'm actually a google employee also, I might have been spared the down votes?
Jobs interviews at Google aren't near perfection with a slight bias towards false negatives, and it's unfair to the people who don't make it through to suggest that they are.
The part about being denied because he was Microsoft-centric and yet Jon Skeet was accepted was quite amusing.
The recruiter was a tad vague about it but if I were to venture a guess, I'd say Google scans the high-profile OSS projects and associated mailing lists. That's about the only place they could have found me.
My advice don’t feel disappointed if you don’t get the OK there are many reasons why someone get rejected, most of them not necessary skill based; so JUST MOVE ON.
I would likely have failed our own interview processes, yet I was one of the guys let know I was indispensable and not to worry about my job security by upper management when we were going through layoffs in the middle of the financial crisis, going so far as to offer me a raise in the middle of it.
The post-interview review of candidates needs to be:
(1) Are they smart?
(2) Do they practice self-improvement? A given if (1).
(3) Can we work with them?
But not many people have the balls to take a chance on someone from the left field, so they'll settle for the mediocre plodder who has learned how to game the interview process.
If, after four months, the people turn out to be "smart and get things done" and the company wants to keep them, they'd get the missing 50% from the first four months as a one-time bonus and 100% salary afterwards.
It costs something but it also costs a lot of time and money for both parties to engage into this mutual guesswork game called job interviewing. It might even cost everyone less as I bet many candidatepeople would have to be fired after only a few weeks or days.
Places that cold-call will do bulk hirings with the expectation that most people will leave. A lot of the time these arrangements allow employers to force a lot of work out of their employees with questionable tactics.
Having an incompetent (or malicious even) developer on your team for four months is likely to cost your company much more than 50% of their salary for four months.
I wasn't envisioning a sweatshop: if the company tried to extract everything out of cheap hires for four months, the company itself would lose. And there are these leeching companies anyway, working within conventional hiring practices as well. I had a good company in mind, one that really needs good programmers and not cheap minions.
An incompetent or malicious developer wouldn't really last four months, not probably four days. The projected four months was the final threshold after which most programmers can tell whether the candidate is really worth hiring.
Having new semi-hires around might certainly add up to the team overhead but on the other hand, that's what happens with conventional hires, too. Lots of teaching, tutoring, and support and things might still get crossed in the first few months. Plus the whole process of interviewing and that some hires quit or get fired within months.
So, to reply to your comment: having a batch of new hires, some incompetent and some possibly stellar, and few weeks to sort out the final candidates and few months to seal the deal, might not cost as much as you're afraid. Even a single new hire (carefully selected by HR, phone interviews, face-to-face interviews, and all) can eat up surprisingly lot of the team's time. Further, like hires in general, you don't want to be doing this all the time, just once a year or when you really, really need more programmers.
I could not afford to work for four months at half of my salary, and I don't have a family - so I can only imagine that people supporting a family would really not be able to do this.
Because best developers already have jobs and aren't knocking on your door desperate to take a risk like this.
That's the problem with the "probation period" ideas, in addition to creating churn and other unpleasant hygenic effects, why would somebody with a great job willing subject themselves to limbo? It will likely end up being a filter for people who have no other options available to them.
I've sent previous interviewing managers questions asking what I can improve when I didn't get a job this year, and none of them returned my e-mail. Very frustrating, especially if you're someone who would like to improve themself!
Has anyone ever thought they randomly fail someone who might pass just to keep all future applicants on their toes?
I have nothing to say about Google's process, with the exception being that I was interviewed by a guy whose research paper I read, something that didn't really surprise me.
Superficial elements have way too large of an impact. it filters out things that should not be filtered out. and way too big of a judgement is made too early, and on too little information, and with too little confidence in the correctness of that judgment. resumes are demanded and then either not read or not remembered. small comments can be magnified in the mind of the listener and used to conclude things that cannot possibly be concluded. ridiculous questions are asked. and lastly, there's very often too much of an attitude that the company/interviewer is in the superior/owner position and the applicant in the subservient/inferior/slave situation (perhaps carried over from blue collar industry) when in reality it should probably be considered an exchange of equals.
Agree 100%. It's a kinder-gentler master-slave dynamic. That's part of why it's so fucked. So what's the alternative? Let's figure something out.