The author advocates questioning the interviewer directly, but he doesn't mention questioning anyone in his Netscape interview, only making mental notes of various red flags.
In practice, I think that's the way 'both way' interviews generally have to go - you don't interview your interviewer, but you do evaluate and judge your potential employer critically.
Personally, my attempts at interviewing an interviewer have served to inform my decision, but not at all due to the face-value of the responses as they're generally going to be hard if not impossible to validate.
>'Very rarely someone probes me to see if they would like to have me as their boss.'
I'd like to try that someday...
Who's the weakest person on your team? What do you mean to do about that? When's the last time you lied to someone here? How did you rationalize it? Are you on any medications? Do you cheat on your spouse? What are you most insecure about?
The type of questions I'd really like to know the answers to - the sort that you learn the answers to within the first few months of any new job aren't the sort that I'm likely to get answers to much less completely honest ones.
1. "During your most recent budget period, what influence did politics rather than the merits of budget requests have in distributing resources, and in what ways?"
2. "How heavily influenced by politics (or upper management) is the performance review process?"
3. "Has anybody recently been let go as the result of being ranked lowest on a performance review?"
4. "Are managers subject to performance improvement plans?"
5. "When was the last time your HR department found in favor of an employee over management or upper management when a dispute arose?"
There's a bias to these (if it isn't obvious). But experience informs me that answers to these questions offer a good insight into how the company really operates. If they are honest answers (they won't be, most of the time, if they're answered at all).
Politics is what happens in subjective situations where people are wrestling for resources. How many budget requests are absolutely objective and easy decisions to make? Truth be told, in a high functioning company, there shouldn't be many. But politics absolutely comes into play when you have the fuzzy.
Is Google+ a better product objectively than Buzz? I have no idea. How do you even make that decision when the project is in its infancy?
Consider John and Katy. Assume that Katy does her job, pushes her code and gets her shit done. John comes in, is a superstar gunslinger. He keeps an eye out for upper management beliefs, quickly prototypes them. Shows a bunch of flashy shit to them. YET, that is all they are. Flashy shit with rotten code. It is the job of the Katy to come and work and write good fucking code. However, both Katy and John are essential for a good organization. They should be ranked by completely different metrics depending on the needs of the organization at that time. In reality, you have managers who have a complex trade-off to make between the short term and long term. This is a situation ripe for jockeying. Politics definitely comes into the picture.
I haven't seen an organization where a power structure doesn't exist. It always does.
Existential question of the day: If the answers are almost all lies or omissions, what's the point of asking the questions? To get good at spotting the rare honest answer among the PR? And how do you know what's a lie and what isn't? There's no way to verify anything they're telling you unless you know somebody working there.
That's a good summary of my view of the entire interview process, actually, from both sides. The exception would be technical questions, of course--but even those are only marginally more useful at determining anything more than whether the candidate can answer specific questions under specific circumstances, neither of which may actually ever arise during the course of employment.
Unfortunately, this sort of thing is a soft skill and doing it well requires a lot of expertise. It's comparable to being a good interviewer, which is also a rarity.
You can't just ask hard, probing questions baldly and expect to get accurate answers. More so, you can't expect to do that and expect it to not affect your interviewer's appraisal of you as well. You need to build up a rapport first and then you need to ask some leading questions that give your interviewer the opportunity to reveal some perhaps unsavory truths about their workplace. Granted, it might be hard to generate a rapport, or they might be too wary to tell you anything of substance or anything negative about the company, but that alone provides a lot of information regardless. If you have a hard time connecting with interviewers then maybe culture fit would be a problem. And if they won't open up about problems then that might be a sign of a dysfunctional corporate environment that discourages honesty and openness.
I think a better way to ask your first question would be:
"What would you say separates the strongest and the weakest members of your team?"
It allows you to get a sense of what they value in the team without needing to make them get defensive over staff they probably worked hard to acquire.
> "What would you say separates the strongest and the weakest members of your team?"
It's easy to reply to this phrasing with a canned answer and very little though. "Experience, skill, and a positive attitude." If someone gave this answer to you and you're the candidate asking the question it is basically 0 information.
I think the better way to ask this question is to ask
"Has anyone been recently let go and why? Has anyone been let go or put on a performance improvement plan for not being a good enough engineer? What are specific reasons why you think they were maybe not good enough? What is your policy when programmers make big mistakes?"
I'm not sure I would ask these questions, but I still think it's a better form of phrasing. You want to know what they think makes a bad engineer.
Hmm...I think if you ask those questions, they might not get the best impression of you -- it would seem like you were getting ready to be a bad programmer.
This is a very interesting exchange because it illustrates the difficulty of forming a question that the company can't turn to their advantage. For example:
> Has anyone been let go or put on a performance improvement plan for not being a good enough engineer?
Few people are put on PiPs for not being 'good enough' at engineering; most PiPs are about people not doing what the company demanded, no matter how unreasonable, which is very different.
But the company could respond to your question with 'sure, we clear-out the deadwood every six months!' because in their view those people weren't 'good enough'
> But the company could respond to your question with 'sure, we clear-out the deadwood every six months!' because in their view those people weren't 'good enough'
And that's the kind of answer that would be really interesting to hear.
> It's easy to reply to this phrasing with a canned answer and very little though. "Experience, skill, and a positive attitude." If someone gave this answer to you and you're the candidate asking the question it is basically 0 information.
Although it doesn't say much about the team, I'd say it provides some information on management and the level of transparency vs image management you can expect on the job.
Aren't they pretty limited in what they reveal about employees who are fired for PIPed, even if anonymized (which may not mean much for a small group anyway)?
I know you think it might come across antagonistic in an interview, but I wouldn't be offended if you came in and asked us these:
> Who's the weakest person on your team?
The newest hire to our company. It's not a total ordering though, every person on the team has weaknesses.
> What do you mean to do about that?
Make sure to put people on things that they're good at is the first thing! Don't put someone on something where they're not set up to have the ability to achieve success. My main job is to figure out what's getting in your way and attack that directly so you can just focus on being successful. If there's doubt about whether someone would be successful here then we'd rather pass on a candidate.
> When's the last time you lied to someone here? How did you rationalize it?
Never. It destroys any credibly you have to lie. That's one of the biggest red flags I could think of. I'd encourage anyone encountering a boss that lies to quit.
>Are you on any medications? Do you cheat on your spouse?
No. No.
> What are you most insecure about?
I used to be insecure about my ability to obtain sales from customers, but after having to do it over past 3 months and focusing on the basics I've become much better and we're now on a great track on the sales side of the company. Be aggressive about going after your weaknesses!
All of my answers are honest and I'd encourage you to hear about the experiences of other people on the team. I'd also encourage you to reach out to anyone who has worked with me in the past through any backchannels you have- that will give you the most unfiltered picture.
Asking if someone is on medication is not only unethical, I'm pretty sure it isn't legal either. Do you want to also know their sexual orientation, religion and who they voted for?
It's completely unethical, but I don't think the candidate has any legal requirements to not discriminate against the employer based on protected classes at all.
Sometimes. The potential employee is not always in a privileged position. I think with most new grads this is the case (some with significant relevant experience are excepted).
If I were interviewing a new grad or someone that didn't have a recommendation (basically someone I didn't have any context for) and they asked me to solve a technical problem, I don't think I would do it. I would not want to waste what little time we had allotted trying to solve that.
If we did want to make a good technical match I think it would be great to sit down and work on a low hanging fruit bug together.
This is why I hate those services that have an automated pre-screen process. The ones where you visit a specific URL and after reading the questions you record a 30 second video with your answer.
The massive hole there is that I don't get to interview anyone the company to see if I feel like its a good fit. I'm sure its saves them time but it wastes mine.
I haven't even heard of such a thing. I've done a couple written Q&As, but those I think are fair, since I have time to prepare a thoughtful response and don't have to worry about communicating body language to a faceless camera at the same time.
To be honest, it sounds like a net lose -- it's a definite negative for a candidate, with perhaps not much benefit for the company (high noise, high false negatives due to the awkward environment).
My gut feeling is that I would immediately reject any company that asked me to do that, if I had the choice.
I agree with you. If you can't be bothered asking me the questions in person, I can't be bothered answering them. That's the social contract.
I've already written a cover letter that responds to the points in the ad; if they can't prescreen sufficiently using that then they need to work on their ad.
Did I ever mention that interview with a whizzo East Coast startup where the interviewer couldn't answer where the company was planning to be in five years time? It's one of those questions where they will squirm like eels, but you have to know, because you are committing your time and future earnings to them. Squirming is fine, but being struck dumb is not acceptable. The experience was epic, it ended with a greybeard apologizing for the HR lady.
That's pretty direct, I like it. I try to ask "what is the worst thing about X right now?" where X is the project/product/thing being worked on.
Caginess and dodginess in this answer is a flag. Of course, different interviewers will be more or less forthcoming and straight with you, but if the entire slate of interviewers hem and haw around the question, I take it as a bad sign.
An organization where people are afraid to be frank and call a spade a spade is hiding a lot of systemic problems.
Right vs. wrong isn't what he's concerned about, I think.
Every company/organization/person should have a long term strategy. That way you can weigh potential actions to see if they are moving you toward or away from your goal. If you don't have that goal, or it isn't well communicated, everyone scrambles to optimize for different things, which frequently leads to people pulling against each other.
It's totally acceptable to update the long term goal as you go along, but it's very helpful to always keep one in focus.
I think that's becoming an increasingly popular opinion, but I really don't buy into it. If you have one year of runway, certainly you should have a one year plan, but I like to see something longer term as well.
This is a really relevant piece, if I'm interviewing you I'm going to wonder if you're not asking any questions about the company. I get that its hard to ask challenging questions in a situation where you want to get hired, but you will need to ask challenging questions when you don't want to get fired too, and if you can do that you are more valuable than someone who can't.
That bit about everyone focused on the stock price also really resonated. Back in the late 90's "everyone" was a millionaire, at least after all their stock vested be that in 1, 4, and sometimes 5 years. Way more people than I expected couldn't really handle that. The most common failure mode I saw was that suddenly the person would do no productive work at all, and instead start shopping airplane or yacht catalogs, or talking about where the best islands to buy were with their co-workers. I once pointed out to a person that if they did no more work, then the company's value would go to zero and knowing the best islands would be a useless fact to know. But I had grown up in Las Vegas (well spent my teen years there) and that was a town that taught people that money is fleeting in a very brutal and efficient way.
If you're the fifth person I've spoken to that day, any questions I have about the company have most likely already been asked and answered. Would it comfort you or worry you to find out I'm asking questions I already know the answer to just for the sake of appearance? Or is there something else at work here I'm not getting?
Actually, it would be very interesting to know whether different people gave different answers when asked the same questions (e.g., managers might give you the "official answer" but non-managers might give you a different perspective).
I've never interviewed anyone, but also, if they don't ask me any questions about the company then I'm gonna think they simply don't care and they applied for the role "just for a job".
- Is your job worth caring about? Let's be honest, not everyone is working on putting people on Mars or pushing the boundaries of machine learning, etc. A lot of programming jobs are just spitting out code for a paycheck.
When I was a tad younger, with less experience under my belt, and fewer choices in employers, I interviewed at many a job where I was expected to act like I'm deeply enthusiastic about jobs of little import to anyone and technically amounted to not much more than flailing my arms at a keyboard for 8 hours a day. That expectation is ridiculous.
The mudane, boring jobs need to be done. Hire people who are capable and willing.
This is a job, not a church.
- One thing I've experienced are the grueling full-day interview process that certain companies are a fan of (one such company rhymes with Blamazon). Literally 7-8 hours straight of interviewing, even your lunch hour is yet another interview. I don't think I've ever had intelligent questions by the end of those. The questions I did have were answered by interviewers before you, and at this point I've been thinking about manhole cover sizes, jelly bean estimations, families crossing bridges, and regurgitating CLRS algorithms solutions for so long I can't possibly come up with anything more.
Full-day cycles are grueling, and to expect candidates to be chipper and operating at 100% (or even 80%) is unrealistic.
What I do is write down ahead of time 10ish questions, then ask each one of 2-3 interviewers. That will usually lead to one or two follow up questions, and that's about enough. Yes, all-day interviews are grueling, but with preparation I view the question-asking phase as a break.
I think what happens is different companies (and dev teams, actually) have different personalities. A type A team/company will look for type A programmers. If you end up with a personality match, it doesn't guarantee you the job but it does probably help a ton.
Well, define "care" and "just for a job." My view is that it very rarely happens that a candidate has sufficient information to know whether the job he's applying for is one he can "care" about as more than just a method of obtaining a paycheck. In fact, I submit that such information isn't possible to obtain, outside fringe cases (e.g. knowing people on the inside already), without actually working at a place for a time.
I always do this, but I play it subtle. My primary test of your ability as a manager is your hiring process, because if you get hiring right then all other problems are solvable. The question I am always asking myself is: do I want to work with the worst person who can pass this interview?
I interviewed for a dev job a good many years ago. I hadn't heard of the company at the time (they were pretty small so there was no reason that I should have) so I did a lot of research. I remember that their financials were looking decidedly bumpy, but almost always in the black.
I asked about this at the interview. The lady interviewing me looked offended that I would ask about their financial situation as it was "not really something [I] should be worrying about".
I didn't get the job, and their feedback was that they wanted a dev, not an accountant.
Not assessing the financial situation of small employers pretty much has always lead to them going bankrupt in my limited experience. And employers unwilling to give any indications are the ones that leave paychecks un-funded when they do (that was an SOs employer).
I think one reason for this (not asking enough questions) is that usually early on your career, you don't really have that many options or you are in a situation where you need to get your bills paid with any means necessary.
I have really never (yet) been in a situation where I would have really had enough options to say no to any company offering a job after an interview. In those cases, your full focus is getting them interested - not really about knowing what kind of extra activities they do or what they are planning to be in say 5 or 10 years.
> It turns out, the majority of the people don’t do this. They simply put on their best face, answer every question and try to sell themselves. Some ask questions everyone should ask, such as the financial situation of the company. Very rarely someone probes me to see if they would like to have me as their boss.
It's funny. Lots of companies are going to increasingly great lengths to filter candidates based on inane tests that supposedly measure technical competence, but many if not most of them do little to filter candidates based on their apparent interest in the job opportunity as a whole.
Obviously, there are reasons candidates shy away from asking "tough" questions other than "I don't really care", but startups in particular should be wary of candidates who don't demonstrate a certain level of curiosity beyond the day-to-day technical rigmarole.
Put simply, look to hire people who understand that interviews go both ways.
One question I always ask my interviewers is "What is the best thing about working here?". You can tell a lot by their immediate response and whether their face lights up with excitement. One answer I will never forget is a developer responding with "We have a Dyson hand dryer".
An equally interesting, and perhaps more useful, question I always follow that with is "What's the worst thing about workign here"... The cop out answer is usually 'it's a big company so you get some politics and inefficiencies'.. I suppose a good follow up would be; "how does the company intend to change this going forward?" or even "how does it compare to other places you've worked"
It depends on your priorities. Do you just need someone to come and fill a spot or would you prefer someone that's actually a good mutual fit for the role?
Huh I remember 2 interviews that I was sure I am never ever going to work at the company :-) At one well-known-company interviewer literally treated me like garbage from the very first minute (including waiting for the scheduled meeting in the building corridor), I didn't even try to do say anything then. Another one started pretty well, but then I saw the team (super demotivated) and they asked me to do some shady test-stuff (HTTP referer header spoofing), but the nail to the coffin was the manager telling me that I have to disregard notice time and instantly jump ships for them, because they won't wait for me ;-) So yeah, the interview works both ways, there were jobs (like my current one) that I felt that the fit is strong and the final negotiation effects are not so important.
One aspect of "selling the candidates" that can be overlooked is the tech interview. There's a big opportunity to demonstrate your own/your team's technical excellence as a selling point.
What this is not, is skewering someone on "j=j++ in a loop" trick questions, or dryly sacrificing them on the algorithmic altar. Programming is supposed to be interesting, so it should be interesting to dive into fundamentals, language issues, library specifics or whatever, and keep drilling to the edge of the candidate's knowledge, and beyond.
The hope is, the good candidates get grilled a little, and walk out thinking "I could learn something here."
Yeah, 'cause language issues and library specifics are far more interesting than dry algorithms.
This seems bass-ackwards. Library specifics, and to a certain degree language issues, are exceedingly amenable to recourse to documentation. An understanding of algorithms, less so.
I don't mean to knock algo questions, especially not complexity and data structures.
I do think language and library fundamentals get overlooked, for the very reasons you mention: yes you can google pass-by-value and consult docs about a TreeSet ... but the good programmers don't, they already know when/how/why and don't forget it after a year of doing something else.
For sufficiently fundamental fundamentals, I'd agree. I'd certainly include pass-by-value vs. -reference vs. -name in that. I strongly dispute the notion that good programmers don't consult library docs. Library surface area is huge, particularly in batteries-included languages. One should know well the areas they use, but there will be plenty outside that, especially if they're moving between many languages.
I guess I've interviewed over a hundred candidates over the years. I always end with: is there anything you'd like to ask me? I can't recall a single meaningful conversation that ensued as a result.
I always interview the company interviewing me. The closer I've mimicked Peter Gibbons from Office Space the quicker the job offer arrived, provided I passed their tech tests.
The way interviews are conducted, mostly, you are left with a little time at the end. Interviewer will ask you to solve a problem, write code for it. Either the time is just enough for you to solve it, or if you finish too fast, there will be a next question thrown at you.In either case, not enough to have a meaningful short conversation followed by a question, which is sad.
It's funny that this article states that it originally came from the IndexTank blog, and the creator of IndexTank just responded to an AskHN questions a few hours ago.
My answer was, "I don't know; I would look it up in a book. Is this really relevant for an architect position?" I got the offer anyway and turned it down.
I think these technical interview questions are a silly way to evaluate developers. You almost never have to write low-level sort routines because you just call them in runtime libraries. But it's harder to evaluate the more important ability to modularize code and manage complexity.
In my opinion, it's a somewhat misleading question (or the answer is creative to the point of stretching definitions).
In-order traversal is pretty easy without a stack, if every node keeps track of its parent.
1. go down left branches until you get to a leaf.
2. visit leaf, and go up.
3a. if, in going up, you were at a left child, visit this node, then go right. loop to 1.
3b. if, in going up, you were at a right child, go up again. loop to 3.
3c. if you can't go up, you're done.
The trick comes from not really storing the parent pointer at each node, but instead doing trickery with xor-ing various addresses together so that you can store 3 pointers in the space of 2 (plus possibly an extra bit).
Of course, if you do so, you've constructed something that's not exactly a binary tree, and can only be traversed in certain fashions where you'll always have the necessary information to xor.
I like this idea but usually interviewers leave me with such little time that it would be unreasonable or impossible to do such a dive with the interviewer.
prematurely ending a stream is a problem for the current stream, and for the next stream as well, and thus is more desiderable to avoid corruption in bytes signaling an EOF than other bytes.
corrupting an EOF in something else is probably not as bad, and/or maybe a corruption 1->0 is more likely than a bit flip 0->1 (maybe when stored/transmitted as 1==higher voltage) and thus
are less likely to be corrupted into a EOF, if 11111111 is the least likely state for a byte to be in.
Also, not one of these bytes is a printable ASCII character, which might thus possibly be/have been much less frequent in data streams, and thus further reducing the likelihood the probability of such a corruption happening.
While a nifty idea, corruption of this sort is so rare and so unbounded (that is, there's no reason to believe it'll strike in your incoming data, it could well strike at the CPU instructions itself or whoknows) that there's not much you can do about it from inside the code. It's all but impossible to deal with corruption rates on the order of 1 in 10^18 (or better! properly functioning hardware is obscenely reliable at doing what it was designed to do [1]) instructions on properly functioning hardware, and all but impossible to deal with failing instructions at a much higher rate on nonfunctioning hardware, except to replace it with functioning hardware.
[1]: If anyone wants to pop up with complaints about that statement, remember that properly functioning hardware is also doing a lot of things very quickly, so it has a lot of chances to fail. ECC RAM is important, for instance, because something that only happens every few billion accesses may still happen several times a day. But this is still an absolutely obscene degree of reliability. Most disciplines would laugh at worrying about something at that rate of occurrence... they wouldn't even be able to detect it.
EOF is returned by functions that can return a valid character. So this rules out all the values in 0x00-0xFF (0 would have been a nice choice for EOF but how do you read nul bytes?). -1 is the logical solution (note that getchar returns an int so -1 != 0xFF).
In practice, I think that's the way 'both way' interviews generally have to go - you don't interview your interviewer, but you do evaluate and judge your potential employer critically.
Personally, my attempts at interviewing an interviewer have served to inform my decision, but not at all due to the face-value of the responses as they're generally going to be hard if not impossible to validate.
>'Very rarely someone probes me to see if they would like to have me as their boss.'
I'd like to try that someday...
Who's the weakest person on your team? What do you mean to do about that? When's the last time you lied to someone here? How did you rationalize it? Are you on any medications? Do you cheat on your spouse? What are you most insecure about?
The type of questions I'd really like to know the answers to - the sort that you learn the answers to within the first few months of any new job aren't the sort that I'm likely to get answers to much less completely honest ones.