This sounds very unethical and dishonest. It's the equivalent of a company interviewing a candidate they have zero intention of hiring, ever. Why waste people's time?
edit: not sure why I'm being downvoted. Am I wrong? How would you feel if you spent time preparing for an interview, did the interview and then found out the company didn't intend to hire you in the first place?
> This article makes me sad. Interviewing in our industry is so broken.
Yet:
> It's the equivalent of a company interviewing a candidate they have zero intention of hiring, ever.
If the company has one position to fill, and if they ever interview/contact more than one person for filling that position all the people who they contacted other than the person who got the job has wasted time, right?
In short, companies have only themselves to blame for this (sad) situation.
No, this is more like the company interviewing people when there are -- and will be -- no positions to fill. It's like a hiring manager going, "man, I really need some practice interviewing people, I should go post some jobs on job sites!"
(I've known many engineers who wing things at work rather than spend the time to research a correct solution, and not just in software.)
That's not been my experience. I've seen a strong correlation.
> show their willingness to do whatever they are told
I don't think it's the same thing. I've told many of the people I've worked for that what they asked me to do was a waste of their resources. One told me "do it 'cuz I'm the boss and I say so" to which I replied "at the salary you're paying me, I feel obliged to tell you that what you're asking will never work". :-)
Nevertheless, if you know upfront that at a job interview you will be asked certain questions, and you choose to go to the job interview, it seems bizarre to not come prepared. Why bother?
Like said, might be culture or maybe I have been lucky.
In my country (I haven't lived there for a while so might've changed but I don't think so) and my company we were not so salary obsessed, so 'at the salary you pay me' is a phrase used never in our office of few 100 colleagues. If you make 5 or 9 figures a year; if the boss tells me 'do it cuz i'm the boss' I'm not doing it if it's a stupid idea and I expect that from my colleagues even if I outrank them technically.
So still thinking it's culture as well; here you cannot fire people easily; you have to make a dossier (with obvious mistakes/flaws etc) and go to a judge and then pay them a few months. So there needs to be much more of a trust relation than master/slave relation imho. Note that we only needed that twice when the employees where watching/downloading pr0n all day. One was a junior designer and the other a phone support employee for our cms.
Edit: btw, i'm not saying I like that system per-se; in some countries (like Spain) it goes too far and you won't hire people because you can't fire them, but in NL I had no actively sabotaging people (you can't fire me so I do just enough); quite the opposite, while in Spain I meet too many of them.
None of this should be construed as a master/slave relationship.
For an analogy, if I go to McDonald's I am not interested in the opinions of the cashier, I just want to pay the money and get the burger. If I'm going to an expensive restaurant, I'm interested in the opinions of the waiter about what to order - that's part of what I'm paying for.
Ahem, Walter writes programing language compilers for industrial use. I strongly suspect that algo prep will make them better at their job if he was involved in the hiring :-)
It's not like one can look some detail up when he doesn't remember the detail was even there. Good software programmer needs a large working set of such details to sensibly function in a professional setting.
For another example, nobody knows every detail in the C++ Standard. But a professional is expected to know how to look up a detail in the Standard as required. That doesn't mean he doesn't understand the language.
Maybe you never need to look anything up. But I'm not that kind of person, and don't know anyone that is.
It's not like that. I do need to check various things, and I daily run `man whatever' (I'm a sysadmin in large part). But even though I often don't remember what was the switch for e.g. `grep' or `find' or `awk', I wouldn't "bomb the question" about that. I would just substitute a sensibly sounding switch, explaining that I'm doing so (and why) and what the switch was supposed to do.
The same stands for algorithms, data structures, or program architecture (in other large part I'm a system programmer). I don't remember how AVL trees do inserts and deletes (frankly, I never learned that properly). I don't remember exactly how inserts and deletes work in B-trees. I never implemented my own hash table. But I still wouldn't "bomb the question" about any of those, because I understand how they work, and the details either can be worked out pretty quickly, or most often are not important for a particular question (unless, of course, the question was "how to insert an element into AVL tree"; then I can at least give high-level answer before calling for data structures handbook for lower-level work).
Heck, I don't even remember most of the cryptographic details. Every time I need to explain RSA or ElGamal encryption algorithms or Feistel net, I need to derive the formulas (I typically don't have any reference handy).
>>. Make a list of companies that I would apply to and sort them from most interesting to no-way-in-hell-i-am-working-here order
This is easy to do if you're in the valley/NY. Outside of the valley, people often don't know many companies besides G and F. Making such a list is a valuable exercise, but quite hard for many people, simply because of lack of knowledge and credible sources. It'd be useful to mention something like Wealthfront list here.
>>. spend a weak reviewing typical algo/data structure questions
There are SO many resources online, that it's very easy to get lost in the search of what's typical, especially if one hasn't interviewed in a few years. It'd be useful to mention to follow some introductory book/resource here.
>> . For the companies that I absolutely want to work for, I review every single glassdoor review and write down the interview questions. Remember, most companies have question banks and most interviewers have favorite questions which results in same questions being asked over an over again. You want to exploit that
For companies with shorter history, this is doable. For companies with longer history of this kind of interviewing, browsing through Glassdoor is very similar to dumpster diving. It's doable, but it's super easy to get discouraged quickly. Not to mention very often people paste questions very vaguely e.g. "got asked a Graphs question", or they paste code which is a nightmare to follow, even if you trust that it's correct.
In other words, note that this phase can take a lot of time to do well.
>>. Then to get over my interviewing jitters, I interview at a few companies where I would absolutely not work at. This results in no pressure interview practise and you can literally laugh at their asinine interview questions and walk out
Again, how does one get interviews at even those companies where they don't want to work at? Getting interviews is as much of a problem, as clearing them. Added to that, there is always this anxiety about rejecting those offers, because there is no guarantee of getting thru the ones you want to work at.
Additionally, when picking practice companies, it's important to pick ones that have a process with similar intensity as your favorite ones. That knowledge is often not mainstream.
>>. Finally, for the companies i actually want to work at, I try my best to get rid of phone screen. This is usually accomplished by dazzling them with my decent size github profile, contributing some fixes to their OSS project or finding someone who already works there that is in my alumni network .
Internal referral is definitely the best way. But majority of people don't have internal warm referrals at most places. Additionally, unless your technical reputation precedes you, most good companies are unlikely to give you a free pass on phone screens. It's extremely rare to have a dazzling Github profile enough to skip a phone screen.
>> Then when you finally arrive for the interview, you have real world interview practise, they are already impressed with your github profile/references and biased toward you versus some random joe off the street and you have made sure you have a pretty high probability of getting a question that you have already seen or is similar to a question you already know.
This again, assumes that everyone in the panel knows about your preceding reputation. And that one doesn't mess up even a single interview.
Overall - please don't get me wrong - this is great advice and much better than getting frustrated without it. What I want to point out, that the inherent fragility of the entire process is so high, that one should be careful pinning one's confidence on any particular strategy. The only thing in your hand, as a candidate, is to prepare and prepare well.
. Make a list of companies that I would apply to and sort them from most interesting to no-way-in-hell-i-am-working-here order
. spend a weak reviewing typical algo/data structure questions
. For the companies that I absolutely want to work for, I review every single glassdoor review and write down the interview questions. Remember, most companies have question banks and most interviewers have favorite questions which results in same questions being asked over an over again. You want to exploit that
. Then to get over my interviewing jitters, I interview at a few companies where I would absolutely not work at. This results in no pressure interview practise and you can literally laugh at their asinine interview questions and walk out
. Finally, for the companies i actually want to work at, I try my best to get rid of phone screen. This is usually accomplished by dazzling them with my decent size github profile, contributing some fixes to their OSS project or finding someone who already works there that is in my alumni network
. Then when you finally arrive for the interview, you have real world interview practise, they are already impressed with your github profile/references and biased toward you versus some random joe off the street and you have made sure you have a pretty high probability of getting a question that you have already seen or is similar to a question you already know.
This technique has helped me get Jobs at top 5 employers in the valley along with a few startups. The reason I am posting this here is to demonstrate how broken, unfair and easy to game this whole process is