As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected. If this is dodging a bullet, then the entire junior field is a WW1 trench, at least where I am. Why would a company hire someone who gets 9/10 on the behavioral portion when they have a dozen other 10/10 candidates? Of course when the interviewer asks me to use "any language", I'll assume they want Python or Java or C++ or Rust, not Bash or ALGOL 68. Stepping out of line would just be performatively asking them to reject me.
If the candidate reads that this may be the case, asks for, obviously, that reason, and the interviewer confirms that they mean "any", then it's a red flag for that interviewer, at least, as a co-worker, if they go on to get upset over your choice, unless it's something where you're obviously taking the piss, like Brainfuck (the later suggestion of assembly probably counts as this, but at that point the interviewer[s] had already failed the interviewee's test of them, so, whatever)
But yes, if you're desperate for a job you should indeed just ignore any red flags and do your best to fit the perfect-cog mold and do whatever emotional labor is required to seem the way you think they want you to be, and take whatever abuse they offer with a smile. That's true.
Also, we can't know what exactly was said, so maybe miscommunication could be partly to blame. Like, "Are you sure I can use any language? (Are you really so gracious as to give me this option?)" vs. "Are you sure I can use any language? (Can I use something you definitely don't know?)"
I think the confusing part to me is why a rational candidate would assume it'd be a good signal to use an esoteric language to solve a problem in the first place. Like my understanding is that J would be a pretty inappropriate choice if you were trying to demonstrate your D/S knowledge, which is typically what that part of the interview is meant to be for. Apart from the round of applause on HN they'd receive later for being so very clever, what's the actual benefit for the candidate for using Prolog or J?
If I need to drive a screw I'll first grab a screwdriver. If that's not okay I suppose I could use a knife. A monkey wrench would not be among the first tools I reach for.
This is not what you see in practice. Trying to hire, the view is very much different, in my experience. Every candidate has strengths and flaws, it's much more of a... constraint problem!
The idea that there even exists a perfect candidate is one of the biggest issues with hiring practices in tech these days.
I, for one, would be extremely impressed by a candidate breaking out J or Prolog for a constraint problem. But I'm also not a typical hiring manager for sure.
When I did interviews, I used to ask for “any imperative language”. Most people chose C or Java, some chose e.g. Python and the best solutions looked very different from the C/Java ones. I did not deduct points for either; a good solution is a good solution.
I once had a candidate that chose Oberon, because it was the only language they felt comfortable with (by their own account). They fell through on the interview for other reasons, but this seriously made me consider to what degree they had any programming experience at all outside a few select school assignments.
Independent of that, if someone came with a solution in a constraint solver, my next question would be (as it usually was, regardless of approach) “and what is the runtime complexity of your solution?” and I'd be impressed if they had any nonobvious thoughts about that!
This is just conflict avoidance and naivety. After a while you start to realize that there's a whole world of people just like on HN and *we hire people too*. No matter what you do, youll end up in the place you deserve. If you try to be sneaky, you will end up working for people who are either easily fooled or see right through how to exploit you. If you let your nerd shine you'll end up with people who love your nerdiness.
I mean, I'm hoping for that too. But it also feels like this only applies as long as there's a balance of likeminded people who are already in the industry vs. the people looking to get a job. For someone like me, without a real network, meeting a person like the kind you mention is extremely unlikely. Even then, most of these people are looking for more qualified candidates, since there's an overabundance of juniors and seniority is a good predictor for being really passionate about their field. So, maybe I'll figure that out someday, but right now I just need a job, and what people in my cohort do is a way to try and get a job at all costs.
Of course, my team also writes SDKs in a bunch of different languages, so it makes sense. Even if that weren't the case though, I'd be stoked. To your point though, early in your career, I get your viewpoint. It's hard out there to get a foot in the door and you have to seize opportunities.
But interviews are bidirectional. The company is deciding if they want me, and I’m deciding if I want them. If I chose to use Self or Forth as the whiteboard context for the conversation we’re having, it’s deliberately to make the interviewer think, and hopefully learn. If the experience of thinking differently about a problem (that they chose!) and learning something new is a negative signal to them, that’s fine —- it being a negative signal to them is a negative signal to me, and I don’t want to be there anyway! If they’re excited, and intrigued, and give “12 o’clock” feedback — well, that’s the team I want to work with. So I’ve helped us both accomplish our goals (making accurate assessments about fit), and aligned our metrics along the way.
I've solved interview questions with one line of Bash before and gotten an offer. The question was something like "count all the files in this folder with a name ending in X". The interviewer was happy I had a quick solution and they could move on to talking about something more interesting.
And a Python solution that avoids those problems is also quite simple and terse for the example you gave, and probably for most problems in the category.
I don't think the fundamental dynamics change by seniority, just that after some level there may simply be a smaller pool.
From the interviewers perspective, it makes sense to reject a candidate if they see any possibility it could be a flop. A bad hire is going to frustrate the team and look bad to the company, missing the best candidate is just going to result in hiring their next best pick.
> As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected.
I guess this is very context dependent but I can also see "bending to the interviewer's whims" backfiring if they see you're just trying to flatter them. I could see some interviewers valuing that you can explain your point if it's framed in a way that shows you are both observant and easy to work with. If it's framed as a more aggressive kind of pushback, yes that's going to get you rejected.
But yeah, I can also see that if you're willing to take any offer at any company as a junior just to get your feet into the industry most interviewers may not be specially smart and resisting is likely to go wrong.
So make sure you use those "do you have any questions" time to ask questions! What is it really like to work there. How much notice do you need to give before taking vacation? Do they really give pay raises? How often do they lay people off? What is the dress code? Do they let you take time for your kids school activities? And so on - these questions should be things that are important to you - find out.
In the best cases the interview is only about convincing you to take the offer - generally because someone who you worked with at a previous job said "hire this person" and they trust that person enough to not need any other interview. So keep your network open.
I feel like in practice, unless you're an established, senior professional in a high-paying, in-demand field with a network to rely on, this would go something like:
> What is it really like to work there. How much notice do you need to give before taking vacation? Do they really give pay raises? How often do they lay people off? What is the dress code? Do they let you take time for your kids school activities?
"Candidate ABC seems too demanding and picky, constantly inquiring about irrelevant specifics. They would be a bad fit for our company culture. I advise going with candidate XYZ instead."
I know applicants need the job more than they need you. However you still have options if you don't get this one - you should always be following several leads until you finally get a job. Odds are your other leads are not anywhere close to as advanced as this, but if you can wait a couple more months you have a chance.
That happens since people only apply to very well paying jobs. If you apply to shit enough jobs they wont be asking hard questions, and those who offer shit jobs will say "all the power lies with the employees, I have no power to make them stay or apply, I am social and nice to them and they still reject my job offer!".
Just give the companies what they want and they all will want you, it is that easy. If you try to give them something they don't care about, like a hiring manager giving you a smile and minimum wage, of course you will get rejected a lot. Give them what they ask for, not what you think they should want.
I started giving interviews again and im surprised how many people dont ask anything. I'm an IC, not a hiring manager, and only evaluating a specific thing, (technical assement) and still nothing really.
When I interview people I encourage them to ask any question they want and I make damned sure it doesn't reflect in my report to the higher-ups! Just imagine being in their shoes, you could be in the same position tomorrow!
Instead you insist we should solve a nieche problem with a ill suited tool, while inventing a costume solution when a standard solution exist.
Bringing the team up on Prolog and integrating it into your CI/CD system and finding some way to connect it with other services is often going to be a poor choice, even if in isolation it's the very best tool for the job. And that's the best case solution - more likely the tests will be limited and not automated, the code review will be rubber stamp because only the author knows the language, and the code and deploy process will be a black box that everyone is afraid to touch once the author moves on.
Obviously in an interview none of the code should make it into production, but being openly pragmatic is still a good idea. And if you use an obscure language, you'd better have better than usual communication skills to concisely explain how the code works for someone who hasn't used that language before. I've seen it done well but it's difficult.
A company's interview process tells you a lot about how the company thinks and operates. This was was surely a dumpster fire.
Because you're unemployed and need to work to get some money.
Do you think you're a super intelligent person when you couldn't even figure that out?
What if the interviewers decided to ask the candidate about their language choice and trade-offs between different languages? Wouldn't that actually give them more signals into the skill of the engineer, rather than just blindly following their script?
That said, I interview in silicon valley and I'm a mixed race American. (extremely rare here) I think a lot of people just don't want me to pass the interview and will put up the highest bar they can. Mind you, I often still give optimal solutions to everything within good time constraints. But I've practiced 1000+ problems and done several hundred interviews.
Source: we am a hiring manager.
Personally, my experience has been that pre-covid, majority of interviewers were assessing your problem solving ability and if you can code the algorithm that you came up with. Getting the most optimal solution and fixing all edge cases for all problems in all interviews was not strictly necessary. But these days, even if you have the best solution coded up for 3 problems and missed one edge case in the 4th problem, you are not “good enough”. At one place, I was dinged for not thinking of the edge case before I wrote the program, even though I caught it while coding it up, in spite of having the write solution for the other 3 problems asked in the 2 coding rounds. It is a tough market, and probably tougher for you. Good luck mate.
You could improve that and still avoid any division or modulus by simply keeping track of when the "next fizz" and "next buzz" should occur. (And output "fizzbuzz" when those numbers are the same and you reach them.)
Weird experience. Didn't get that job (probably for the best tbf).
Hrm. So what you're saying is you've never actually taken or given this style of interview. Nor presumably ever worked at a company that did this interview. So if on the off-chance these interviews actually were a somewhat successful tool for filtering candidates you wouldn't actually know it?
That feels like a miss.
I've also never worked at a place that uses beatings to improve employee morale. So, I can't guarantee that beatings aren't an effective technique for doing so.
My deeply unpopular opinion is that "leet code style" interviews are actually pretty decent at avoiding false positives. Obviously some specific questions are gotcha trivia and many interviewers are bad no matter the question. But they're a reasonably accurate proxy. Their issue is false negatives.
End of the day the ONLY question an interview sets out to answer is "will this candidate be successful in this role". Interviews are strictly a proxy for "the real job". So arguments that "it's not reflective of the real job" are utterly irrelevant. It is not possible for ANY interview to fully reflect the real job. And you can't ask someone to quit a steady job to trial for 3 to 6 months to see if they're a good fit or not. So we're stuck with proxies.
I definitely think it's important for people who are hired to write code to in some form demonstrate that they are capable of writing code. That seems reasonable. But we can't expect candidates to write a big project for every place they apply. That's too much. And almost all candidates can't share code from their prior job. And solo GitHub side project are quite frankly not relevant for 99.99% of candidates. (And maybe more).
The one tried and trued method of hiring is to hire people you've worked with before who were good. This is not scalable.
Hiring is hard. Really really hard. I find that the vast majority of leet code complaints come from people who don't hire. If anyone ever cracks the puzzle of how to hire better they'll have a monumental competitive advantage. Many many have tried. So far none of have succeeded.
It's been a while since I had to hire outside your "people you've worked with before" bucket, but when I did, here are the two questions which worked best:
1. Tell me about a time you analysed a complex problem and came up with a solution.
2. Tell me something creative you did at work. Something you're proud of.
In my experience, a good candidate typically had excellent answers to those questions, because (1) a good candidate has had to do some real engineering at some point and they can tell you about it, and (2) a good candidate has done technical work which they're really proud of just in and of itself, and they want to tell you about it.
A technical question was useful in reducing false positives, but something a couple of steps above FizzBuzz should be fine for that. You just find out anything useful about a candidate by asking them to recreate some esoteric CS algorithm on the spot, unless you really need to select for people who can recreate esoteric CS algorithms on the spot.
In any real engineering situation I can solve 100% of these problems. That's because I can get a cup of coffee, read some papers, look in a textbook, go for a walk somewhere green and think hard about it... and yes, use tooling like a constraint solver. Or an LLM, which knows all these algorithms off by heart!
In an interview, I could solve 0% of these problems, because my brain just doesn't work that way. Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews.