When the interview was over I thought, "Is this how working with these guys is going to be?" If I ran into a problem and went to them for help, would they just stare at me, waiting for me to figure it out on my own?

They didn't extend an offer to me and, based on my performance in that interview, I can't say I blame them. I'm not sure I would have accepted if they had, however. That experience really left me with a bad taste in my mouth and a low impression of that company.

We as an industry really REALLY need to figure out a better way of conducting interviews.

The technical competence check is all retrospective, hearing them talk about prior projects and what the design and implementation process was like, how decisions were made, what the challenges were and how they were handled, any regrets/learnings. And most of that is just digging in far enough to confirm that the person was actually a first-class participant in it with a deep understanding, and not a bystander. Any whiteboard stuff would be "show us how the system worked" as a last-ditch check on basic communication skills.

This all requires that the interviewer be willing to interact deeply with the candidate. Our profession has a (well deserved, I think) reputation for having a high percentage of people who really don't like interacting with others on a peer level.

Is it likely that a large part of the problem is that we have people doing interviews who really shouldn't be? I mean, if your typical response to talking to another technical person is immediately to try to one-up them, then you're going to be a really shitty interviewer. And that's exactly the personality type I see being described over and over in these anecdotes.

The psychological reality behind all this is even worse.

The interviewer is not looking for new colleagues, he is looking to improve his own self-esteem and rank. The reward for rejecting a candidate is a feeling of superiority and an appearance of being irreplaceable.

The interviewer and the candidate have opposing goals, and the interviewer can randomly change the rules at any point.

But then I've always been interviewing for my own future colleagues/boss/reports. I guess the dynamics could be different if you're in a huge company and just generically interviewing for new cogs that might get slotted anywhere.

If the person is smarter than me even better! Instead of spending time teaching them maybe I can learn from them and get into their network so that if I ever need a job in the future they can help me out.

I can tell you, with quite substantial sample size from me directly and from people I deeply trust that every time we encountered an interview like this, we later found out that the company culture was really bad.

Those are not the kind of people you want to work with.

English has this expression too, except it's "The fish rots from the head". (Which, when you think about it, makes more sense.) What's your first language?

> I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.

It only later dawned to me that our industry has a non-trivial fraction of people for whom empathy is a foreign concept. They're not sociopaths, because those folks can at least feign empathy - we're talking about individuals who can't see themselves in another person's situation at all. On top of that, we don't really provide actual interview training to engineers either. Out of all the people I personally know in London, only one (1) has received formal interview training.

Is it any wonder that the interview gauntlet is such an awful experience for pretty much everyone?

Here's why https://blog.codinghorror.com/why-cant-programmers-program/

- Tell us about the approach you took with the take-home coding challenge. Why did you break up the functionality in the way that you did (modules/classes/functions)? What kinds of constraints or requirements would cause you to make a different call here?

- Tell us a debugging war story. What was the bug, how did you discover it and come to eventually understand the root cause? Any challenges with reproduction? What steps were taken to prevent it from happening again?

- Pick a feature of XXX programming language and explain how it contrasts with approaches taken in other languages. What do you like about it? It is more productive, efficient, safer, more explicit? What are the tradeoffs and how do you balance these? What kinds of projects would have you prioritizing using a language/ecosystem with this capability?

Someone incapable of writing a fizzbuzz program is not going to be able to bluff their way through an interview like this. Obviously you need to be committed to listening and exploring the space with the other person as opposed to flexing and looking for the "right" answer, but that's just part of the discipline of being a good interviewer and not a jackass.

Coding exercises entirely miss the point, because writing code is the easy part. The hard part about good software engineering is being able to rapidly acquire problem domain expertise and knowing which engineering design choices enable rapid, scalable, and maintainable development to solve the problem. That's why companies using code exercises to screen candidates are generally not worth the interviewee's time to work for - it indicates that the interviewers don't understand the problem domain, either, and (by extension) that company is mired in mediocrity.

I've had code exercise interviews. I'm quite happy that I have never had to work for one of the companies that used them. I have never given a code exercise interview, and I've been quite pleased with the candidates that have responded and worked with me.

Which is noble, I suppose. But clearly lots of people still felt that it was unfair and alienating; closer in spirit to a hazing than a good-faith evaluation.

I've found that the ability to receive and act on guidance with a certain degree of humility is a much better signal of someone's potential than how many algorithms they've memorised.

