As it is, I choose my interview battles carefully. One of my favorite questions I ask is whether my position is new (rare for my situation) or if I am replacing someone who left.
This very naturally opens up a conversation about expectations from both sides. If someone separated, why do the interviewers think it didn't work out? If this is a new position, how do they imagine the first year?
Suddenly you're talking about culture, performance and policies without having asked directly about any of those topics.
However, by no means am I saying ask for the sake of asking because I’ll read through that and will probably try to turn it into a conversation you’d be expected to participate in ;)
Very often it's the questions the interviewee asks in the interview that make my mind up on a hire/pass decision.
Tell me about your hiring process — how many rounds, how many interviewers? Is there anything special about your interview process I should know? Are coding interviews on a whiteboard or laptop? What resources do candidates have access to while coding? Assuming the process goes well, how long does your hiring process typically take? How long do candidates who are given offers have to decide on an offer?
are perfectly fine, because they're simple and objective, and can be immediately answered by the company (if they have their shit together on any meaningful level). But questions like:
What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively? What biases have you decided to accept in your hiring process? Which are you trying to change?
would be a red flag, because really now, it's not like employers have huge swaths of time available to holistically explain the raison d'être of their hiring process and how it got that way. If anything it's the exact opposite -- if they company is successful, then their people have almost no time at all to wax philosophic which each and every candidate about such topics.
So to ask questions of the latter sort strikes me as a bit obtuse.
A simple answer is something like, "We want to figure out whether a candidate can do the work we need them to do. We do that by giving candidates sample work problems which are streamlined versions of problems we've actually solved at the company in the past. People we hire are more likely to still be employed with us than they are at our competitors after a year. We know we don't hire enough women and URMs into technical roles, and we're instituting a rule that at least one woman or URM candidate needs to be interviewed for each open role."
Well, yeah, that's the thing - the answer is (or should be) so self-evident that one wonders if one wonders whether the question is really worth the bandwidth.
I am in favor of asking 'Are questions asked in the interview a true reflection of what I would be doing if I was hired.' If the answer is no, then you have more questions that revolve around 'how they evaluate best-fit'.
The tech interview process is broken and change requires challenging and questioning the status quo.
> What are you trying to figure out about a candidate in an interview? Why do you think your current process does that effectively?
Unless the interviewer is from HR they probably don't know (or care) much about the answers, and unless you're interviewing for a position in HR, knowing the answers won't tell you much about whether to take the position. So why ask at all?
Questions like these are analogous to bike-shedding - asking about what's most visible to you at that moment, rather than about what's important.
I don't think that hearing whoever happens to be interviewing me defend their interviewing process tells me much about whether to take the position.
-The person I'm replacing, why did they leave?
-How much overtime is done and is it paid? Are weekends required? Are people asked to volunteer for a weekend shift? Do you have "deployment days" where people have to stay until/past midnight not accounted anywhere?
-Who is going to be my manager/technical lead? Can I talk to them?
-Is this a full time position, or full time supplemental (ex: IBM) Oh, it's full time suplemental, is overtime paid? Do I have vacation days and health insurance?
-Can you show me the exact spot where I'll be sitting?
-Can I take two weeks to decide on the offer considering I have currently three more interviews in progress?
Interviewers should have no problems answering questions about their work culture unless it is unhealthy or broken.
I was once told I was egotistical after the interview (because of my probing questions) but was offered and accepted the job anyway - it was a admirable brand. Quickly found myself regretting. My questions were based around work culture (Is this a new position? Have many people have left recently? etc.)
Discovered the department was toxic, aggressive members with terrible traits. Structurally very secure from legal and HR so unlikely to change anything.
Thankfully was early in my career and left. Lesson? Take the time to thoroughly question the interviewer and reject any company that seems avoiding. Take the advice from this article.
Never had a bad role since.
They block iCloud, Messages.app, have some horrible resource-heavy anti-virus, and a ton of other restrictions on my machine that impair my ability to get my job done.
At least you get to use macOS at work, mad jealous!
Cue disappearance of frequent grumbling about “IT”, since worst they can do now is install McAfee, which is worked around by exclusions for devs (with absolutely everything thrown into exclusion folder!).
Shit actually gets done and “fuckin IT” is no longer a valid excuse for not delivering.
Am I the only person to call BS on this one? How this is likely going to be interpreted by an interviewer is "can I excuse my poorer skills/performance by capitalizing on my gender/race?", so you will get a politically correct answer like "diversity is among our core values and we promote it by giving preference to <...> among the candidates with equal skills and backgrounds" and will never hear from them again.
I mean, diversity is a legitimate value, but asking this during an interview when you are trying to advertise yourself as a valuable addition to the team, is a bit strange IMO.
The trouble is - once the company starts setting quotas and special rules for enforcing diversity, it attracts the type of people that focus on gaming those rules instead of bringing in added value and this quickly creates another form of toxicity.
In my opinion the ideal work environment is somewhere between those 2 extremes.
Can you tell me how you know this or what makes you think it is true? It sounds like a readily available stereotype.
A more recent example is how whiteboard programming questions during interviews turned out to be ineffective because it indicated how well a candidate rehearsed this type of questions, rather than their programming abilities.
- Reduces ability to catch errors. Linus: "given enough eyeballs, all bugs are shallow". But this does not work if everyone looks at things in the same way.
- Makes it easier for undesirable decision cascades to form: One or two people have an idea, and the other members in the group copy their decision, because they always agree. Smart well-weighted decisions are the product of disagreement.
- Stifles innovation. Do you really want your tech company to be all Stanford graduates? Where everyone knows the exact same algorithms, because they sat in the exact same classes, by the exact same professors for decades?
- Is inefficient in regards to Pareto optimality: It is impossible to hire someone that knows all. Hiring for diverse skill sets comes close. Hiring people with homogeneous skill sets is an expensive uphill battle, that relies on small random mutations.
- Reduces the motivation of your top performers. The really desirable job candidates don't always like working in a drone factory, where everybody dresses the same, there is no challenging of their ideas, and, for instance, women all have inferior roles.
This only covers one aspect of managing diversity though. Other than practising active diverse hiring though, some companies are very active in diverse communities which naturally leads to diverse hires.
I think it is absolutely an important thing to try to delve into, but yeah, maybe try to be strategic about it.
A very good metric to this (for me) is lines of code. Take where they say their product is (in terms of features etc) and then weigh that agains their LOC (if they're willing to give it to you)... If you get a sense that the LOC is far too much wrt the capability of the product (experience/intuition will give you a feel for this over time, as you start paying attention to the metric)... this will give you a good sense of how many late nights you'll be spending trying to fix some nasty bugs or contend with spaghettini instead of delivering real value.
We don't value LOC as a measure of productivity because it is a terrible metric to use. That doesn't change just because a person is on the developer rather than the manager side of things.
Anyway I'm not sure what else your 100K LOC is supposed to represent - that the app has a lot of responsibilities?
What I don’t understand though is this: why not just do the problem? People ask these kinds of questions to see how you solve problems and what it’s like to work with you. They ask the same question to every candidate so they can calibrate. They ask questions to known problems so they can see how you will handle unknown problems (ie the job).
How else do you expect them to interview you?
Because none of the work I'm interested in deals with CS trivia at that level, and it generally is a strong indicator that the company is engaged in one or more terrible practices like, e.g., incorrectly thinking Google's hiring process is generalizable or that CS trivia is the same as engineering. Or else it is looking for someone who doesn't know or care to think about the bigger picture and solve bigger problems than what they can pick out of a textbook (i.e. they're looking for a technician, not an engineer).
I'm not a fresh graduate looking for my first job in which I'll spend my day throwing code at an editor to implement someone else's designs because I lack the experience and wisdom to participate in the design process, nor am I ignorant and arrogant enough to believe a little understanding of DS&A is sufficient to cover all or even most of the important problems in engineering a product.
> They ask questions to known problems so they can see how you will handle unknown problems
That doesn't make any seunse. These kinds of problems test memorization and little else.
> How else do you expect them to interview you?
By asking intelligent questions having to do with problem solving and not running through the college level CS equivalent of basic arithmetic.
Also, at my company this serves as a jumping off point for other questions. Scaling, concurrency, networking etc. All great for seeing breadth of knowledge and problem solving/talking through a solution type skills which I think are relevant in day to day work.
"Will this be relevant to my daily responsibilities and, if so, in what exact context?"
"How many times per week is this algorithm re-implemented by your engineers to solve real problems?"
it may in fact be relevant, and then you better know it. but for 99.5% of dev positions, it's just a BS test. knowing the Big-O, cpu/mem trade-offs and applicable datasets for common algorithms is usually important but being able to re-implement them rarely is. the most important thing is knowing what the algos are and where they need to be utilized (binary search, bloom filters, nested sets, etc...). the most i do is give high-level descriptions of the algos' steps, if i know them.
it's valuable to have the interviewers describe early on what a typical day entails at the position you're applying for and what type of assignments are typical. you'll have much more leverage to have these types of conversations.
of course, this attitude ain't gonna fly for low-level coders working on kernels, compilers, graphics, etc.
So even if these questions aren't related to the day-to-day work programmers do at the company, it could give them a legal way to filter for intelligence.
I say that it could because I think they'd have to select the questions fairly carefully to ensure they're achieving the intended result, and then compare the success of the candidates hired via those questions vs. the success of those hired via work samples or different types of interview questions.
Probable thought process of interviewer:
* What a prick
* LOL we have 200 resumes on file for this position
* Dammit I'm going to have to interview more people
* When can I go back to being an actual engineer, the job I was hired for
My series of questions when I get the chance to talk to an engineer on the team I'm interviewing for is just this, "What's a normal day at work look like for you? Not a fire drill day or anything crazy. Just walk me through what you think of as your routine."
And once you can get that conversation going, you can pretty easily suss out the answer to very many questions in the article without coming across as even really asking questions, let alone seeming like a special snowflake.
Some questions can be more direct than others. But I think many of them can be figured out through a healthy conversation in the interview process.
If you can't engage someone in that kind of a conversation someone ought to be seeing some red flags.
Makes you sound better.
The interviewer should never worry about being asked ANY questions about their culture unless it is unhealthy or broken.
Most interviewers responded in the ten percent range. One notable exception was a place where they responded with "fifty percent" -- I can't imagine what it was like there.
Without other information, 50% may mean a lot of bad colleges or arrogant self-aggrandizing interviewer.
I asked this to my netflix interviewer, he just mumbled some incoherent answer about "netflix values" and didn't answer my question. He seemed to get angry when I reworded my question and asked him again.
Seems like they have no idea why they are following that process, just blindly copying "industry best practices" .
https://www.slideshare.net/reed2001/culture-1798664 (17 million + views)
I am on the fence about the second part of your question. On the one hand: If they are free to grill you about hypotheticals and process, why can't you do the same? On the other hand, should you really? It is a very cheeky ("courageous") question that would catch me off guard. "Who are you to question the very job interview we are currently having? How is this relevant to your prospective job? Current interview not up to par for you?".
What a strange company.
Also, the questions re: benefits etc. are more well-suited towards the recruiter you’re working with or HR; it is highly unlikely that the hiring manager knows enough about those things to answer your question effectively.
Everything else is pretty good, though I wouldn’t ask it at once (overwhelming and a negative social signal)
I usually ask, in no particular order: What do you do, how do you do it, how can I help you, can I remote.
Interviewing is a chore, I'm not going to invest my time in doing it unless I think I'll enjoy being there, which requires at least approving of what the company does.
(I would be a little less choosy if I didn't have a current job, but still probably don't want to write software I have strong moral objections too)
And usually it's just BS marketing fluff.
The only trouble is that the vast majority of companies can't be understood if you don't already know the business.
Three things I want to learn from a candidate:
- Does she/he feel responsible?
- Does she/he self reflect and learn or blame others?
- Can he/she solve problems on her/his own?
Any ideas on how to find out?
Some examples https://www.themuse.com/advice/30-behavioral-interview-quest...
Knowledge is power: Why are they hiring? https://codeformore.com/knowledge-power-hiring-new-developer...
I worked in a small company where I was the only programmer and had to figure everything on my own, plus search engines, IRC, StackOverFlow. Then an interviewer at Intel was mildly unsatisfied that I didn't ask about a test question that wasn't entirely clear. Also, one company where I worked very briefly considered question asked a sign of weakness.