I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups. That includes hiring countless developers, so I get both sides of the situation. And my partner is also a tech recruiter for a top tier HFT / market maker, so I know what a demanding but respectful hiring process looks like.
Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs. And a year later the role is still open.
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?
Unfortunately, yes. Young engineers are terrible at communication and working with others. Partly due to workplace incentives and partly because you must realize that entire generations have grown up with computers and not people.
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
Which is exactly why they do irrelevant interview brainteasers as well
This problem is a two way street in the tech sector, in case anyone wanted to fix it. The candidates alone are making the same mistake and bringing it to the company
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.
Do you want a pat on the back or something?
I had an technical interview with a company early last week, we did a shared session using VS Code. The interviewer wrote the function signature, and I filled out the implementation. I did great, according to the interviewer, and moved to the next set of interviews.
The next interviewer, which turned out was also technical, ended up opening up a shared Google Docs to write code it. I asked if I could just share my screen in my own editor, but they couldn’t give me permissions to do that. I was given an extremely vague question. When I asked questions, he told me to stop because he was holding out for next iterations of my implementation (again, in a Google Docs). Given no structure and an absurd environment, I completely bombed it. And to top it off, instead of getting an email saying they were not interested in me, they just ghosted me all together. A complete waste of time. I wish them luck in their endeavor to find the best engineer to write code in Google Docs, since that is apparently what they are interviewing for.
it was like sitting in a confusing nightmare for an hour
Frankly the most annoying interviewer I ever encountered. Served as a low water mark and inspiration for me to be as helpful, thoughtful, and kind as I could be in the next 100 phone screens/interviews I conducted for my employees.
FWIW, I've been to many a Google campus and know many employees there, so I think this was an outlier.
either way I ended up getting a cooler job somewhere else so maybe it was a good thing in the end
I really dislike when companies do this. It's very time consuming and psychologically/emotionally draining.
My focus is security, and so the second time around I got Travis Ormandy as an interviewer. I was able to impress him well enough with my IPSec foo to make it onsite. Then I got asked a question I had already been asked in another interview with another company, and I was able to knock that out of the ballpark (I mentioned I already knew that question, but the interviewer wanted me to answer it anyway). Then I got asked a question that used recursion, and because I took a graduate course on induction and recursion within the past year, that was effortless for me. Then I got asked a question that involved a kernel feature, and because I happened to recall the Linux kernel list macros and semantics (something I couldn’t repeat now over 10 years later), I really impressed that interviewer.
I ended up having a really successful part of my career at Google, even though I ended up not really writing much code when all was said and done. However what code I did write was highly impactful.
Looking back, things could have gone very differently if I had gotten a different set of interviewers and/or questions. The questions I got just happened to coincide with what was “paged in” to my “working memory,” so to speak.
I've never even heard of a Bloom filter, so I know how I would have done.
I've ran into "OMG he didn't know that!" responses when one dev disapproves of a candidate. Inevitably I ask "Really how often do you need to know that? and if you needed to wouldn't you just google it and be done?" but we assume it means so much more and there you go.
Then someone else gets hired and they knew the trivia, but can't apply it or worse only really knew the answer and not the ramifications... or they just can't wrap their mind around / don't care to think of second order effects or whatever.
These results may be "curved".
If you give the same easy test with no pressure and everyone is sufficiently good, then it was a waste of everyone's time.
In such an approach, you do something that is sufficiently hard that you're able to identify the people who are the better performing ones along with a reasonable idea of how well they work under pressure (because that will happen at some point).
Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).
Maybe because the concept of a test is flawed? It seems to me like every company that uses a whiteboard test gives out the same tests anyways.
What are they really trying to test? If someone understands common algorithms and data structures? I dont see why that couldnt be determined by a simple interview with an engineer. A test might be useful for a HR recruiter who doesnt have a computer science background, but those tests are usually conducted by other engineers anyways.
The whiteboard thing just seems to me like an arbitrary hazing ritual.
This is more a random fluke as much as sampling bias. Akin to someone either getting lucky or someone who is coming from a very similar environment. This isn’t a measurement that guarantees someone is competent, rather it’s a guarantee that someone is coming from just as incompetent an environment as you have.
Speaking only of ICs:
From principal engineers down, there's a technical screening. Distinguished engineers? Maybe. But then you're speaking about Guido van Rossum, James Gosling types.
My experience has been that this applies to recruiting, hiring, BD, sales, fundraising, etc. Anywhere that there's a systemic principal-agent problem.
I've heard that advice in various forms but I must say (anecdote incoming) - in my own 30 year career, the best jobs I've ever had were the random ones that I just applied for and the worst ones were the ones that somebody I knew from before recruited me in from outside.
I am wondering if the entire interview process should just be pay them for 2 weeks and see if they stick.
Am I on the top of my game right then and not stressed about anything and the questions out of the random million possible questions that could come up are ones that I just happen to have had on my mind recently? Then I ace the interview.
The last time that happened it was in a big international consulting company, they then put me through 5 other interviews afterwards, each one telling me I would hear something back in the next couple days.
The last one I got told couple more days, they didn't call me back for nearly two weeks. Then they call: Hey Bryan, we would complete the offer process now hope you're still interested?
Uhm unfortunately I got an offer last week for a 6 month consulting project, sorry but I had to take it because they said they couldn't wait to see how this turned out.
on edit: clarification.
In many other fields (medicine, law) people study a standardized body of knowledge, take a standard test and then get a license so they can do something others cannot.
However, this doesn't prevent a lot of awful and a lot of great people getting through. You would still need to interview a lot of them. I wonder if it sets a minimal level.
I assume it actually works pretty well but there's obviously a huge amount of gatekeeping involved.
Someday soon we may accept that what gets classified as software engineering is actually an amalgamation of skills from an entirely different set of titles/careers, most of which treat software creation and management as a tool and means to an end.
I don't generally consider a blacksmith and a welder to be the same occupations. You can lump them under metalworker, but would you really expect the interview process for these roles to be at all similar?
Or, why did the screen just scroll down and lose my place in the paragraph? Oh, they loaded an ad in the middle of the document and the page re-rendered itself causing jerks and fits on the screen. Nice job FAANG site!
Or try performing a sort of items by price or whatever other criteria … doesn’t work because the website wants the user to see the “suggested” items no matter what search criteria was desired y the user.
And …
I mean, we have things like the SWEBOK (https://www.computer.org/education/bodies-of-knowledge/softw...) that could be used to build a set of interview questions and acceptable responses, but does anyone use it for that?
The best interviews I've had, either as the interviewer or the candidate, have been when there was a discussion and a free flow of information in both directions. Unfortunately, it seems that in a lot of places, this degrades quickly into a hazing ritual.
He asked five or six questions related to C and C++ undefined behaviour, a very open-ended one about a technology I'd never used. I answered as best I can, but always opened with "I'd be referring back to the C standard and opening a JIRA task to fix the code". We got on to how I'd fix the code -- remove the UB, but only if there's a unit test covering it. What if there are no unit tests? What if there's no JIRA? Lots of what-if-maybes.
A few days later I was on a 3-way call with the recruiter and one of the guys that interviewed me. They spent the whole thing telling me how "any decent developer" should have known what the UB would result in, shouldn't have to refer to standards or books... and on and on. But as a courtesy, they'd be happy to make an offer.
Half the minimum posted salary, no benefits. It was right in the middle of the minimum wage and the "living wage" lines.
I declined politely, and the recruiter hung on the call...
"Wow. I don't know what to say. That's never happened before... do you mind if I share the recording of that call with my manager?"
They were still advertising to fill several positions when I last stumbled across them on Glassdoor a few months ago...
I haven't participated in technical interviews in a long time, but when I was asked to do it, I made it a point to throw as many lifelines as I could until I got a satisfying answer. For instance, if want to know if the person understands generics and they can't answer the question outright then I'll ask them about C++ templates. Similarly, if someone can't describe the term "idempotence" I'll ask them "can you tell me what makes a function pure".
Mind you those terms aren't interchangeable but if you catch one it should be trivial to understand the latter.
Becoming a specialized divorce lawyer still requires you to pass certification on things like criminal law and constitutional law (among many other things), you won't be permitted to practice law if you know just your specialty, no matter how well you know it.
Becoming a heart surgeon still requires you to pass certification on pharmacology and gynecology (among many other things), you won't be permitted to practice medicine if you just know your specialty, no matter how well you know it.
But for software workers we do accept that you can ignore many related (and even relevant) fields and just learn only one niche of technology - we could make an all-encompassing bar, but it would be a major change and I'm not sure if we would want that.
They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I started in this field in 1997. The interviews were more old fashioned, a few tech questions, see if you were an oddball, then they'd get back to you. If you didn't work out, they would just fire you. Pretty simple.
Not all CS degrees are created equal I'm afraid.
I’ve interviewed many people with 4 year CS degrees who can’t really code. I’m not sure how this happens, but it definitely does. I disagree that having a CS degree should excuse candidates from coding interviews.
If it's not enough for an employer, it's because that employer devalues what's taught in most CS programs. Granted, there's a significant mismatch between CS degree work and real world work, but that's true in lots of engineering. Ask any engineer in whatever subfield how much time they spend solving differential equations. I mean, great that I learned how to balance a binary tree and write a heapsort in my DS&A class, but have I ever needed to do that at work? Other than to pass some stupid coding interview?
In other words, there flipside of what you said is that sometimes you'll excel and be offered the job on very attractive terms.
Credentialing organizations already exist[1], but none have lobbied the US government to prevent the uncredentialed from practicing.
Perhaps it's time. If none of the existing orgs are good enough, start a new one.
1. https://www.computer.org/product/education/professional-soft...
I doubt hospitals interviewing senior doctors need to ask them basic anatomy questions, or law firms needing to ask candidates the difference between tort and criminal law. Tech could benefit from this minimal minimal bar.
One wonders what the history of how the credentials in medicine or law were forged.
Many devs are not good at their jobs. They mean well, but they can't solve basic problems without looking at stack overflow. And by "basic", I don't mean leetcode, I mean iterating over a collection.
> Anyone can trivially study and pass
Yes! At that point, I would know that the guy sitting next to me did at least some amount of studying of the fundamentals.
Sure, but what credential exists that both is reliable enough to support that use and would remain reliable enough once it became used that way, even in a specific narrow subfield of development?
https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...
I looked at it briefly but realized that I would need to study a significant amount of engineering aspects (how much water can flow through this pipe type engineering) to be able to pass the first exam.
For people who are developers, while the ethics, principals, rigor and similar type aspects of the PE exam process are useful, that it is still focused on being a PE first and a PE with an Software specialization second means that most people who are software developers would not be able to pass it or find use in the additional engineering principals that it provides (you wouldn't want me to sign off of a building design... well, maybe if I studied enough to pass the FE exam first...)
So, first I'd have to take the FE Electrical and computer exam... https://ncees.org/wp-content/uploads/FE-Electrical-and-Compu... or go with the other disciplines exam - https://ncees.org/wp-content/uploads/FE-Other-Disciplines-CB...
Either way, there's a lot of material there that I don't know and I don't imagine most CS new grads would have a clue on.
And that's just the FE exam. After four years of under a PE, then the PE exam - https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pd...
It's just not worth it.