It takes a lot of practice to know what level of assistance to provide at what time. A coworker once showed me a technique of keeping a google doc with the problems, as well as a step-by-step of the solution and the times at which they should be at that step. It always seemed to work out well for the candidates, as even a poor candidate would finish the problem at like 55 minutes into a 60 min interview.

Even with that, getting a person to see what they should be doing next, without telling them explicitly, is definitely a skill you develop with practice. I think you're right in erring on the side of too much assistance. You get to see much more of how the candidate works if you can skip over the part where they are getting stuck on something.

Actually being able to take a hint and work with the interviewer is a strong signal that a candidate, while maybe not the best for the job, has growth potential.

"How would you pull in data from an arbitrarily long -- maybe never-ending -- source of data in Python?"

me : "What kind of data? What is it used for? How should it be represented afterwards?"

Silence on the other end , followed by "Well that's up to you."

I then fumble out a few ways to do it (verbally), to a recruiter that doesn't seem to understand anything that i'm saying -- he's probably reading a question from a script and pattern-matching what I say to the supposedly correct answer given to him in the same script.

Finally it ends with "Oh, that's interesting. ...We'll get back to you." , and the interviews that go this direction -- they never get back to you; you've already lost.

I'm not spouting gibberish, i've been at this for a long time; i'm just not spouting out whatever tech-jargon that their company supports and is needed to conform to his script, and quite honestly the person on the other end of the phone call seems to be universally under-equipped to judge anything remotely CS related.

It's a really weird/ephemeral/surreal experience. Imagine a surgeon being appointed to a position at a hospital because the secretary quizzed him on some flash cards (flash cards provided by Acme Sharp Scalpels), and the surgeon -- by chance -- prefers Acme Sharp Scalpels, and so mentions that brand. Instant hire according to the flash cards.

That's a lot like what it's like when a technically-accurate developer gets passed over for one that blithely mentions popular software packages (pandas/tensorflow/whatever is popular this week) without any real technical knowledge on how to achieve the goals wanted by the hiring party.

The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.

Is this a good question? If you want somebody with a lot of Python expertise, then knowing about generators is a good thing.

If I was interviewing a candidate, and they didn't know this, then I would just find a pleasant way to move on after a minute or two. If this is the only interviewing question, then that makes me happy, because this company has a flawed process, and is leaving some great talent for me to hire.

It's not a big deal if you didn't know this at the time. You might not have known what a generator was, and the person interviewing probably wasn't very good at interviewing people.

> The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.

That's funny...I've implemented more than my share of such things in a long career, and my first intuition for an answer to the question, as phrased, was to implement stream sampling. It never even occurred to me that the answer might be a syntactical feature of the language (and yes, I know what generators are).

According to you, I'd be so wrong that I'm a waste of time.

Do you see the problem yet? It isn't theoretical. I've hit this kind of situation with so many interviewers that I'm actually more nervous when I'm sitting across from someone who is clearly on their first or second job out of school. They're asking (unclear) questions in the "python syntax" category, and I'm thinking about the engineering consequences of consuming an endless stream of data...

This is a...youthful...industry, and a lot of junior people (with "senior" titles!) are out there doing interviews. It takes experience to become a good interviewer, and if you've never had that experience, you don't know what you don't know.

I don't think so, because you actually know about generators. If you were hiring for people who had a lot of Python experience, but didn't know about generators, that would be a bad sign. You would probably want to ask a some other questions, so you would have a more complete picture of what the candidate knows.

My main point is that the company's interview process is flawed.

Sure, but will the OP give me a chance to demonstrate, or simply flip the idiot bit as soon as I don't give the expected response? In the context of a phone interview, I probably wouldn't get anywhere near discussion of python generators in an answer to this question. I'd probably say something like:

"For an infinite stream, my main concern is system resources, which are never infinite...I'd want to use something like stream sampling to calculate the desired metrics, but it's hard to know the right solution without more information about the problem."

Far too many interviewers hear that as weasel-wording, and simply disengage. It's even worse when the interviewer thinks they're asking a clear question about python syntax. It takes a high level of self-awareness to know that you might be the problem when you're the interviewer.

An experienced interviewer might engage with that, but many folks don't have the patience to listen to an unexpected response, nor the respect for the candidate to give them the benefit of the doubt. As I said, this pattern isn't theoretical. I've been on the interviewer end of this kind of pattern many times before.

> My main point is that the company's interview process is flawed.

Agreed on this.

