Job interviews go both ways (2011)
diegobasch.com
diegobasch.com
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.
"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.
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.
> 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'
And that's the kind of answer that would be really interesting to hear.
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.
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.
> 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.
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.
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.
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.
And it's just a pre-screen, right? It's not like you have to make your decision right there and then if you do well in it.
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.
Interviewing needs to be interactive because any decent job requires interaction.
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.
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.
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.
(although now it's been on HN interviewers will probably be better prepared)
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.
I don't want to work with people who don't care.
- 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.
Honest question, can you give some examples of good questions that the typical interviewer would be able to answer?
- What do you like / dislike most about working here? (I'd typically lead with like for obvious reasons).
- What surprised you the most after you started working here?
- Relevant questions you discovered when you did your homework on the company.
Maybe I've already gone through 5 other people today, and I'm exhausted, and I've already used up all my questions about the company.
This strikes me as yet-another-psychology-test-designed-by-non-psychologists.
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 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'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.
Why would I invest my time interviewing you only to turn around and tell you something that might make you decide not to work here.
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."
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 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.
As I got exposure it moved on to 1. Specific question on potential growth 2. Companies market position risks/challenges and their actions/plans
But I have not asked hard questions that a few have outlined here. Hopefully I don't have to :)
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.
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.
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
01111111 10111111 11011111 11101111 11110111 11111011 11111101 11111110
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.
[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.