Worst interview questions for software developers
fibery.io
fibery.io
Man, this question.
I was asked this question in an interview for a startup. I gave the regular answer that was expected of me. The interview went well, and at the end when the interviewer (who was the co-founder) asked if I had any questions, I turned this around on him: "where do you see [company x] in five years?"
He laughed and talked about finding product-market fit and getting a certain amount of funding, and having so many employees, and that kind of thing. In other words, the things you're expected to say in that position. I was impressed, and took the position when it was eventually offered to me.
18 months later, the company was on fire, most of the staff were laid off, the product I had been working on was shelved, and the company pivoted to a completely different product. I put in my notice just before that co-founder left the company completely, and eventually took a salaried position in a different industry, and moved across the country.
So, we both just said the right things, but had absolutely no fucking idea where we'd be in even two years. If either of us had any idea, we wouldn't have told the other person anyway. Questions like this have no answer, but a trivially correct response, and so are meaningless wastes of time.
If this role can’t help you get to your actual goals, chances are you’ll be looking to leave sooner than later and you most likely wont be as invested.
So just curious, in my last job the real answer would have been “it’s paying enough to let me fund things on the side to help me move towards my goals”. Is this a wrong answer? I imagine most places wouldn’t care for such a blunt, cynical answer, but it’s the truth.
Standing in front of a mirror.
I would never ask this in an interview, but if I was foolish enough to do so, I'd be fine with this answer.
[Sighs heavily and pulls a tarot deck from laptop case]
Unless the chance of getting the job is unaffected by the answer, and it doesn't sound like it is, there is a right answer to the question.
> Questions like this have no answer
Is “Retired” ever a good answer to that, even if it’s true?
If an engineering candidate's last few positions have all been about a 1-year vest, that's definitely going to be on my mind. I'd prefer to build a coherent, highly-effective development team who can see us through the whole lifecycles of this and successive projects -- not what might as well be fly-by-night gig contractors, tossing less-aligned check-off sprint deliverables over the wall.
I don't currently have a standard way to ask about this, and would play it by ear. Maybe their answer is that there was something about recent positions that they didn't like, or maybe they've been doing early startups, or maybe they were junior but just now hitting their stride as experienced and know what they want and how to perform, or maybe they give what seems like a dishonest answer, or maybe they're only looking for particular kind of short-term transactional engagements (which we might need).
Pay - Almost always, wages don't keep up with your progression, and never with the market.
Progression - Not just promotions, but being given the interesting work to run with. Once someone sees you as junior, it's easier to go somewhere else to be treated with a bit more gravitas.
Morale - Quite a lot of tech leadership is terrible. Various problems make people sad.
Skill - They might actually be terrible / or skilled but terrible at actually finishing anything.
I'm in the UK and spent many years as a contractor. It was never a case of not caring, or not wanting a long term home, and since most of the work and platforms were similar org to org, not understanding longer term consequences of decisions doesn't entirly apply.
Mostly, the negativity just writes off ambitious people. Though it might make sense given your org, like others, might just have the same reward problems.
Or the person has unreasonable expectations. On top of that, they are bad at selecting a job that will make them happy. In any case, I would not hire then either. Maybe if I just had some boring app that needed some maintenance I would hire them, but that is not what I do.
I'm in the UK. My summary of the British market is most devs are earning $50,000 - $100,000, with a few tier 2 and even less tier 3 companies, that don't actually offer SV level RSUs.
Basically there's not a lot of spots to "guess right".
Historically there's a large contractor market that's way more lucrative net than anything excep tier 3, of which you can probably count on your fingers.
Personally, I try to build better orgs to keep these folks happy, but each to their own. :)
I'm not sure that's entirely fair to say. If a company makes a few bad hires, are they necessarily bad at selecting candidates that will make them happy? Or is it also that there are other factors, like lack of availability of first-choice candidates, possibly an inexperienced hiring manager, maybe pressure from C-suites to hire a friend of theirs regardless of qualifications, and perhaps the regrettable, but unavoidable, truth that a bad hire is more than likely going to misrepresent themselves and social engineer their way into an offer?
Personally, I think it's a little unfair to make the assumption that someone who's switched around a handful of times and/or gives "morale" as a reason for leaving is bad at picking jobs that will make them happy, but I'm just some guy on the internet- I don't really know anything about anything.
If the answer comes back as mostly pay/opportunity: I get it; that's a real problem in a lot of places and it causes a lot of ambitious juniors to change companies frequently; no concern.
On the flip side, if you are entry level (< 3 years of experience), I will give you a pass if you can answer the question reasonably. We all know that the best way to get a salary bump is to get a new job and early on, it is more ok than later on in your career.
Typically I don't ask about the overall trend, but ask a bit about each of their last few jobs including their reason for leaving each. (This works regardless of whether they've had many or few jobs.)
Then you can decide whether you think there's a worrying trend (e.g. talking disparagingly about every single one of their many < 1- year jobs) or generally reasonable reasons for moving on.
4. Why do you change jobs so often (so rarely)?
How does that matter? If I am a match for the company
in terms of qualifications and personal qualities, how
will my job history and reflection help? I changed jobs
every year or so. Is that “often” or “rarely”? What’s
wrong with changing jobs frequently?
Several of the questions in the article are very good questions to ask. Their purpose isn't for the candidate to give some canned response, like the article states. Their purpose is to help the candidate shine by asking questions that can be answered with examples from the candidate's background. If the candidate can't give solid answers that's not an issue with the questions.
- VCs merged us with a Chinese acquisition and sent our work overseas
- Manager ignored my memos for 5 years and then said "you have no new ideas" to my face in a review
- Sales team demanded an emergency prototype and then let a competitor steal the contract
- Company pivoted into a different tech stack overnight
- Google rewrote our code in a weekend and kicked us out of Android
- Owner wouldn't install health benefits (+$5K) but hired his daughter for the summer for busywork
- Company abandoned the market and went into Facebook games
There's nothing much to lose by that point.
Interviews are here to determine if the place is a good fit, on both sides.
Some things are just damn too easy to spot without even trying, and this one of them. Have a great story to explain why you are actually wont leave when meeting first frustrating item at your work.
Also, everything is being evaluated, including how you react to uncomfortable questions. Parents snarky response would be a nogo on itself, regardless of subject.
If the guy reply "why do you care", then it s def suspicious and the short term guy might be so incompetent he s pushed away and doesnt last more than a year. I d take the guy who seem to survive 4 years most jobs to be safe.
It seems very inaccurate to judge that probability purely on past performance, which is likely to be just a handful of data points.
I was one of those, but I don't think that there's many.
I remember talking to a manager of a startup we were working with, and he told me that the average stay of an engineer was 18 months, and that they plan for that.
I bounced like that, for my first three jobs, but stuck at my fourth, for nearly 27 years.
Of course, the only reason you'd ask such a question in the interview is that you have already decided you don't want the job. But the response can still be illuminating/entertaining. :)
Would probably end the interview right then and there but so worth it to see their reaction.
Quant finance companies expect employees to work 60-80 hours per week.
But then again, they pay 400-500K USD to 22 year old new grads.
10 years of experience in Cpp, Java, Javascript, Python, SQL, the last 5 of which as a lead (aka designing the data model and optimizing slow parts of the code base through better ds and algo implementations).
Only catch is I won't show up physically in NY or Philly or Chicago, etc.
It makes sense: they value people doing high-quality work and avoiding mistakes. Everybody there was also clearly very productive—it was one of my first experiences that convinced me that long hours are actively counterproductive.
I understand other firms in the space (like Citadel) have pretty different cultures, so it's not going to be true for the entire field.
A good response is "there s no hour limit: as long as there s work and the client isnt satisfied, we work. I think it's important to sleep a bit between work day sto stay coherent, otherwise as long as I can".
Doesnt matter true or not :D
"Work is variable. If we are on a super tight deadline with real implications, then people should put in extra hours if they can. Like, if we need to deliver for a major client, let's just do that.
And then other times, you can back off and work at a sustainable pace. It really depends on what makes sense in the situation"
This answer may not please everyone but I think it would resonate with reasonable people. It's worked well for me.
I'm 43 years old, been programming all of my life, and have a Master degree. I've never seen a person do concentrated work or study for more than 6 hours a day. I've met plenty of people who claimed to do double. But they were either lying to me or to themselves.
If you think people can do 50 hours per week of highly concentrated work, you still have a lot to learn. Once you understand developers have around 0 to 6 hours of productive work in a day, you can start to optimize it.
Best of luck to you!
I had a similar situation interviewing with one of Musk’s companies a while back. Who would want to work 80 hour weeks to make a 40 hour a week salary? The answer should be no one. You did great.
They were filtering out people who were not willing to work 50 hours a week
You were filtering out companies who expected over 40 hours of work a week.
The only complaint I have is they should have put hour requirements it in the job posting so you both filtered each other out before it got to the interview stage.
More like 30. But I'm not expecting perfect one.
Am I wrong to think this seems at least somewhat reasonable? Like obviously it's annoying to explain yourself, but it takes time to on-board someone and for them to become productive and it seems reasonable to want someone to stay on long enough for that at least. This naturally applies less to those super engineers you barely need to train and have obvious experienced, but that's probably not the normal case.
This is what most of those questions on the list have in common: both sides of the table know that the answer will be contrived BS. They are a waste of everyone's time.
I know personal counterexamples where someone verged on job-hopping who became a great relatively long-term employee. And I've also known people who had a single example of clear not-meeting-of-the-minds. But, in general, if there's a consistent pattern, no reason to believe you'll be different.
I don't begrudge people for having good reasons to justify their job switches (e.g., wanted a manager role, and was told none would be forthcoming in the future), but e.g. "I got bored doing React and I wanted try Vue on the MEAN stack" does not bode well for the projects left in the lurch when he gets bored at my workplace.
I 100% agree lack of fit can absolutely be a reason to leave in < 6 months. One or two of these wouldn't be a concern, however I've seen resumes of people who have been in the industry 8 years, with the average stint being between 6-8 months and none over 2-years. I'll probably pass on this candidate, even if they otherwise look better than my next choice. Sure they might make "significant changes" in the 6 months they are here, but I'll almost certainly be better off in the long run with the person who sticks around long enough to have something resembling deep knowledge of our environment. If they have had a "lack of fit" with that many previous managers, I have no reason to believe I'll be the one they finally click with.
At 2nd job it took 5 months until the first commit. At my 3rd like 4 months.
Getting up to speed and not being a net time sink for the coworkers, like 8 months on my 2nd job even though I did kinda the same thing in my first job. About 5 months at my third job.
This also make me have a hard time understanding how job hoppers are valued at all.
But reading your comment I realize some companies work completely differently.
At my last job I had a small bugfix (a one liner but still a bug) committed on my first day, PRed and merged by the end of my second day. That job was the definition of hit the ground running but still. Damn.
It's easy to make a quick impact on greenfield or yellow field projects with little or no pre existing dependencies.
Hiring managers need to consider if the question is relevant, given the work to be done.
This is starting to sound a little cruel.
I once reviewed a resume where someone literally had a 30 year career when their longest stint was 14 months with several stints of 2-6 months each. Not exaggerating. I passed on the candidate myself, but the last 20 or so companies who hired him were willing to take their chances.
I also once interviewed someone else much more jr who looked like a serial job hopper. During the interview he had a very good explanation for it which eased my concerns literally 100%. This was like 4 years ago and he's still onboard.
At a previous employer we hired someone who had a 15 year job history where he left every employer like clockwork every 14-16 months. We hired him anyway because he had a specific skill we were looking for.
And, yeah, sometimes people with a string of bad luck will begrudgingly grind out a couple years somewhere they'd prefer not to be to better help their future career prospects. It's REALLY not the worst thing in the world.
And that! That is the problem to deal with.
Or just don't hire the bastard. Your choice.
I have asked this question in the past, and will continue to do so. I used to be more lenient with short term stint candidates. It never paid off, so I’m a lot more strict about it now. I have not once experienced the highly competent short stint non-contractor developer that HN would have me believe exists in such frequently that’d make this an unreliable signal.
I can’t realistically envisage an employee so valuable and productive that anything less than a 12 month stint wouldn’t leave a taste in my mouth, and for good reason. Not many people would be earning their keep for a fair portion of that. And I would’ve burned a lot of time learning how to work with them. At the end of it you’ve ended up with a loss of what little institutional knowledge they had, and a bunch of code written by someone without the proven ability to build maintainable software that’s only learned by being burned and learning the hard way.
I'm pretty sure that question is illegal. I do know that asking if someone is married, is illegal (in my state). We got lots of CYA training from HR, telling us to not ask these questions.
But I have the luxury of having the means to do that.
"I was in a relationship and it broke me, never again. I do not even like cats"
"I like being in a couple where we are both enthusiastic about our work. And I am sterile"
(or something more sensible - but honestly: lie, lie, lie)
Seems like a polite noncommittal refusal. And if, by some miracle, they have a legitimate reason to want to talk about that topic, then they get a chance to clarify.
If you don't want to answer, you can try pushing back gently and see if they get the hint. Maybe something like "I would prefer not to answer personal questions but I'm happy to answer any questions about my work experience and professional history"
It places you in an awkward position of course. But it can't really harm your chances at that point. Your interviewer will either realize they are offside with the question and drop it and it won't really affect their perception of you, or they will insist you answer a question they shouldn't be asking and you probably shouldn't work for them anyways
I was shocked to get an offer from them. I turned it down, as from my perspective, it probably spoke volumes of likely cultural issues with the company.
A previous boss of mine genuinely preferred hiring people with children, simply because they "feel more dependable".
Personally, I do not believe that kids vs. no kids, single vs. married, makes a difference in work performance. Any changes attributed to family status can be equally attributed to age and maturity.
It makes a difference at some place which might require late hours, weekends, or on call.
It also makes a difference for companies that want to absolutely abuse their employees.
Our HR was run by our General Counsel, so they tended to be pretty strict about the language they used, and they called it "illegal."
I think asking questions about sexuality and/or disability may fall into the same bucket.
Thanks for the clarification.
* If I'm going to be working with/for these people I want it to be a good fit. Honesty increases the chance of that, and reduces the chance I'm going through the whole job-hunting process again in the near future.
* Interviews can be a great opportunity to assess the current expectations of others in the industry, which is really helpful for staying current. This isn't always true of course, but enough of my interviews are of a pretty technical nature that it generally is.
* If the interviewer asks probing enough questions I can often learn something new about myself by seeing what (honest) answers I arrive at.
They're also fun; interesting opportunities to meet new people. It helps that I've got a good track record of getting the roles I apply for, but I'm not sure whether I enjoy them because I'm usually successful or whether I'm usually successful because I enjoy them.
Either way, whilst not all of those questions are appropriate I'll still answer them honestly. And to me, the worst interview questions are leetcode and algorithms (unless they directly reflect the nature of the work expected of course). I have a general background awareness of such stuff, but you'd be better off checking my search engine skills to make sure I can find them if I ever need them.
This is important, IMHO. So many companies set a tone of dishonesty and playing-to-the-metrics, starting from the interviews themselves. Which is absolutely not what you want from an engineering organization.
One of the most refreshing things about being a principal engineer at a multinational tech company was interviewing engineering candidates in China. They came across as exceedingly honest about what they're looking for, how they see the company, etc. (I also often find candor from experienced US candidates, especially once they read me as valuing and respecting that, but it didn't often seem the immediate default. I think they're often braced for Leetcode hazing, class shibboleths, corporate theatre, etc.)
https://duckduckgo.com/?q=cheating+chinese+student&t=newext&...
Also, I wouldn't know what to make of all the search hits I might read, especially since presumably there's cultural context I don't understand.
If you work with engineers from China, I suspect you'll notice many favorable qualities. Maybe including an implicit "No Jerks policy" (in American tech company terms).
You'll also notice that they're all distinct individuals (in American terms), and though it might be human to prejudge groups/labels of others, that's not fair to individuals, and we strive to be better than that.
I think this is a huge no-no to ask in the US, since a company can't discriminate in hiring on the basis of family/children, and this is sounding too close to that. (It's about ideals like fairness, and also about company liability.)
When I'm an interviewee, I don't read too much into early startups doing things like asking that question, since startups are still learning lots of things. But if someone is doing this in a big established company, there might be a disconnect from conventional HR practices there, and who knows what other surprises are in store.
“Imagine you are on an island with your peoples…. How do you protect your population?”
Then this interview kind of went weirder further along…
“Some predators are entering your island and rape your women. What do you do?”
Well: not joining the company making up these weird questions ;)
I guess this “island question” was somehow picked up by the engineer watching too many hiring talks on YouTube and I think the island question was remotely connected to some person doing these questions at Dropbox (besides the rape stuff of course)
Of these, I've only been asked questions 5-9 back circa 1990 when I was just starting out and the "where do you see yourself in 5 years" and "what are your strengths/weaknesses" were ubiquitous. Something must have happened in HR world in the 2000's because interviewers stopped asking these questions even thought I was still hiring for dev positions so maybe a memo went out or possibly the internet was blowing up. By the 2010's I was 20+ years into my career and at that point your CV speaks for itself and they just want to know if you are going to be behaviorally difficult person. Interviewing very senior people is a much more difficile proposition.
When I was 20 (cusp of 21) and hiring for internships my mentor told me the answer to "where do you want to be" should be "in your seat" but I my mentor was so old he didn't understand the concept of HR people giving the first interview lolololol.
I actually saw a job application recently asking to confirm that you haven’t used any nicotine products in 6months in order to be hired. This was very strange as it was a 100% remote job so maybe it was HR/copy paste but the wording was bizarre . They made it clear that it was about nicotine and not just tobacco and explicitly called out things like gums or patches.
I did not continue the application. I assume now it was some useless virtue signaling related to young people and vapes or something. I’m not even sure they’d seriously test people, but it’s still ridiculous that according to what was written you could be denied employment or lose your job because you had a cigarette outside the bar last weekend or have been using nicotine gum to quit smoking
10 - Fermi problems. Good to get an indication of a candidate's problem solving skills.
9,8,7,6 - The candidates's motivation, weaknesses, strengths, plans. What's wrong with that? Evidently, you have to modulate the answers somewhat, but the extent to which you do that well is indicative of your understanding of the job requirements, the competition, etc. Perfectly legitimate.
5 - Best candidate. Again, this is a fine question - it allows you to highlight your understanding of the job, and your fit, and your accomplishments, and so on.
4,2 - If you've had unusually short tenures at prior jobs, why? Again, perfectly legitimate question. There might be some reason pertaining to the prior company, or there might be a character trait with the candidate. Insofar as training a candidate incurs some fixed costs, it is legitimate to aim to find out whether they'll stay around for a while.
1,3 - "bad habits", family. Agreed, irrelevant.
But 2/10 is a pretty bad hit ratio for a top 10 list.
But agreed on the rest. OP thinks they are bad, when really they are poorly worded, and they would be better off taking a moment to think what kind of information the interviewer is trying to get at with their questions. Heck if the job involves interfacing with other people the ability to do this can even be an important signal on if the candidate is right for the job. A lot of people are really bad at asking what they are looking for.
So they don't fall in. Next question.
Well, you could ask them to solve a problem that might realistically come up on the job.
There are a lot of professions that require problem solving, but they don't use Fermi problems.
Interviewees for car mechanic or doctor positions don't get asked how many piano tuners there are in Chicago. They get asked questions like "A 2021 Prius is emitting a high-pitched whine and exhibiting poor acceleration from stop lights. What is the likely cause?" or "This patient has a blood pressure of foo/bar, a creatinine level of blah and has this other symptom blugh. What would be your next step?" If you gave them a Fermi problem they'd probably walk out the door.
Many of these "interview questions" are basically just cargo cult stuff. The company has heard that Microsoft or one of the FAANGs has used some weird-assed question at some point, and thinks that if only they do the same, they'll be the next FAANG. It's a tacit admission that the hiring manager actually has no clue as to how to evaluate a candidate based on metrics that are actually relevant to the job.
Software is a weird industry where you have to quiz every applicant to make sure they know how to program even though they've been the industry for years, and we seem to get it wildly wrong anyway.
Coincidentally, although I've been offered jobs after doing these kind of interviews and technical tests, I've only ever accepted jobs that are on the basis of "we know you, just come along" and I guess I now don't have any trust in a full interview process.
There are nearly as many poseurs in mechanics as there are in programming, though. I think reputable shops grill candidates pretty hard. And not with Fermi questions.
I prefer to actually think about what I want and devise a problem set to work through with the last candidates. You know, "here's a simple TCP server with a minor bug in the handler for one packet. Let's fix it". Real job: here's a 100k LoC server. Add a report/packet type/etc or fix a bug...
Uses up my time as well as theirs, but shows me a lot about how they work as well as what they'll be like to deal with.
Generally, if a person can talk in detail about a topic, they know the topic.
But it requires you also know the topic.
It's actually a very straightforward equation, but way too often people just trial-and-error or make an assumption out of nowhere, instead of plugging in the disk-size, user-count and growth rate multiplied with size per user.
Same goes for understanding what a computer is capable of, instead of throwing in some complex kubernetes cluster because requests are processing slow. If you actually knew the order of magnitude of queries per second that is normal, you would question the application first before questioning the number of servers.
Then maybe ask that question instead?
But even this question is not relevant to the vast majority of programming jobs. It's more of a devops question.
Because those are different jobs. A good software engineer must be able to reason around all sort of real world problems. Software does not exist in a vacuum.
Calculating the number of pencils used by Chicago's public school system in one year or whatever is pointless, though. I could "solve" this problem, or at least make a reasonable estimate, I suppose, but I'm a web developer. Wouldn't you get a better indication of my problem solving skills if you asked me about a problem related to web development?
A question like "what are some problems you ran into on previous projects and how did you solve them?" will be one I can answer instantly as well as give you a better indication of the competence I have doing the job you actually want to hire me for.
This might be a worse version of the "greatest weaknesses" question. It sounds like it could get closer to protected status that you consciously don't go anywhere near in an interview context.
Also, some of my favorite and most capable colleagues might answer honestly, about some random quirk, and not only is it problematic to have asked, but -- if that quirk got transmitted through some corporate telephone game, like an interviewer wrote down the answer -- someone elsewhere in the org will probably get a garbled impression (from "drinks too much coffee" or whatever), and then maybe bureaucracy breaks down during the offer process for the person you most should've hired, and they get alienated and go somewhere else.
To say this rubbed me the wrong way is an understatement. I knew immediately that I would loathe reporting to someone so egotistical, so it went downhill from there. I'm just never going humor to someone who starts a conversation with a pissing contest.
Solid general piece of advice there. If the best answer is a lie, it’s not a good question.
Much better to do the invitation style questions. "Who is going to help me clean this up?" "What is left to your homework?", etc.
With the obvious major caveat of things being very tailored to the specific kid and situation, of course.
The question was "What is the worst challenge you've faced, and how did you deal with it or overcome it?" and on me asking if it should be work related, "it doesn't have to be work related".
I can't remember whether the wording was exactly "hardest challenge" or "worst problem" or "most difficult challenge", but it used an absolute term (worst/hardest/most, not "a difficult challenge" or "a time in which you faced..."), and it was certainly very close to one of those.
I think that most people's hardest challenges in life are things like "my parents passed away" or "I came out as trans, and my parents disowned me, and I've had to come to terms with that" or "I had a divorce".. basically, interpersonal relationship experiences which really aren't very work relevant.
The use of "hardest" also makes it feel like you're lying if you go for something less serious, but work related.
I brought up a non-work-related rough time in my life from years ago, which still easily stood out as the most challenging time in my life, and then specifically asked again "this doesn't seem work relevant, should I choose a less serious work-related challenge?" and the interviewer asked me to continue with my non-work relevant one (i.e. asked me to relive some trauma).
It soured the experience massively for me, I had to try and disassociate some to avoid crying, and all in all it was the least comfortable I've ever felt in an interview. I can't imagine what signal that gave them.
That somehow also didn't disqualify me since I still got an offer, though I of course declined it.
Anyway, the company was osohq. I hope they don't ask this question anymore, but I guess prepare a story just in case if you do interview there.
It’s like how, in the US, if a stranger asks how you’re doing, you shouldn’t actually tell them how you’re doing. You should just say you’re doing fine, because they aren’t asking the question literally.
The oversaturated modern job market melted the brain of the HR departments to the point that they think it's a great privilege to work for them when they are just another company and you only want to earn a salary.
Without thinking I replied "Alive or dead?".
I followed this up with the logistics around solving the problem in each scenario. Most of the solutions involved "I know some very rural people who will take our money and help us solve this problem."
At no point did it occur to me that they might be speaking metaphorically. I did get the job though.
This is of course on top of discussing their recent projects and seeing how far they can drill down into them.
I do this to weed out people who are very suave at interviewing, but turn out to be not only incompetent at the position, but actively poison the org. These folks are rare, but they do exist and can cause lots of organizational harm. They are aggressively self-promoting people who don’t know what they’re doing, but can fake it convincingly for awhile somehow, and who work energetically for higher and higher positions.
Often CV and LinkedIn are way out of whack because of the level of creative nonsense they have gone through about their pasts to get a job. I don’t mean this in the “CV is marketing you” sense, I mean this more as “saying you were CTO when you were a junior QA person” sense.
Many short stints can mean they were found out within a few months/year of being hired.
An odd variation on this is talking about very important sounding positions that turn out to be their own one-person consulting company.
In the past 5 years I have seen three cases of this where they were hired (2 I did not interview, 1 I did and was a “no”). All three imploded rather spectacularly.
I have also seen good candidates with bizarre CV inconsistencies or several short stints in a row who explained it all very sensibly and turned out to be great.
This is why these aren’t CV screening red flags, but points of discussion.
9. Trying to understand persons motivation for the job. For culture fit, for position, etc. Not a'ways 'i love it and that's my sole interest in life' is a 'good' answer. Some companies/position are looking for cold professional approach, financial interest may be interpreted as less problematic and stable. Depends.
8, 7. To see how the candidate see himself, usually entry point for more questions and soft skills evaluation. Also gives you an idea what person in front of you sees as good and bad, and if he fits the manager/team. And people do tell their real weaknesses. Surprisingly, people tell A LOT on interviews.
6. Pretty obvious - direction of development, some want to grow to be in a managing positions, some interested in tech side only, position/company may provide support for this or no.
5. Also hate it, but used to see how motivated person is and again - how he sees his strengths.
4. Asked if person really jumps from job to job or, say, stayed in company 10 years. In first case - it's suspicious and question gives the chance for candidate to explain themselves. For people who worked in one place for a long time - let's see if we are the company that provides same benefits or not.
Last three is stupid and may be illegal.
But in general - questions are just entry points and a way to start a discussion about the things you wanna know. It's not stupid if you understand why do you ask it and not looking for just an answer.
Also his solutions for those who get this questions... Being passive aggressive rarely helps. You are in conversation with someone - speak, express your frustration, explain why. Facepalm, exhale and look deeply in the eye after being asked about why do you canned so many jobs - that's a great answer I guess, explains a lot, but just understand, that you are an asshole in this situation.
I learned to value good interviews. And I'm not afraid to stop and quit interviews that I don't like. If you don't like questions and don't want to participate, act like an adult - explain you are not interested and save time for both parties involved.
If you want to see how a developer really works, ask them to submit a patch, participate in a real code review and review their public facing code contributions.
I dislike your tools based "do it live" test unless you pre-configure their preferred tool chain end to end. Many devs are rote in their tools of choice while lost in anything else. That's ok.
Where do I see myself in 5 years: Not here.
How many peas in pod: Don't use Quicksort (stole that answer form Obama)
Why should I-- : I've traversed your red/black tree and found the jade monkey, I have proven that I'm worth more than the position pays therefore you will need to increase said position's compensation, and I'm very hungover. I did all of this while wicked hungover. Do you have a beer for me or can I leave now? I have a lot of dogs to count for my next interview.
I am reminded of how Daniel Stenberg (author of curl) interviewed with Mozilla, and mentioned it was several interviews taking place over several days. Obviously questions like these made up the bulk of the interviews, because they could not seriously have any doubts of his skill as a software developer.
Several interviews stretching over several days; accused serial killers have had to endure less before going to trial.
Are we talking about NTSC composite artifacts?
You should answer this question with your greatest weakness in the context of the interview. It's such a good opportunity! It's so awful feeling like an interview went great but stressing about something you didn't talk about - maybe your lack of experience or lack of degree. Whatever you're worried about that you didn't get to talk about. You get to actually talk about it and address it to the best of your ability.
It also looks great that you're talking about something real. Something you're nervous about. You are being honest and vulnerable.
It reflects incredibly well on you if you can be vulnerable and professional.
If I don't get the opportunity to answer a question like this in an interview, I'll use some of my question time (usually with the hiring manager) for it. Having the ability to anticipate and address a teammate's (interviewers) hard-to-discuss questions is such a strong, positive signal.
Interviewer tips: listen not just to the answer, but also how do they communicate, do they use deflective or passive language, ask them to elaborate a lot with lots of details (bullshitters are bad at this), let them do all the talking ("why? Tell me more" Or "and then what happened?" are all the additional prompts needed), take good notes
* tell me about a time you disagreed with someone senior to you. (After every prompt ask "How did you handle it" and "what were the results?")
* tell me about a time you failed
* tell me about a time you had too much to do and not enough time do it.
* tell me about a time you solved a problem in a way you were really proud of.
* tell me about a time you felt you were asked to do something that was outside your skillset or comfort zone.
Lots of alternative questions you could ask instead, but again the key is no right answers, and you'll get a lot more signal compared to most questions.
This could be a good question, when it's a high-value position of which a big part of it involves depending on the person's advice/judgment.
If they give what seems like a very honest and thoughtful assessment, that's a good sign.
But seems useless or counterproductive, if it comes off to them as just a nonsense ritual or trying to assert power. And if you don't alienate them, they might still give you a counterproductive sales answer, and that also then sets the tone for if you hire them and want honest assessments.
In 99% of cases, the real, honest answer is "I couldn't possibly know, because I don't know all the candidates for this job". Which makes it a very boring interview question.
The only time where that doesn't apply is a very, very tiny niche where you know all of the qualified people.
You could also see that as a prompt "pitch us why you're a good candidate", which also seems pointless, because pitching yourself is a big part of the interview already.
Open ended problem solving problems can be done well.
'Where are you in 5 years' is really helpful to understand aspirations aka 'I want to be a Senior Dev/Architect' vs. 'I want to go in to Product' etc..
He's heard of work/life balance and doesn't want to do work during unpaid hours.
Nobody hires a cashier asking "tell me how you've made cashiering an integral part of your whole life or we won't hire you".
It seems very narrow minded to think that newer technologies could be "read" by any classical understanding of the word. I mostly learn new tech by cloning github projects and tinkering with them; or pick some interesting subjects and follow whatever scattered pieces of documentation I could find. You're not going to catch any seasoned engineer reading Machine Learning for Dummies.
It would be a much more straightforward question if you just asked the candidates what they learned recently.
I estimate about 55,000?
Ferarri is 1300kg, needs 1300 liters, 1.3m^3 of air to be buoyant, and assuming square pingpong ball of 3cm, that be ballpark 46k. Add some extra for current, drag, mud
Then maybe you just not a good fit for the company, and it is actually a very good question for that company's interview, after all?
What is the most interesting project you have worked on recently? Doesn't have to be work related, but should be relevant to the job, e.g. programming, not gardening for a developer role. Why was it interesting? What were the biggest challenges on that project? How did you solve those?
Will show if people are passionate about something specific, and also gives a general measurement on what they consider challenging, and a first insight into their problem solving skills. If the person goes into detail, go along and ask more questions. Very helpful to figure out how a person works. This should hopefully be a low pressure "just talking" question to get started and help people to calm down a bit.
There's no need to lie or have a canned response, because tradeoffs are inherently between things which are both desirable.
Question 10 with a 'walk me through the thinking' reveals aptitude for modeling and dimensional analysis, but at a higher level, shows ability to break complex problems down into many simpler and easier to solve problems.
That is the essence of dev.
It shows thinking through and around the problem, identifying the first component to pull out, revealing key threads to other components, that together tell you if you're in the ballpark on modeling and analysis.
All dev is breaking problems down well. A thinking aloud response to 10 reveals a lot. The estimate itself (the Fermi part) isn't actually what matters.
Sure, often you just have to measure. But I'd much rather work with the person who can get an order-of-magnitude estimate from a 10 minute measure than the person who gets a reasonably accurate estimate but only after taking half a day to set up the experiment.
> All these riddles are aimed to reveal the person’s creative nature.
They aren't riddles, nor do they require creativity. Fermi questions exercise a basic skill: estimation.
Bread and butter.
This happened to me in my very first grown-up job interview.
"I don't want to ask you where you'd like to be in five years…
…
but where do you see yourself in five years?"
This blog post is pretty self congratulatory. We get it, employer bad -> employee good.
The fact of the matter is, they are investing in you. It often costs more to hire frequent replacements than one long-standing employee.
I’ve been places 9 months, 6 MONTHS, this question drives me up the walls. At the back of my head, I never once thought, “I don’t deserve to be asked this”.
#8 measures self-awareness. Many people can answer this question with "I know I could be much better at X and I am working on it" which is what it's about.
I've also seen people fail #8 in interviews for junior positions. They can't introspect. It sounds impossible but it happens.
Eg. if I guess NYC population is 10M, with every 100th household having a piano, I can guess there are 100k pianos in NYC. If each of them needs tuning once every two years, that's 50k tunes each year. That's roughly 1k tunes each week, which, if a tuner can do 2 a day (5 work days per week), is 100 tuners.
And then it'd be worth comparing to tuning of venue pianos which are tuned more frequently: let's say 10k venues with pianos requiring tuning every month, or 2k tunes a week. So another 200 tuners.
You can also talk about pattern of work instead of market demands (eg most tuners only get 1 tune a week, so we can multiply the number of tuners by 10), just to show off you are ignoring other variables knowingly.
Obviously, each of the guesses has a large error margin, and errors multiply, so you can be off by way more than a single order of magnitude.
But just coming up with things to include in your calculation, and not being scared of exploring such random situations with little data you know, signals some generic problem solving ability.
Eg for a better answer, I now know I need exact number of people and venues in NYC, I need to ask tuners how often are pianos tuned, get some data on how frequent are pianos in homes, how long does a tune take, etc.
While I think I am decent at these questions, and I do believe they signal a very generic problem solving ability, I agree they are terrible interview questions for most software engineering roles, since you rarely hire for such generic ability, and might even get more out of a more specific question/test..
It's like the Drake equation - it doesn't matter what factors you choose (you can always come up with more) or what values you assign them (you can't know what most of them would be anyway). It's meaningless as a whole. And also irrelevant to software development or most anything else; at best it would be only very loosely relevant to managing a piano tuning company.
I have no idea what those values are! I am still able to make guesses to show that I can figure out a bunch of variables that affect the final value. And since I am multiplying data that's off maybe even by few orders of magnitude, errors multiply as well: I am aware of how erroneous input data affects the results too.
Is it relevant to software development as a whole? It definitely is.
You've got to provision web workers for new service being developed: you can only (guess)timate number of expected users, you can guess how much CPU time each request will take, figure out cost per unit, look at bandwidth requirements, and make your pick. To improve on your guess, you actually go and measure request times (p50, p99), decide on the number of users you can sustain with your team cost effectively, measure network usage, etc.
Or you need to decide on what type of DB to use? Depending on access patterns (read heavy, write heavy, time series...), data size and scalability demands, team familiarity with different tech, you make a guess at what should work: you can only measure after you've got the system exposed to real, live load.
Now, I still think it's a bad interview question: people can be perfectly comfortable answering above questions, yet not see that they are in abstract exactly the same as the number of piano tuners in NYC. It tests for that generic and general ability to estimate anything, and to break down any problem.
Yet some people get flabbergasted (like you seem to do?), since they think too much about specifics of each of the numbers they use and how wrong they might be. Basically, they have a hard time of letting go of the inaccurracies :)
As such, it's a mixture of tests: supposedly only tests you problem breakdown skills, but in reality tests your confidence in using inaccurrate numbers or lack of problem domain knowledge to solve a problem.
Which makes it a bad interview question unless both of those is what you want to learn about someone.
It's similar to estimating novel work.
It shows that one can break a problem down into more manageable pieces. Being more manageable means you can get a better estimate by delving deeper.
The question is not about finding the right answer, but about employing the right methodology.
And if you've got next-in-the-chain taking estimates as hard boundaries or facts, you need to be explicit they are not, and hopefully teach them to be a bit more suspicious of everything.
Even then, it's ok if someone else takes your ballpark and runs with, as long as you are willing to take responsibility. If you are higher in job title, be explicit this is what you are asking them to do, and that you will take the responsibility! Invite them to improve upon it as they learn more, though!
Ability to BS and multiply, more or less. Feels like a waste of a question even for the one asking it!
> Yet some people get flabbergasted . . . since they think too much about specifics of each of the numbers they use and how wrong they might be. Basically, they have a hard time of letting go of the inaccuracies :)
Having a hard time letting go of inaccuracies seems justified if you're in a more technical profession. Too often there's good engineering reasons for not wanting to excuse loose reasoning with bad guesses. On the software dev side, there are also too many cases where those kinds of fudged numbers are inevitably used against us.
According to recruiter and many answer here it appears people are spending days at job throwing numbers to the wall.
Can anyone explain what these numbers with massive uncertainty are used for and why go tough all that effort if you still have to go back to sources and references to fix up the estimate anyway?
Are you sending this from 2010, OP?
edit: someone downvoted this -- i'd love to know why you think an inorder, preorder, and/or postorder implementation would help in an application that uses SQL to query a db for primary keys in a couple tables?