20 ms·
If companies interviewed translators the way they interview coders
- ToJans 9y ago> It means we do Agile. Everything is in a flat structure, except when it comes to salary and responsibilities. Pure gold!
- adekok 9y agoOnly from the experience of good people interviewing at bad companies. Interviewing bad people at good companies goes more like this: Q: Can you explain the difference between a noun and an adverb? A: I've worked at the UN for 20 years! I'm an accredited translator! I translated for Putin and Obama! <sigh>
- kevan 9y agoAs an interviewer, sometimes I feel a little silly having to ask a candidate super basic things like what the runtime complexity is for inserting an item into a list or array. But then a third of candidates that I interview fail pretty badly. At his last fortune 500 job one of my coworkers started every interview with fizzbuzz and had about a 50% pass rate on it. Maybe that's a problem with candidate sourcing, but there's a lot of people out there that can't code.
- lighthazard 9y agoHaving a hard time understanding why those candidates were even called in. No pre-screen coding practice? No pre-screen phone call?
- trendia 9y agoThere are a lot of people who have more credentials than skill, which isn't easily detected by looking at a resume.
- kevan 9y agoI don't know what their exact process was, but I'd guess there was just a non-tech phone screen before the onsite. It's a tricky balance, some people get insulted if you ask them to complete a pre-screen coding exercise. "I have 15 years of experience, stop wasting my time!" On the other hand, I've interviewed a few people with that much experience, supposedly code-writing lead engineers, that couldn't write the code to insert an item into a sorted array.
- brookside 9y agoWhat is the runtime complexity for inserting an item into a list or array?
- xxs 9y agoO(n) - regardless linked structure or array backed.
- arethuza 9y agoHow is inserting an item at the head of a linked list O(n)?
- Joe-Z 9y agoIt's an average. Sometimes you insert at 0, sometimes at 1, sometimes at 2, ... sometimes at n. On average it's O(n).
- poikniok 9y agoWho said you insert at different locations?
- abalashov 9y agoNobody. But who said you insert at the head? And who said the whole thing is list-backed? Insert is just insert--not a lot to work with there. Performance complexity is spoken to general cases and averages unless indicated otherwise.
- chaosite 9y agoIn this case it's the worst-case performance.
- sherincall 9y agoEasy: insert(list, node): node.next = list.head; list.head = node; sleep(list.count++); Remove the `sleep` in second version, and quote significant speedup. See also http://thedailywtf.com/articles/The-Speedup-Loop http://thedailywtf.com/articles/The-Speedup-Loop
- mtviewdave 9y agoThere is a core truth that there are "programmers" out there who cannot program, and the only way to filter them out is to have them implement some algorithm live. But I think a lot of the grief around whiteboard interviews comes from all the additional crap that's grown up around that, including: 1. That ideally a candidate should code up solutions on a whiteboard, while standing. That it's unnecessary, or even bad, to try to replicate a working situation by having the candidate seated at a computer. 2. That there's a correlation between difficulty of question and quality of developer. So a candidate who can implement both fizzbuzz and quicksort at whiteboard from memory would be a better developer at your company than one that can do fizzbuzz, but not quicksort. 3. That the ideal programming question has some sort of "trick". So the ideal flow when a candidate is answering a question starts with the candidate implementing a naive solution. After which the interviewer says "it's possible to do better". Then the candidate ponders for, ideally 30-60 seconds, whereupon they realize the trick and code up the optimal solution. My ideal interview process recognizes the need for a developer to demonstrate the ability to code while at the same time recognizing the above interview style for the cargo cult exercise that it is.
- sage76 9y agoWhat are these companies that ask fizzbuzz? Every company I have applied to lately, asks me impossibly tough questions on hackerrank, which have to be done in like 30 minutes each. That would mean perfect syntax, and perfect coverage of test cases with no knowledge of what test cases are failing, or else I am rejected. EDIT : Add to that, perfect time complexity. I had a question recently, which was so tough, that forget the allotted time, I have asked my friends about how to solve it and they seem to have no clue either.
- beagle3 9y agoCan you link to it / describe it?
- sage76 9y agoThis is all I remember now : An array represents a binary tree like this : 1 / \ 2 3 \ / 4 5 / 6 is represented as : 1 2 3 * 4 5 * 6 so apart from the last level, any missing child nodes are represented as *. You need to find the set of unconnected nodes whose sum is maximum. Child-parent relationship means they are connected.
- Clubber 9y agoWhen I was doing Delphi, the first technical question was, "what is the difference between a function and a procedure?" That was a quick and easy way to figure out who had written a program in Delphi before. Anything more complex than that or FizzBuzz doesn't add any value. Case in point: I interviewed a guy who nailed even the most obscure stuff, but he couldn't finish a project. He was great at small, complex problems, but he couldn't ship. We needed someone who can ship.
- VLM 9y agoEven more concrete example, something like: Q: Explain the difference between they're, their, and there. Q: Principle or Principal?
- pmontra 9y agoReminds me of those companies that throw online algorithmic puzzles to candidates. They do some good only to the companies running the puzzle services.
- Floegipoky 9y ago> Note to self: when we send a rejection letter to this candidate, be sure to include feedback that is too vague to be of any use to them, but will avoid any lawsuits. Haha, what feedback?
- theprotocol 9y agoWhat rejection letter? :)
- theprotocol 9y agoFor better or for worse, I've now become abrasive when asked interview questions in such a scripted, artificial manner. Because I no longer want the job at that point, I can respond more boldly, e.g.: "Where do you see yourself in 5 years?" "I don't know. Are you reading these questions from a textbook? FYI they're not very effective if you want to find someone who will do the job." "What's your greatest weakness?" "Trick questions in job interviews." This is obviously not good advice; I have just reached a point in my life where I will not be made to dance to the whims of the interviewer, despite which the job would likely go to one of the employee's friends rather than it being given to me anyway. One of the few merits of this approach is it tests if you can be frank with them or not. If they get offended at your lack of sucking up, then you probably wouldn't want that job anyway, because I find that if you suck up during the interview, you will find yourself struggling to maintain that ideal forever if you do get the job. It's better to be upfront about what things you actually care about.
- ryanmarsh 9y ago> This is obviously not good advice No. It is good advice. It's very good advice if you want to find a place where you fit well. Unless you're starving and just need a job, any job, right now. Allow me to explain: After some ups and downs in my career I resolved to be true to myself. In my case that means calling bullshit on ridiculous things. You know what happened? I found out really quickly where I would have been miserable, and I was totally surprised by some incredible groups that wanted someone just like me, they just didn't know it. Actual responses from me in interviews that found me a great fit: Q: <contrived hypothetical completely unanswerable> A: I don't know that sounds like a contrived question. I'd be asking why you have that problem in the first place. Q: "people who do what you do are often vague and noncommittal" A: that's because most people who do what I do haven't bothered to read the foundational texts, thus they rely upon tropes and ceremony. This field is full of muppets. Q: what's your greatest weakness A: sometimes I'm just a little too awesome smirk that says "are we really playing this game?" Q: are you <blah blah> certified? A: no I've purposefully avoided <blah blah> certification.I think it's heavy handed bullshit and I don't want to be associated with it or asked to do it No joke these were real responses that got me great jobs and client engagements. They also quickly helped me discover people I wouldn't enjoy working with.
- jobigoud 9y agoForgot the part when you must have a public portfolio of work you did for free in the recent years even though the job in question will keep intellectual property under a lock.
- nicole_express 9y agoIndeed-- require people who have a large public portfolio of translations they've done for free, and then have them sign a contract stating the company owns the rights to all translations they do while employed and for a year after they leave, regardless of whether they were on company time or not.
- rmc 9y agoI am tempted to ask to see the company's open source contributions
- TomK32 9y ago"translated early christian heresy text from greek to modern latin. Sadly won't be published ever by papal order"
- beagle3 9y agoOne of the interview questions I've used in the past is "reverse a linked list". Indeed, you (almost) never need to reverse linked lists in practice - but you often need to chase references of one kind or another (database, pointers, etc.) and do some manipulations on them that would result in a different list. If you have 20 data points, it doesn't matter what you do, but if you have 100M or 10B points, it makes a great deal of difference whether you do O(n), O(n log n) or O(n^2) or O(n!). I think this is a good question, because it is an abstract version of the kind of problems that any non trivial code has to address. It is easy to describe, and easy to solve if you know what you are doing. I don't use it anymore because it's too common to be useful. And yet, through the years I've gotten the feedback[0] that it is "far detached from real work", "tests how good I did in school rather than how good I am" and various other comments -- and almost always from candidates who did poorly; I've never gotten this feedback from anyone I would consider competent. [0] I try to get feedback through whoever referred the candidate, whether it's the friend-of-acquaintance, or the recruiter. I don't, in general, trust direct feedback from someone I turned down (or hired, for that matter).
- sidlls 9y ago> I don't, in general, trust direct feedback from someone I turned down (or hired, for that matter). That's a problematic attitude, in my view. It reads to me that you think you have all the answers already, or at the very least that you view yourself as being superior to people you interview. That lack of humility is troublesome for a number of reasons. As far as your interview question, do you normally not interview candidates to develop software? Your question is appropriate for a grunt who's entire responsibility is to thoughtlessly code up somebody else's design. It's not appropriate for someone expected to contribute thoughtfully to the engineering of a software product.
- beagle3 9y ago> That's a problematic attitude, in my view. It reads to me that you think you have all the answers already, or at the very least that you view yourself as being superior to people you interview. That lack of humility is troublesome for a number of reasons. I would correct that (if I could still edit) to "direct immediate feedback". What I meant was, if someone I just turned down for a job says "it's stupid", I don't consider that useful data; similarly, if someone I just hired says "This is the best interview question ever", I don't consider that useful data either. I do ask for, and usually get, direct and raw feedback from people I work with (both those who report to me and those I report to). > As far as your interview question, do you normally not interview candidates to develop software? Your question is appropriate for a grunt who's entire responsibility is to thoughtlessly code up somebody else's design. It's not appropriate for someone expected to contribute thoughtfully to the engineering of a software product. Can you elaborate on what you consider "contributing to the engineering of a software product"? and more generally what "software engineering" entails? I mentioned as explicitly as I can that I do not expect anyone to reverse linked lists. However, it is an abstract question that is not unlike the kind of things that arise in practice, e.g. figure out inverse relationships in data. And gives a good ground for discussion about things like requirements (time, space, correctness, verifiability, boundary conditions, erroneous inputs, etc) -- inside a well defined and (supposedly) familiar context; The same problem in a business setting would require a lot more definitions and would be frighteningly foreign for some people (to digest within an interview). How do you interview?
- EliRivers 9y agoIn the end we went with a different candidate. He doesn't speak the specific language we need, but he has experience with similar words in a different language and he's a lot cheaper. And also, http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...
- walshemj 9y agoLol the average chippy on a building site wont have worked with much if any hardwood. Having said at my first job our in house wood shop where capable of museum grade work in any wood you name but we where no 1 or 2 in the world for the areas we worked in
- diggernet 9y ago> Interviewer: But how many years of walnut do you have? > Carpenter: Gosh, I really don't know -- was I supposed to be counting the walnut? > Interviewer: Would you say you're an entry level walnut guy or a walnut guru? Oh, hey, I just had that interview. It's called the California State Systems Software Specialist examination. Almost 60 questions like: "Create processes (e.g., install, configure, maintain, secure, backup/recover, etc.) to ensure that technical staff are consistent with vendor documentation, application requirements, and departmental standards." or "Consult with internal/external entities regarding services provided by systems software teams and answer questions/inquiries in technical areas such as connectivity with departmental systems, data exchange, security, etc." For each of which, you must answer: Recency a. Performed the task within the last 2 years b. Performed the task within the last 4 years c. Performed the tasks more than 5 years ago d. Not performed Years of experience a. More than three years experience performing this task b. More than one year to three years experience performing this task c. Less than one year performing this task d. Not performed Level at which the task was performed a. Supervised or served as an expert on task b. Performed task as a lead c. Worked independently on task d. Worked under close direction/supervision on task e. Assisted another person on task f. Not performed If you don't happen to have been assigned the proper tasks in recent years to score highly enough on the test (by whatever algorithm they use), then you are not eligible to even apply for any Software Engineer role in the state, and can't retake the test for 6 months.
- odammit 9y agoI was once asked a very very specific question about a conflicting setting in an nginx config and the dude actually wrote the config on the whiteboard and asked me how I would make it work. I stared at it for what felt like minutes and then said, if I looked in your search history would I see you looking this up on stackoverflow? The guy said "yes" and I said I would make it work by asking you to send me the link to the stackoverflow answer. He laughed and said "you got me". Same company different interviewer asked me to explain the "pros and cons of Java vs Rails." I turned the job down.
- Declanomous 9y agoOne of my friends told me that when he was interviewed at his current company, they asked him a similar question, and he said he gave a long complicated answer that basically amounted to "I would google it." He got the job, so there you go I guess.
- odammit 9y agoGotcha style questions like that pretty much just ask "have you been in the exact same scenario as me last Tuesday?" My interviewing has boiled down to 30 minutes of shooting the shit to see what the person is like and to make them more comfortable and then a pair session with a ticket I haven't had experience with so we are both on approximately the same level. My goal in the session is to see how they interact with an unfamiliar project and what kind of questions they ask and their discovery process of learning our business domain.
- hashkb 9y agoYour interview process is unfair. 1. The shoot the shit session is guaranteed to be driven by your personal biases. 2. Working on a different ticket with every candidate ensures you can't possibly compare one candidate's performance to another's.
- odammit 9y agoTotes, but what interview is fair? I also send the same screening test depending on role so I do have a baseline, although I'm much more interested in our interaction during the pair session.
- bitL 9y agoThe issue is that most companies jumped aboard this insanity - it was originally meant for the top companies to get the best people, now every crappy company offering $40k salary is doing this...
- c8g 9y agorelated discussion Google: 90% of our engineers use the software you wrote (Homebrew), but... https://news.ycombinator.com/item?id=9695102 https://news.ycombinator.com/item?id=9695102
- base698 9y agoMaybe he was an asshole? You only got one side to that story.
- jmull 9y agoHeh, heh. My favorite bit is toward the end: ...we do Agile. Everything is in a flat structure, except when it comes to salary and responsibilities. If only this were an exaggeration.
- funkaster 9y ago> Yeah, you know, trans-comps, Translation Competitions. Those were you put a bunch of documents in Sanskrit, throw some beverages and pizza, and invite translators everywhere to lock themselves down for 48 hours to see who can translate those the fastest. Sometimes they add free prizes to spice things up. Have you ever won any of those? lol... I actually won a trans-comp when I was in (middle?) school: I was attending a catholic school and we were taught latin and went to some translation competitions: you had to translate a chunk of text as fast and accurate as you can. It was fun :)
- minimaxir 9y agoGayle Laakmann McDowell, author of Cracking the Coding Interview, commented on Facebook about this article (all text below is her words): https://www.facebook.com/groups/hackathonhackers/permalink/1642919005763578/ https://www.facebook.com/groups/hackathonhackers/permalink/1... > Weird analogy. Companies don't ask candidates the history of binary search trees, computer architecture, or anything like that. A better analogy would be if they gave this translator a particularly challenging piece of text to translate -- for example, one that didn't have a clear right answer and the candidate had to discuss different tradeoffs. But... then that doesn't seem like quite so silly of an interview process. There are absolutely valid criticisms of whiteboard interviews, but most criticisms made are either based on terrible implementations of whiteboard interviews or based on stuff that's just incorrect. (Yes, it's totally fair to criticize a company who conducted a flawed whiteboard interview. But that criticism doesn't apply to the system as a whole. That same company could mess up whatever your favorite interview style is, too.) > By the way: I don't actually know how translators are interviewed. But one of my best friends interviewed to be a journalist with some major New York newspapers (WSJ, etc). She was already a journalist before this, so they had lots of public writing samples for her (analogy: GitHub code samples). Did they just hire her based on this? Nope! She had to do a live writing test (analogy: whiteboard coding interviews). She also had to do a pitch session to talk about different potential stories she could theoretically write about (analogy: design/architecture interviews). Plus some behavioral interviews. Why not just look at her writing samples? Unlike for coders (which might not have public portfolios representing a significant portion of their work), basically all of her work product was actually public. So why not just hire from that? Well, because all they see is the final output. They don't know what direction she was given, how long it took her, how much editing/collaboration was involved, etc. A crappy writer in a particular environment can churn out good work -- because someone else is doing a lot of the work. Looking at the final result is actually not a great measure of someone's skills. Coding interviews aren't that special.
- jondubois 9y agoWhat's annoying in tech is that even if you do have public work (E.g. one or more popular open source projects), you still have to pass the technical tests in order to get hired. Nobody actually looks at your code and think "Oh wow, that code is clean, it works well, it's loosely coupled and high cohesion - We should hire this guy". Often they just want you to be able to solve lots of tedious algorithmic problems REALLY QUICKLY. The horrible thing is that even if you CAN solve these problems, you might not be able to solve them all within the allocated time (unless you've practised a lot recently).
- EGreg 9y agoDo interviews really go like this at many companies? Here in NYC I have never had unreasonable interviews even close to that. And I interviewed for a lot of senior developer positions and consultant positions. In our own startup we have a completely different approach. Our motto is "People live lives. Companies build products." We like to hire and work remotely because that eliminates geographic restrictions and lets people work asynchronously. We've found that the better the system for asynchronous communication, the better the long-term productivity and maintainability. We use a common folder structure, code conventions, for each project. Developers build fully documented reusable components that are re-used across projects. Every developer is very replaceable (meaning our losses are limited if they leave or scale back their time). This is actually a great thing for developers given our compensation model (see below). If a developer does something wrong (like checking in syntax error), we first check if this is something we should fix in the system (add a linter to the pre-commut hook). There are so many amazing open-source tools today. It's a compoundibg snowball to design a good system. Sometimes the COO job feels like an architect/developer, just like DevOps, but for people and configuring processes and systems instead of programs or servers. The best talent is the one who already knows or can learn your platform (in our case https://qbix.com/platform https://qbix.com/platform) and become productive. Who is eager to grasp new SKILLS (like debugging javascript with asynchronous call stacks) and get familiar with useful TOOLS (like Google Chrome). We hire from anywhere and prefer to work over the internet. Even our compensation model is different than what most companies do - it aims to attract independent people and entire teams, and compensate them based on the contributions they actually do. We want to grow a snowball in a transparent way, and motivate people by giving them ownership of a product or feature instead of focusing on making them sell their time as full-time employees who commute to an office. I'd love to get feedback on the compensation model btw: https://qbix.com/blog https://qbix.com/blog
- mcguire 9y agoI thought it would be something along the lines of, "Could you translate '¿Donde es el baño?'" "I'm sorry, I don't do well on tests. I thought we were going to talk about my past projects on my résumé. In fact, I'm quite offended by your question. Good day, sir!"
- mcbits 9y ago"That should probably be '¿Dónde está el baño?', but the question is clearly asking 'Where's the restroom?'" "Wrong, sorry. My sheet here says 'Where is the bath?'"
- spullara 9y agoAt Twitter I did a few hundred technical interviews and in general I don’t like asking CS student questions but you do need to figure out if the person can code. To this end I devised a whiteboard problem that actually mimiced a real problem. After I left I posted it on GitHub: https://github.com/spullara/interviewcode https://github.com/spullara/interviewcode It is important when doing lots of interviews to have a question that you know well and can be used to benchmark across your interviews. Something relevant to the job is an added benefit.
- xtracto 9y agoWhen I was working at Ooyala I used to do the typical data-structure interviews (trees, graphs, etc), until one time an interviewee asked me: "Do you guys use all this in your day to day?" I felt ashamed to have to answer "not really", which I did. After that, I started asking for answers to problems that I really had in the day to day. Some of them actually had real complexity (like doing binary search to overcome a buggy HTTP request items pagination library). I think the main problem with data-structures and algorithms questions is that, the person that originally envisions a question, understands the "soul" of the question and how to vouch the candidate as she solves the question. However, when someone else takes that question to apply it, he only sees whether the answer is right or wrong, without looking at the resolution process.
- NTDF9 9y ago>> I think the main problem with data-structures and algorithms questions is that, the person that originally envisions a question, understands the "soul" of the question and how to vouch the candidate as she solves the question. However, when someone else takes that question to apply it, he only sees whether the answer is right or wrong, without looking at the resolution process In addition, I think that when someone asks a binary tree traversal problem to a candidate, the interviewer starts fretting over trivial edge cases, function signatures and coding style etc. Whereas, if you would have asked a distilled version of that pagination problem, I would be so excited to have a chance to solve that problem and we could focus on my ability to solve that problem instead of my coding style on a whiteboard.
- spullara 9y agoAt Twitter I did a few hundred technical interviews and in general I don’t like asking CS student questions but you do need to figure out if the person can code. To this end I devised a whiteboard problem that actually mimiced a real problem. After I left I posted it on GitHub: https://github.com/spullara/interviewcode https://github.com/spullara/interviewcode It is important when doing lots of interviews to have a question that you know well and can be used to benchmark across your interviews. Something relevant to the job is an added benefit.
- spullara 9y agoAt Twitter I did a few hundred technical interviews and in general I don’t like asking CS student questions but you do need to figure out if the person can code. To this end I devised a whiteboard problem that actually mimiced a real problem. After I left I posted it on GitHub: https://github.com/spullara/interviewcode https://github.com/spullara/interviewcode It is important when doing lots of interviews to have a question that you know well and can be used to benchmark across your interviews. Something relevant to the job is an added benefit.
- dkarapetyan 9y agoI keep saying this but no one seems to be listening. Use triplebyte, interviewing.io, or recurse.com for all recruitment. You are not going to beat those folks in terms of quality of candidates. They have data and stats. You have anecdotes.
- daxfohl 9y agoBecause it seems like a misc plug? Recruitment is ridiculously ridiculous. Data and stats, so what?
- dkarapetyan 9y agoI'm not affiliated with any of them. The plug is genuine. I've been on both sides of interview table to know it's a crapshoot. You really are better off with one of those three than on your own. Those companies go out of their way to reduce as much bias as possible. In the long run we are all better off if we rely on data instead of anecdotes and fancy resumes.
- doktrin 9y ago> Everything is in a flat structure, except when it comes to salary and responsibilities. This part got a laugh out of me. Otherwise, the analogy feels really stretched and at times feels straight up incorrect. For instance, I've never sat through a technical interview administered by non-technical staff. I've likewise never been quizzed on the history of computation. I agree that the programming interview in the US can be overly algo-and-whiteboard happy, but I think this critique is unfair and possibly even outdated (my most recent round of interviews involved more live coding, and less whiteboarding, than when I last interviewed 4 years ago)
- titanomachy 9y agoI've definitely had phone screens where the interviewer was non-technical and asked technical questions they didn't understand, and were just looking for form answers they could tick off. Even from Big 5 companies. But in-person technical interviews were always with currently practicing engineers.
- doktrin 9y agoYeah I wasn't taking phone screens into account. I'd edit my comment to clarify that I was thinking of in-person interviews, but the timeout has elapsed. I think I disregarded HR screens because the questions (IME, at least) are often so trivial the experience of the interviewer doesn't really matter. There have been a few times when I've disagreed with a screeners pre-defined answer, but none of those cases resulted in a rejection or a halt to the interview process.
- deleted 9y ago[deleted]
- pandaman 9y agoI had a technical phone screen done by an HR several times, or at least it felt like it was a completely clueless person. Once I could tell exactly why, when after he asked me what is complexity of binary search and I replied "O(log)" he asked what base? (for non-technical people reading: logarithms of every real base produce exactly the same O() result being different only by a constant factor).
- codedokode 9y agoThe article was fun to read but the job of an engineer cannot be compared to a job of a translator. And regarding "full-package" translators I think that web developers should be able to write both frontend and backend part of an application. It is not that difficult to learn. Programming is not something you can learn once and then repeat the same actions for the rest of your life.
- gregoriol 9y agoOne time, I got one of those questions: two columns, on the left names of some people, on the right names of some frameworks, please associate who created which framework I really should have left at that point: >1 hour lost there...
- luord 9y ago> Please stop saying trans-comps. Oh, I can only hope...
- Fej 9y agoI see folks around here constantly complaining about this issue (not incorrectly) but is anyone actually doing anything about it? I mean, we can whine all day and remind each other that it really does suck, but that does little to address the problem.
- lmilcin 9y agoI find this article one-sided and too exaggerated. In reality, the sad state is, in my opinion, confluence of the following forces: 1) HR people more often than not have barely any clue about the topic. They must, unfortunately, play this charade because if they knew the topic they wouldn't be working in HR. 2) The technical people who prepare the questions typically believe they are too busy to spend time thinking about the problem and instead decide to settle on any test. The assumption is that a good candidate will be able to navigate any kind of test better that a bad candidate. In view of the technical person, this is just a screening, the real purpose being to elliminate as many phonies as possible. 3) The candidates more often than not have highly exaggerated view of their abilities. Unfortunately, high demand means that the market reaches for lower and lower quality of "resource" leading to comical situations where a large portion of the workforce (especially in countries like India) is developing software by shuffling around keywords until the code compiles which entitles them to call themselves Senior Engineers. Real senior people have no problem finding a job to the frustration of others who find the situation "unfair" and the entire process "rigged". One more note on the process: while the cost of failed interview for candidate is quite low, the cost of making a mistake is very substantial for the company.