It surely matters if the data source is push or poll or something else, matters if it's a lot of data or a trickle, matters if you need all of it or if you can miss some (and how much), if the source buffers it or doesn't. I'd expect discussions about message busses, queueing, buffering (maybe ring buffers), data stores (maybe SQL or No-SQL), as well as concurrency or parallelism expecting the question could move to "and what if there was 1000x more data?". "Process stock market data" needs more than "read a temperature every minute".

Or at least for a candidate to ask about some of them and be told "this isn't so complicated", not "it's up to you". If it's only asking whether you can loop over a generator instead of trying to read all the data up front, the question could surely be more focused?

I still answered the question in my head on a whim, half-expecting it to be false, it's a really vague formulation. Sounds like the interviewer was randomly browsing language features and cutting and pasting random descriptions from whatever tutorial. Or maybe the company was using python generators in a really specific "data pulling" niche that the answer seemed extremely obvious to the technical team writing the questions and they forgot that outsiders are not wired to think of the same patterns.

I think that's only applicable if you are reading from a socket. Although I don't know too much about asyncio streams.py, so I'm not going to get a job at this company.

Wrong answer.

The heap data structure would be a right way to go about representing such data.

>>If you don't know this, then both people are going to wish that they had that half hour of their life back.

Same in your case now.

that describes 2/3rds of the 'codility' tests I've been given in a few scenarios (toptal used it to weed me out). The couple of jobs I've been in where I was explicitly barred from ever asking any clarifying questions, or talking to business/SME folks about the problem at hand... I left those pretty quickly. I guess it serves to weed out people who have some hard-wired dependency on talking to people to clarify requirements.

Looking back there's no way I would have fit in there, but damn did that interview screw me up for a while.

  > We as an industry really REALLY need to figure out a better way of conducting interviews.

if your an app dev: make me an app that does x, you have 60 min

if your a rails dev: make me a site that does y, you have 2hrs

if your a pdm: make me a spec and tickets for a system that does z

maybe i'm missing something but it shouldn't be too hard should it?

For example; "Make me a site that does x, you have 2 hours" Do I need to build the app in front of you? Problematic because how often does one build an entire web site in a couple of hours, while someone is standing over their shoulders scrutinizing every keystroke?

Do I take it home and do it? If so, how do I prove to you that I did the work?

Do you care what framework I use? Do you care if I use Open Source code?

What design should I use? Where do I get the site assets from?

If I'm building this site for you, are you paying me for that time?

Then there's the non-technical parts missing from an interview like that:

How does such an exercise tell you that I'm the kind of person you want to work with?

How does such an interview provide me an opportunity to ask you question? It tells me nothing about you or your company which is every bit as important as you finding out about me.

(I am hesitant to describe my idea, but WTH, I'm currently not in a position to act on it, and they say ideas are dime a dozen so...):

For those of you for whom English is not your first language, you surely know what TOEFL is: Test of English as a Foreign Language. The private company provides a test where they evaluate a person for proficiency on different sets of English skills: Reading, Writing, Speaking, general comprehension. At the end of the test they give you a score for each of those and then a general score.

Now, the nice thing about the TOEFL score is its reputation: When you are going to study into a University (from Oxford to Liverpool, from Harvard to Queensland), if you are not a native English speaker, the university asks you to take a TOEFL (or equivalent) and get a score higher than X. As long as you provide that score, the university won't ask any questions. They don't doubt your English proficiency skills.

I want to do something like that but for development: Sure, University thought you CS101, CS201, etc. But what companies are looking for are specific skills (similar to say, https://sijinjoseph.netlify.app/programmer-competency-matrix... or https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhC... ). These very concrete skills that can be concretely measured.

I want this becase I've been dealing with recruiting, interviewing and also being interviewed for most of my career. And in my experience setting up a "recruiting wheel" in a company or startup is very painful. Most developers don't know how to perform interviews. Or don't care (who has time for that?). As an Engineer manager, having to comb through 400 resumes a week is time consuming and unproductive.

So I imagine a scenario where, there is this proverbial "Full Stack Developer" certification authority which is independent, very reputable and unbiased: They won't tell me if X or Y developer will make it into my team. They will tell me how does the person score in "Algorithms/Data Structures" or "Micro Services development" or "Frontend development" and then I will choose whether I want to hire them or not (according to my current requirements). That way, I only have to do a culture-fit interview and that's it.

In the past I have dealt with "Sourcing Agencies" that try to do something like that: They do the 1st technical interview, and they say that there will be alignment to what I want. But that was not the case: They send me 2 candidates and get very surprised when I reject one and not the other. And I feel our objectives are not aligned, so everybody is frustrated. Moreover, I don't want to have to deal with hiring agencies. And paying 1 to 3 salary months is too fucking expensive.

Now, as a candidate/developer: I would love to have a "TOEFL" like certificate that I can show, with my proficiency. That way, I can "look for a job" passively. I don't have to be making countless of code interviews showing one time after another what I know. I only do it ONCE for an authoritative company, and everybody else can check my qualifications there.

Companies like Microsoft or TripleByte have tried to do something like that, but the problem is again that they do other things: Their interests clash. Why would I trust LinkedIn? That's why TOEFL monetization make sense: The candidate has to pay for it.

I am aware there are some certifications: Oracle whatever, Microsoft whatever, AWS whatever. But those are either too specific/niche (WebLogic Server 12c administration exam) or they are only a "badge" (AWS Cloud Engineer) that doesn't tell you that much.

There is opportunity here for disruption. And I know that the problems that I've faced are faced by countless of other CTOs/Technology Heads.

That is a big ask. There have been many attempts at CS-adjacent certifications, some of them government sponsored, but none of them find widespread use. The ones I've personally encountered were grossly out of date (e.g. a C++ assessment that didn't mention templates at all, in 2012), and weren't even mentioned during interviews by the company that demanded them.

It's not just a matter of trust, either. Our industry is incredibly conceptually diverse, despite the common current of abstract patterns that underlies everything. There is no specific or generic skill test that won't be out of date in a year, and forcing the required degree of standardization on our industry to make that possible would effectively destroy it.

In the mean time, the only organizations incentivized to keep their assessments up to date are the vendors themselves, who as you note, have conflicting interests. And at root, if you want to be even slightly more generic than a vendor certification, you are basically trying to test for intelligence and adaptability.

They should. My university had a minimum TOEFL score requirement. The number of grad students who passed that requirement, but then couldn't write a coherent English sentence to save their lives was still incredibly high.

One interesting thing about TOEFL is that it is, arguably, correct and complete. I.e when using the English language you use 100% of the skills the test measures, and the test measures all skills necessary to thrive in English. That's why you only need do it only once (every X years).

Engineering skills as defined by those matrices are so much more open ended that you'd need specific matrices tailored for different positions. E.g. a front end developer doesn't need to know what a linked list is. Then you end up moving away from the idea of ONE authoritative test.

Also worth noting that wherever I've seen it used, TOEFL is usually a mere checkbox to tick, and there are other, more thorough measures of skill involved.

First, there are wrong incentives at play, good guys currently don't need that as they mostly are employed and look for jobs passively. Good guys don't care about certificates and you want to certify good guys so your certificates mean something and can build trust. Weak guys will be spending money to cheat their way around just to get passing grade, which will cost money to prevent.

Then you have hiring managers that will not use this exam as good enough just to hire a person unless there is big company that would do the same. So you have chicken and egg problem, because no one will trust your certification and to get the trust someone would have to use it.

My idea is that you cannot effectively hire at scale. I could hand pick maybe 5 devs/year for my company, getting to real numbers in my small company I can see that we can hire maybe 2 developers per year. When We hire someone it worked for me with simple questions and attitude check. I don't see a way to hire 100 good developers in 1 year, that is not possible. Maybe at a scale you can hire 10-20 good developers a year but you have to have 3-5 people involved full time - and ideally those 3-5 people should be nice and technical - where in the end you don't want to use them only for hiring because those are probably your best developers with soft skills.

For that competency matrix - that is something you can do when you have developers inside of the company and you can observe them for at least 6 months. Good luck getting that in practical testing setup for 2 or less hours. I also find those kind of matrices terrible and not useful for evaluating people or projects. I work on a project where we were not fitting in anything of what was in the matrix .. yet we were delivering good quality for business all the time, while teams that were stuck on their "competency matrix" trying to improve meaningless points ended up disbanded and not working anymore in the organization.

Already exists. https://news.ycombinator.com/item?id=27662804 Don't you have apprenticeships in your country?

A good friend of mine worked with a young developer recently who was excited about what he was able to generate with a single npm command. When my friend, who has been writing software longer than this guy has been alive, calmly pointed out that the npm command had just generated 400 files and thousands of lines of code that didn't actually solve their problem, this guy got mad and went to complain to their manager.

"Wow! I can do so much with so little!"

"Everything you just generated is wasteful and meaningless."

The right way is to encourage that enthusiasm and guide them toward doing more useful work with the same power they just discovered.

You’re making the same mistake at vetting them that they’re making at vetting you

Similarly, a false positive is something that was accepted, when it should have been rejected.

If you have a sufficiently high candidate pool. you can (for a while, at least) live with an interview process with a relatively high false negative rate (that is, x% of the time you don't hire people you should have).

If it is typically quick to go from "in through the door" to "is a productive member of the team", it may be that you can live with a high false positive rate (that is, y% of the time you hire people you shouldn't have).

In your interview case, they should have given you hints, even if they want to not hire you later.

As an interviewer your two objectives are:

1. Ensure the candidate has an excellent experience

2. Collect data points

In that order. Sometimes we run into candidates who make the second item difficult. They fail to complete the specific technical problem. They can't speak about their experiences in detail. We need to drag data out of them screaming. It doesn't matter, your priority is to ensure they feel respected, and leave thinking they WANT to work there.

https://alexgolec.dev/reddit-interview-problems-the-game-of-...

I'm interviewing you too, so give me something that reflects the problems you solve as a team, otherwise my assumption is your office is full of white boards containing puzzles of the day and your tech is all 3rd party libs.

It may also be that anything work-related is actually too long to fit into a limited interview time.

Now, a trivial, brain-teaser, question would be "you have an NxM matrix, and you can either go left or up. How many paths are there from the lower left, to the upper-right corner?"

I consider it a brain-teaser because if you write code that contains any matrix manipulation or searching, you have basically failed. There is a closed-form expression for the number, so...

[1] By "non-trivial", I basically mean that there are multiple correct solutions.

The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).

How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).

The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.

I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.

It's too bad your experience was so negative. That's going to be a datapoint in my mental dataset of companies to consider when the time comes.

And from a completely non-technical persons perspective Reddit is incredibly disorganized at the executive management and corporate level. The amount of turnover, controversy, business model revamps, etc. for a 16 year old company with the hype they have is unique and unprecedented. It's not surprising whatsoever that their hiring practices are similarly disjointed.

I come in. The front-end guy starts asking me questions to try and solve something he is working on. No-one else is there yet. He is asking me about why a JS compiler is removing his comments, I say I don't know, I have never had that issue before...I make an off-hand comment that I use React and most of my JS code doesn't have comments because I am just working on projects by myself, and I don't do a lot of library code...the manager comes in at this point, and proceeds to berate me about why commenting is essential. I say: I use comments where they are needed. Off he goes, again.

Interview starts. Manager proceeds to go through a series of questions designed to expose my ignorance. None of which are related to the job. One classic was him explaining to me that database normalization made no difference to the size of the database because "the data is all the same on the disk" (which is, ofc, not accurate...I tried to explain, he just kept repeating that over and over...he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin). For some reason, there was also a back-end guy there who, upon hearing that I built something in Java, proceeded to launch into a series of questions on internals of Java (for example, he asked me what the difference was between certain versions of Java and the size of the heap...perhaps unsurprisingly, he also got some of this stuff wrong but began laughing when I said I thought X was Y).

The only two questions that I had about front-end dev were: the front-end guy trying to ask me to help solve an issue he was having (before the interview, when no-one was there), and a question about the value of this in arrow functions (which I got wrong, but is also an excruciating thing to try and explain, so I don't think the guy knew whether I got it wrong...it is a terrible question). That was it.

Huh ? language parsers remove comments because they're comments, that's literally by definition. Are you (or your past interviewer) using "comments" in a different sense ?

(Also, not trying to be a pedant on you I swear, but technically JS is traditionally interpreted. Most mature runtimes have compilers but it's not part of the API. It's just a juvenile pet peeve of mine when language implementations are generically referred to as compilers.)

>he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin

I sincerely hope from my heart of hearts that company or department is in it's well deserved position in the depths of the toilet now, or at any rate that specific person.

Actually can't find him at the company anymore. But the company isn't doing too well (although they seem to have moved into a nicer office). Revenue down 50% last year (from a small number to an even smaller number), costs up 60%, losing substantially more money than they have revenue, the operations guy who did my interview isn't there anymore either...true "tech company things". I didn't the impression that the company was that bad, they were more "much steam, no fire".

I'm really sorry to hear this, that sounds incredibly stressful. The worst part about stress in technical interviews is that even under good interviewing conditions (which you clearly didn't have) it can really hobble a candidate to be stressed.

I hope this experience (or this HN post) doesn't scare you away from programming or interviewing at software companies in general. Those guys sound like jerks. There are good companies and decent coding interview routines out there.

It was quite weird.

I thought I nailed their code challenge and expected to continue through the process, but after that session that was pretty much the last I heard from them. It was pretty disappointing.