Senior Developers Are Getting Rejected for Jobs(glenmccallum.com)
glenmccallum.com
Senior Developers Are Getting Rejected for Jobs
https://glenmccallum.com/2019/05/14/senior-developers-rejected-jobs/
383 comments
Definitely. I've run into devs with ">10 years of experience" who's coding abilities were closer to that of new grads or 1-2 years of experience.
I'm curious on how HN would filter developers like this. I've been a fan of take home exams, but I know that doesn't work for everyone.
I'm curious on how HN would filter developers like this. I've been a fan of take home exams, but I know that doesn't work for everyone.
One technique I've used for 8+ years now is an in-person programming problem. The general guidelines are:
1. It is a problem representative of the work the person will normally do in the job (we use an extract of our actual data for it) 2. We provide clear guidelines and criteria for success. 3. They are allowed to implement a solution in any language they choose, using any tools they choose (we ask everyone to bring a laptop with their preferred dev environment, but we do provide one with some common tools for them if they can't). 4. They are allowed to use Google and open-source libraries to help them with the solution (we want to see how they really solve a problem) 5. We are there to interact with them and answer domain specific questions, as well as to offer advice if they are stumbling on something to help them move forward.
I've really, really gotten a lot of good mileage out of this. The range of skills that I've encountered over the years has really surprised me. The problem is pretty straight-forward, and usually involves parsing some JSON, looking at the data, and matching disparate sets of the data together. The basic O(n^2) solution can be done in about 20 lines of code and there is some nuance to the datasets that require them to think through the problem and not what they have memorized in their head. I've had programmers with years of experience from places like LinkedIn take 20 minutes just trying to read a file in from the file system, and I've had people who are self-taught developers crank through a really good solution in the same time. I like being able to see how people are writing code, how quickly they are able to lookup information they might need, and listen to the types of questions they have when trying to solve the problem.
1. It is a problem representative of the work the person will normally do in the job (we use an extract of our actual data for it) 2. We provide clear guidelines and criteria for success. 3. They are allowed to implement a solution in any language they choose, using any tools they choose (we ask everyone to bring a laptop with their preferred dev environment, but we do provide one with some common tools for them if they can't). 4. They are allowed to use Google and open-source libraries to help them with the solution (we want to see how they really solve a problem) 5. We are there to interact with them and answer domain specific questions, as well as to offer advice if they are stumbling on something to help them move forward.
I've really, really gotten a lot of good mileage out of this. The range of skills that I've encountered over the years has really surprised me. The problem is pretty straight-forward, and usually involves parsing some JSON, looking at the data, and matching disparate sets of the data together. The basic O(n^2) solution can be done in about 20 lines of code and there is some nuance to the datasets that require them to think through the problem and not what they have memorized in their head. I've had programmers with years of experience from places like LinkedIn take 20 minutes just trying to read a file in from the file system, and I've had people who are self-taught developers crank through a really good solution in the same time. I like being able to see how people are writing code, how quickly they are able to lookup information they might need, and listen to the types of questions they have when trying to solve the problem.
> A truly senior developer who really wants the job, with a few weeks of practice for an hour every night can considerably improve their chances.
Thing is, very good people always have a plethora of options. So a company that tries to make a talented developer jump through somewhat silly hoops, is often going to miss out on that person. Google for example will say, 'we're ok with a lot of false positives' but they are also missing out on outright brilliant people who can make an outsized impact.
The FAANG companies can get away with it to a degree, because their compensation is so high. But there are a bunch of companies out there copying these hiring processes when they can't pay anywhere near what those companies pay, nor offer anything else compelling enough to make up for that.
So on one hand, yes, if you want to get paid the big bucks to work at one of the FAANG companies, you play ball their way and jump through the hoops. But that strategy is not going to work very well for the vast majority of other companies.
Thing is, very good people always have a plethora of options. So a company that tries to make a talented developer jump through somewhat silly hoops, is often going to miss out on that person. Google for example will say, 'we're ok with a lot of false positives' but they are also missing out on outright brilliant people who can make an outsized impact.
The FAANG companies can get away with it to a degree, because their compensation is so high. But there are a bunch of companies out there copying these hiring processes when they can't pay anywhere near what those companies pay, nor offer anything else compelling enough to make up for that.
So on one hand, yes, if you want to get paid the big bucks to work at one of the FAANG companies, you play ball their way and jump through the hoops. But that strategy is not going to work very well for the vast majority of other companies.
I've received offers to interview with Google, Facebook, Amazon and others... I turn them all down. The key is to find a job you like and make money on the side.
The sad part about this is that the filtering doesn't prevent getting sub standard candidates through the door. For example, I've been rejected by the Google interview process...but then shortly afterwords went to I/O expecting to find loads of insanely smart people working at their sand boxes and office hours that could run circles around my abilities and teach me things. There are some that know their stuff, but a lot who's apparent knowledge etc. was very under-whelming to the point of me knowing more than they did about the subject. Over time I've come to realize that part of the hiring process at these companies is political and that the filtering is still not preventing bad candidates from making it inside the company.
> A truly senior developer who really wants the job, with a few weeks of practice for an hour every night can considerably improve their chances.
But why would I want to spend that time? There's a lot of companies out there looking for experienced people. I have better things to do than to cram things I'll not actually need. I'm lacking time, not tasks and ideas.
But why would I want to spend that time? There's a lot of companies out there looking for experienced people. I have better things to do than to cram things I'll not actually need. I'm lacking time, not tasks and ideas.
Yes, I really want to give up my evenings for weeks to practice to impress people who clearly do not give a shit about what my job actually entails, by doing stupid crap tests that have nothing to do with the actual job.
I'd be damned tempted to walk out of an interview if they expected me to do trivial programming exercises.
I'd be damned tempted to walk out of an interview if they expected me to do trivial programming exercises.
This is seriously f'd up. When I was hired by IBM years ago, they also had a test called the IPAT (Initial Programming Aptitude Test) but, guess what?, there was no programming in it! Instead, the test was designed to see if one had the basic reasoning and logic skills which would be necessary to solve a wide variety of programming-related problems -- not one stupid, specific problem in a particular language. That's just asinine.
Making sure that developers have the "needle in a haystack" solution that you're looking for almost guarantees that you'll weed out the most talented folks -- the ones who are programming generalists that can reason about and solve any kind of programming problem.
Making sure that developers have the "needle in a haystack" solution that you're looking for almost guarantees that you'll weed out the most talented folks -- the ones who are programming generalists that can reason about and solve any kind of programming problem.
An extremely underrated point: Hire. Generalists.
Sometimes you really do need particular skills and experience that take decades to learn. Otherwise you don't even know what you don't know and you don't know what mistakes are usually made in a given area.
Not knowing what to do or what others did can be an advantage. Einstein developed his theory of relatively by simply discarding all the known theories about how physics worked. In my own experience at IBM, I solved a bug that had been repeatedly opened over a series of 9 years by simply asking the question, "Is this number a hex or a decimal?"
> by simply discarding all the known theories about how physics worked
But he wasn't ignorant of them. He knew the existing work. He was extremely well read in physics and maths. He wasn't a generalist!
If you get a group of random generalists to build your compiler, or your graphics engine, or your cryptography stack, they aren't going to know what they don't know, and it'd take them decades to come up to speed.
But he wasn't ignorant of them. He knew the existing work. He was extremely well read in physics and maths. He wasn't a generalist!
If you get a group of random generalists to build your compiler, or your graphics engine, or your cryptography stack, they aren't going to know what they don't know, and it'd take them decades to come up to speed.
As somebody who wrote all of the above (and a lot more) I call B.S. on this one.
The amount of unique stuff in each subfield is not that great, and if you have a wide and solid base in different subfields, picking up the unique ideas and techniques isn't that hard or time consuming.
But after a generalist has it, he is a lot more productive and creative because he often applies stuff from other subfields to come up with better/novel solution to the problem at hand - something a specialist cannot do.
The amount of unique stuff in each subfield is not that great, and if you have a wide and solid base in different subfields, picking up the unique ideas and techniques isn't that hard or time consuming.
But after a generalist has it, he is a lot more productive and creative because he often applies stuff from other subfields to come up with better/novel solution to the problem at hand - something a specialist cannot do.
"Einstein developed his theory of relatively by simply discarding all the known theories about how physics worked."
That's ludicrous nonsense. The primary breakthrough of the theory of relatively was taking what the math had been telling physicists about the universe for years seriously. In hindsight, everything necessary was there before Einstein, it just was very deeply assumed not to be reasonable. Relativity builds on numerous pre-existing foundations and is very much in the "standing on the shoulder of giants" tradition.
https://en.wikipedia.org/wiki/Theory_of_relativity#Developme... , first paragraph
That's ludicrous nonsense. The primary breakthrough of the theory of relatively was taking what the math had been telling physicists about the universe for years seriously. In hindsight, everything necessary was there before Einstein, it just was very deeply assumed not to be reasonable. Relativity builds on numerous pre-existing foundations and is very much in the "standing on the shoulder of giants" tradition.
https://en.wikipedia.org/wiki/Theory_of_relativity#Developme... , first paragraph
Yes, he knew them and discarded them. Adam Frank's excellent About Time does a good job of telling the story.
> Yes, he knew them and discarded them.
That's the sign of an expert, not a generalist.
That's the sign of an expert, not a generalist.
If you took out the bits of relativity that were developed by others, you'd be left with not very much. Relativity without the Lorentz transform... I'm not even sure how one would resolve that. As I said, the vast majority of the insight was just taking what the math was already saying seriously. Einstein put it into a final form, and this is important and valid work, but it's not like he invented all the mathematical tools from scratch.
Either you've misinterpreted Adam Frank's work, or it isn't excellent.
I'll counter-cite Reflections on Relativity, which contains a lot of deep analysis of the mathematical history of relativity both before and after Einstein: https://mathpages.com/rr/rrtoc.htm which makes it quite clear both what he did, and did not do.
Either you've misinterpreted Adam Frank's work, or it isn't excellent.
I'll counter-cite Reflections on Relativity, which contains a lot of deep analysis of the mathematical history of relativity both before and after Einstein: https://mathpages.com/rr/rrtoc.htm which makes it quite clear both what he did, and did not do.
I'm no astrophysicist, though Frank is. The two concepts I'm referring to as being "discarded" were Newton's idea that motion (ie: time and space) exist in a fixed frame of reference. I think it's fair to say Einstein tossed that out wholeheartedly. The other idea Frank mentions that Einstein threw away was the idea of an æther that filled the voids in the universe. According to Frank, Einstein didn't like this idea so he just worked without it.
Am generalist, I hire generalists. My favourite feature is that they/we don't know what we're not supposed to do. So we just go, damn the torpedoes. Smart generalists GSD
1) there are not even enough generalists, good generalists are expensive, and bad generalists... you don’t want them.
2) as a generalist, I am quite OK with hiring specialists, if they are really good at what they do. I am a “full-stack”, which means that while I can do both frontend and backend, I can’t shoot React and CSS like a machine gun, nor can I squeeze the last bits of performance from JVM. I hire specialists to do that, after I got the ball rolling.
I think this can really depend on the size of the business. At a small company, you probably can't afford a specialist for each area of responsibility. At a big company, you probably can't afford _not_ to have a specialist.
As a generalist, I can't agree more.
Most opportunities look for some high degree of specificity. For contract work or a pre-defined task, that makes sense but for companies that need a rich talent pool, I don't know why there appears to be little opportunity for generalists.
Most opportunities look for some high degree of specificity. For contract work or a pre-defined task, that makes sense but for companies that need a rich talent pool, I don't know why there appears to be little opportunity for generalists.
So basically, an IQ test.
I believe these run into legal grey areas because they have to be obviously relevant to the job in question, which likely leads to the tests getting progressively more domain-specific as time goes on.
Programming does seem to be a field in which general intelligence is a big predictor of success. Whereas a field like management probably personality and general intelligence are more equally weighted.
I believe these run into legal grey areas because they have to be obviously relevant to the job in question, which likely leads to the tests getting progressively more domain-specific as time goes on.
Programming does seem to be a field in which general intelligence is a big predictor of success. Whereas a field like management probably personality and general intelligence are more equally weighted.
So basically, an IQ test.
Well yes. And that is what the current crop of "programming puzzle" interviews essentially are; the next iteration of attempting to measure people on a cardinal scale instead of an ordinal scale.
The key to remember is that evaluating on a cardinal scale is much more efficient than evaluating on an ordinal scale, so companies will do everything they can to transform the "secretary problem" into one where they measure absolute metrics instead of relative metrics.
Now, whether those metrics align with business value is a separate issue. All evidence suggests that they are largely independent of business value.
Well yes. And that is what the current crop of "programming puzzle" interviews essentially are; the next iteration of attempting to measure people on a cardinal scale instead of an ordinal scale.
The key to remember is that evaluating on a cardinal scale is much more efficient than evaluating on an ordinal scale, so companies will do everything they can to transform the "secretary problem" into one where they measure absolute metrics instead of relative metrics.
Now, whether those metrics align with business value is a separate issue. All evidence suggests that they are largely independent of business value.
HR told me I couldn't ask such questions without proving they were useful first.
Basically a scientific experiment, have someone else ask and grade the questions, but those results were not considered for hire/nohire. Then 6 months after a bunch of people were hired we pull the results of the test and compare to their performance reviews. If the questions were a good predictor or future success we could use them on future interviews.
The overhead of this was more than we were willing to pay so we went back to HR's allowed questions.
Basically a scientific experiment, have someone else ask and grade the questions, but those results were not considered for hire/nohire. Then 6 months after a bunch of people were hired we pull the results of the test and compare to their performance reviews. If the questions were a good predictor or future success we could use them on future interviews.
The overhead of this was more than we were willing to pay so we went back to HR's allowed questions.
My previous company issued the Wondelic Test (https://en.wikipedia.org/wiki/Wonderlic_test) for everyone. I don't know the details but there was a minimum for different positions. There was also a personality portion and they were looking mostly for "A" type personalities, and a small subset of others. I don't have the "A" type personality, but I'd like to think the IQ portion made up for it LOL.
Legality...not sure.
Legality...not sure.
Meanwhile employers can ask you to complete "psychological evaluations" just fine
From what I know, the IPAT still exists. Had to take it in 2015 for a co-op with IBM.
Googling around shows the consensus that the IPAT is considered one of the most difficult hiring tests out there, yet it contains no programming.
I mean, when I did it it was considered a formality.
I don’t think anyone considers it a difficult barrier compared to getting into FNG etc.
I don’t think anyone considers it a difficult barrier compared to getting into FNG etc.
That seems much worse than programming tests IMO. If I have a bachelor's degree, and you're asking me to retake the SAT, you're just insulting my qualifications. At least programming tests have some legitimate rationale. Let's not pretend IBM has any fucking idea what they are doing.
It wasn't an IQ test, and IBM definitely knew what it was doing in ways today's "move fast and break things" culture cannot fathom. Their software was and still is used in many mission-critical applications because the company was rigorously focused on quality. When was the last time you heard of a bug in mainframe software affecting anyone?
While I agree with you conceptually, as a daily DataStage/InfoSphere user, there are plenty of buggy IBM products. I do think a general problem solving test is way more useful for vetting candidates than some stupid algo whiteboard assessment, and my company has been using something like that to great effect to recruit jr devs.
Maybe you're talking about something else, but have you heard about IBM's infamous Phoenix Pay System?
https://en.wikipedia.org/wiki/Phoenix_pay_system
In short, it's costing Canada billions of dollars and has affected countless people's livelihoods.
https://en.wikipedia.org/wiki/Phoenix_pay_system
In short, it's costing Canada billions of dollars and has affected countless people's livelihoods.
Intelligence Is the Best Predictor of Job Performance https://journals.sagepub.com/doi/abs/10.1111/1467-8721.ep107...
Thought in the US you will run into problems due to Griggs v. Duke Power Co.
Thought in the US you will run into problems due to Griggs v. Duke Power Co.
I don't know if people have generally been following Taleb's critique of IQ and other intelligence measures, but there are three tracks to it.
One is purely statistical -- that if you offer any metric of success, and try to correlate it with any measure of intelligence, even if the two are actually uncorrelated, then having dead people in the sample (that is, people who score 0 on both) will increase the quality of the correlation. Applicable because when you eliminate people who score low on IQ tests and low on performance tests from the sample, the correlations tend to disappear in these studies.
The second is more intuitive, that intelligence is multifaceted and attempts to project it into a low-dimensional space will mask the inherent complexity, but will be capable of identifying individuals that score low across many dimensions. That leads to the condition in the first issue.
The third is probably the most controversial; that IQ tests in particular do not measure generalized intelligence, but measure how well you can do "drone work", so for places where performance can be objectively measured, it will tend to be in tasks that do not require creativity or initiative in unpredictable directions because those are not easily measured, so thus reflective of the same sorts of tasks that IQ tests measure.
One is purely statistical -- that if you offer any metric of success, and try to correlate it with any measure of intelligence, even if the two are actually uncorrelated, then having dead people in the sample (that is, people who score 0 on both) will increase the quality of the correlation. Applicable because when you eliminate people who score low on IQ tests and low on performance tests from the sample, the correlations tend to disappear in these studies.
The second is more intuitive, that intelligence is multifaceted and attempts to project it into a low-dimensional space will mask the inherent complexity, but will be capable of identifying individuals that score low across many dimensions. That leads to the condition in the first issue.
The third is probably the most controversial; that IQ tests in particular do not measure generalized intelligence, but measure how well you can do "drone work", so for places where performance can be objectively measured, it will tend to be in tasks that do not require creativity or initiative in unpredictable directions because those are not easily measured, so thus reflective of the same sorts of tasks that IQ tests measure.
This was also back when companies were actually willing to train people. Using a test like that, they could try to hire people who had "potential" and then give them a career where they could grow, improve, and bring value to IBM
That doesn't mesh so well with the modern era of employers hating spending a dime on training, even if it would save them a dollar, and employees wanting to jump ship every other year for that sweet sweet 10% compensation bump
That doesn't mesh so well with the modern era of employers hating spending a dime on training, even if it would save them a dollar, and employees wanting to jump ship every other year for that sweet sweet 10% compensation bump
Good point. The first thing they did after hire was send everyone away to a 6 week "boot camp" which was invaluable. Who does that anymore?
This is kind of a funny article. It starts off by describing the problem that is created by these interviews, and then sort of waves its hand saying that companies like them and they are here to say. It's probably more of a blog post than a journalism article, but it would be more interesting if they either got to the depths of why they are failing some people and considered some alternatives that might work for both companies and people who are more senior.
> It's probably more of a blog post than a journalism article
What gave you the idea that it was anything but a blog post/personal opinion piece?
What gave you the idea that it was anything but a blog post/personal opinion piece?
[deleted]
I am sure all these methods were validated as significant predictors of job success using longitudinal data, right? It's not like the bad old days where managers and HR people would just ask questions they thought were relevant to the job (or flip a coin).
https://www.forbes.com/sites/work-in-progress/2015/05/21/why...
https://www.forbes.com/sites/work-in-progress/2015/05/21/why...
[deleted]
[deleted]
We need to admit that the interview process isn't about determining the relative qualifications of the applications in the pool, because we all know that 3 hours and whiteboard can't tell anything you need to know about whether or not that person will perform over the years. We need to acknowledge that we perform this pantomime in order to satisfy layers of management that are unable to accept that you can't hire for these positions as you would a traditional sales position.
Further, I think it needs to be said that at smaller companies (read: startups) whats really happening is that applicants are being evaluated for whether or not they're cool enough to join the club. We call it "culture fit" but we're really just trying to vet their personalities.
EDIT: To be clear I do think people's personalities need to be evaluated, especially with smaller teams. I just think we should drop the pretense that "implementing" a depth first tree search on a whiteboard tells us anything other than that they could summon that algorithm at that moment in time with that amount of coffee and whether or not they had a pleasant morning. First of all, I want engineers that are good at working with others, and second of all it takes months to truly evaluate an engineers ability to do their job. We gain nothing by pretending this isn't the case.
Further, I think it needs to be said that at smaller companies (read: startups) whats really happening is that applicants are being evaluated for whether or not they're cool enough to join the club. We call it "culture fit" but we're really just trying to vet their personalities.
EDIT: To be clear I do think people's personalities need to be evaluated, especially with smaller teams. I just think we should drop the pretense that "implementing" a depth first tree search on a whiteboard tells us anything other than that they could summon that algorithm at that moment in time with that amount of coffee and whether or not they had a pleasant morning. First of all, I want engineers that are good at working with others, and second of all it takes months to truly evaluate an engineers ability to do their job. We gain nothing by pretending this isn't the case.
‘Culture fit’ (without clearly specifying what that means) is such an enormous backdoor for all manner of bias and personal prejudice I’m surprised the concept is even legal.
Completely agree. I've been lucky to have been surrounded by pretty reasonable people in my 8-10 years in the startup world on the east coast but "culture fit" was one of the rare situations that I got in a really impassioned arguments with my superiors. It's code that allows you to avoid hiring a guy who wears Fubu or has a Kentucky drawl.
What’s wrong with evaluating whether you’d get along with someone as a coworker? In my experience, being friendly and getting along has aided cooperation far more than hiring the most qualified candidate at the detriment of group dynamic. Yes, there are potential biases, but at a smaller company I’d say that’s a huge factor.
I edited my top level comment for just this reason. Interpersonal communication skills are extremely important to evaluate for any position. But the person you're replying to is saying, correctly, that this isn't what people mean in practice when they bandy about the term "culture fit."
I see, yes, stereotyping based on some perceived “flaw” like accent is absolutely wrong and needs anti-bias training to remedy. It is tough though. I want people I interview for my company and team to get along with everyone, and trying to make that evaluation in a short amount of time can often result in immense bias. In the end, interviewing is fucking hard.
No question. Personally I think the first and most important step is getting everyone in our industry to admit that they have deeply internalized biases that they're not likely to be fully aware of and that they have a real effect on important decisions. Once you've acknowledged that you can start to check yourself.
Agreed, and it's up to the organization to remedy those biases with multiple rounds of interviews, and most importantly, making sure those multiple rounds consist of interviewers with different inherent biases and tendencies.
Or it’s such a vague term that means something different to each team and might have significance depending upon what is valued?
Yes but my point is that in my 8+ years in the startup world it has a very specific connotation that is, as someone else said, a vehicle to legitimize really inappropriate biases into hiring.
"Poor communication skills" is another that seems to just mean "has an accent."
So if I make a startup, I should be forced to hire some brilliant programmer whose personality I clash with over over a slightly less brilliant programmer who I can tell will become a fast friend just because the former has demonstrated more technological prowess?
"Hard to work with" is a pretty big minus on somebody's skillset, you don't need to hide it under "culture fit".
I mean, it's just a hunch though. I've only spent an hour or two with the person, I don't know actually know if they would be hard to work with.
Candidate one gives off slightly anti-social vibes but is brilliant, candidate two jokes around with me during the interview and is smart as well, but less so than candidate one. Am I justified in going with candidate two on a hunch?
Candidate one gives off slightly anti-social vibes but is brilliant, candidate two jokes around with me during the interview and is smart as well, but less so than candidate one. Am I justified in going with candidate two on a hunch?
In your position, I’d take candidate 2. Displaying a reasonable level of competence and ability to work in a group is so much more crucial for a small company!
But now you did the mistake of assuming a lot of stuff, with very little data. Why can you say that person 2 is better at working in a group? Maybe person 1 was just very nervous, or is a type that takes a few days to warm up to new people. Maybe person 1 just crack jokes all day and is actually detrimental to the productivity. Impossible to tell from this one que alone.
And hence, some weight in the skills/judgement of the interviewer.
Which is also why there are usually multiple stages in an interview process, or at least, you pass a candidate to 3 or more team members to interview the candidate.
In my experience, it's hard to find good candidates, but not that hard to figure out which of the candidates will be a good fit, and a strong contributor, to a team. I've also hired mostly for team sizes of 10-20 developers, not 200.
Which is also why there are usually multiple stages in an interview process, or at least, you pass a candidate to 3 or more team members to interview the candidate.
In my experience, it's hard to find good candidates, but not that hard to figure out which of the candidates will be a good fit, and a strong contributor, to a team. I've also hired mostly for team sizes of 10-20 developers, not 200.
You're always left with an imperfect amount of information after an interview. I don't think that means you should discount how well someone fits into a conversation given how important solid communication is.
Pretty much this. Yes, technical skill is important, but to some degree, the proficiency to do our jobs can mostly be taught given a proven background and some proven competency during the interview. Good communication skills? That's something taught over a lifetime.
what about the risk that candidate #2 has schmoozed their way up the ladder, and really isn't as smart as they seem?
Rejecting someone is really hard. Of course you want to give them actionable feedback, but at the same time you don't want to give them a bad feeling about you or your company. These two things are almost diametrically opposed to each other, because most people take feedback from strangers pretty badly.
Sure, it'll be more productive for everyone if I tell someone that we think they're just not smart enough to learn shit as fast as we need them to. But that hurts. So we say "You're great, but we're looking for someone with just a few more years of C++ experience". Similarly, when we think you've been acting like an arrogant dick, we say "lack of culture fit".
I once rejected someone whose English was so bad that I couldn't understand them on the phone. That's a hard thing to tell a foreigner who has the courage to call you up, by phone, in a language they probably know they're not great at, for an internship position! So I lied and I told them they had insufficient React experience. Am I proud of that? No. I'm still not sure what I should've done.
I see this trope a lot on HN that "lack of culture fit" means "wrong brand of sneakers" and it's usually nonsense. "No culture fit" means "there's something specific that we dislike about the way you behave or communicate but we don't want to hurt your feelings more than necessary".
Sure, it'll be more productive for everyone if I tell someone that we think they're just not smart enough to learn shit as fast as we need them to. But that hurts. So we say "You're great, but we're looking for someone with just a few more years of C++ experience". Similarly, when we think you've been acting like an arrogant dick, we say "lack of culture fit".
I once rejected someone whose English was so bad that I couldn't understand them on the phone. That's a hard thing to tell a foreigner who has the courage to call you up, by phone, in a language they probably know they're not great at, for an internship position! So I lied and I told them they had insufficient React experience. Am I proud of that? No. I'm still not sure what I should've done.
I see this trope a lot on HN that "lack of culture fit" means "wrong brand of sneakers" and it's usually nonsense. "No culture fit" means "there's something specific that we dislike about the way you behave or communicate but we don't want to hurt your feelings more than necessary".
If the reason you can't work with them/clash with them is based on their protected class status, the answer is yes, you are forced to hire them. So why not expand it a bit to protect groups that might not have quite the same level of legal protection?
My opinion: there's not enough information to make a rational decision between the two.
Perhaps check references to determine if either candidate was able to work well in the type of environment you provide.
For example - the nice person may be lazy, or the abrasive person may productive and helpful.
It's been my experience that contacting the candidates references will flush that information out. Even in this age of litigation - I've always been able to get an answer to "Please rate on a scale of 1 to 10"
We've avoided some people that interviewed well and had great skills but were horrible human beings - and we've picked up some people that are hard workers that are willing to learn that didn't interview well.
Perhaps check references to determine if either candidate was able to work well in the type of environment you provide.
For example - the nice person may be lazy, or the abrasive person may productive and helpful.
It's been my experience that contacting the candidates references will flush that information out. Even in this age of litigation - I've always been able to get an answer to "Please rate on a scale of 1 to 10"
We've avoided some people that interviewed well and had great skills but were horrible human beings - and we've picked up some people that are hard workers that are willing to learn that didn't interview well.
Some programmers are real jerks who are always trying to prove how smart they are in competition with other people in the room, and because these are basically acting out on a neurosis if you have one of them yes an hour interview will probably at least establish some cause for concern.
If you want to play the hypothetical game: maybe you're the kind of person (most of us are!) who will never be fast friends with someone who's a woman. Or gay, or Muslim, or Mormon, or vegan, or deaf, or Republican.
If your hiring criteria excludes groups like that by a "fast friend" proxy test, then yeah, you should be taking the better programmer.
If your hiring criteria excludes groups like that by a "fast friend" proxy test, then yeah, you should be taking the better programmer.
Yes, as a manager you shouldn't become friends with your reports anyway. It happens but it always complicates things. If for no other reason then you have a perception issue with your other reports that you don't have a relationship with. Did your friend get a promotion because they're good or your friend? Did they not get the promotion because they're your friend and you're worried about optics?
This doesn't even touch even more difficult situations like when your friend messes up and needs to be dealt with in a professional but non-personal manner.
So yeah, hire the better coder.
This doesn't even touch even more difficult situations like when your friend messes up and needs to be dealt with in a professional but non-personal manner.
So yeah, hire the better coder.
So? Bias isn't illegal unless your pattern of bias lines up with a protected class.
Bias was for protected classes was made illegal for a particular reason, which also applies to a less extent to the non-protected classes. To argue that bias is acceptable along as it isn't explicitly illegal is a stance that seems dangerous when applied to other areas of technology, and many past discussion within this community have shown that many members here are concerned with doing more than the bare legal minimum when it comes to ethical behavior.
Ageism is illegal in US under Age Discrimination in Employment Act if that person is 40 or older.
Only if the ageism is on favor of the younger person. It is never illegal ageism to always hire the oldest candidate.
Every ageist situation that I have encountered thus far (am age 46) was "not a cultural fit."
I look younger than I am, but my patience for over-working too many hours is at an end. Years of stress have led to health issues that have to be managed.
But this all rolls into "not a cultural fit."
I look younger than I am, but my patience for over-working too many hours is at an end. Years of stress have led to health issues that have to be managed.
But this all rolls into "not a cultural fit."
Yeah, and as a worker in his 20s who prioritizes work-life-balance, I wouldn't be a culture fit at those places either.
So the law is wrong. This is the alignment problem, but for laws instead of AI. The law doesn’t perfectly match what society (to the extent that society is an entity with desires) actually wants.
As usual, the root problem is that workplaces are made of humans. Yes, "culture fit" can absolutely be used to excuse nastiness. It is also a real thing that seriously matters, and ignoring interpersonal dynamics is a very quick way to kill a startup.
I'd just note that you can smuggle nasty behavior into any formal mechanism. Witness the legal system (which you'd engage here) - whining about bad-faith arguments in court is basically a national sport in the US, until the whiner is the plaintiff.
I'd just note that you can smuggle nasty behavior into any formal mechanism. Witness the legal system (which you'd engage here) - whining about bad-faith arguments in court is basically a national sport in the US, until the whiner is the plaintiff.
tbh I don't see a huge issue with a small team of friends wanting to stay a small team of friends. imo, it starts to be problematic when a large (for some definition of "large") employer hires on the basis of culture fit.
I've seen "culture fit" used in an attempt to reject female candidates because the interviewer didn't want to stop telling dick jokes around the office.
Fortunately, the management chain caught this and ... corrected the issue.
Fortunately, the management chain caught this and ... corrected the issue.
Turns out culture fit was the problem, just not for the candidates.
My wife had a great interview, everything was going well and they were showing her around the office. When she got to the team that was hiring, the hiring manager indicated that they like to shoot Nerf guns at each other, and they hope that is OK.
My wife showed a sign of mild disapproval, and that was it. She was rejected for "not a culture fit".
My wife showed a sign of mild disapproval, and that was it. She was rejected for "not a culture fit".
Culture fit does make a lot of sense though. I interviewed at a company where everyone was a gamer. Would I have fit in? Probably not. Another company everyone looked about 25 or younger.
I don't blame them for not wanting to hire someone pushing 50. They just don't know if they're going to get the cool 50-year-old or the grumpy old troll who won't listen to anyone.
Of course they can never come out and say that for obvious reasons.
I don't blame them for not wanting to hire someone pushing 50. They just don't know if they're going to get the cool 50-year-old or the grumpy old troll who won't listen to anyone.
Of course they can never come out and say that for obvious reasons.
> Culture fit does make a lot of sense though. I interviewed at a company where everyone was a gamer. Would I have fit in? Probably not. Another company everyone looked about 25 or younger.
I play video games. I have all of the last two generations of consoles, a smattering of older consoles I've managed to hold onto over the years (lost most of them for one reason or another) and a half-decent gaming PC where I prefer to play games if possible. On top of that I've done game development on the side, and have run multiple gaming communities for approximately a decade now.
If I went to go interview with a company and they talked about how they were all "gamers", I'd be running for the hills.
You know what I want to do at work? Work.
You know what I want to talk about at work? Not video games.
You know what I want for non-monetary compensation? Not a weekly autochess tournament or PUBG squad night.
You know what kind of people I want to be surrounded with? Not a bunch of clones who all have the same beliefs and values and (lack of) experiences.
I play video games. I have all of the last two generations of consoles, a smattering of older consoles I've managed to hold onto over the years (lost most of them for one reason or another) and a half-decent gaming PC where I prefer to play games if possible. On top of that I've done game development on the side, and have run multiple gaming communities for approximately a decade now.
If I went to go interview with a company and they talked about how they were all "gamers", I'd be running for the hills.
You know what I want to do at work? Work.
You know what I want to talk about at work? Not video games.
You know what I want for non-monetary compensation? Not a weekly autochess tournament or PUBG squad night.
You know what kind of people I want to be surrounded with? Not a bunch of clones who all have the same beliefs and values and (lack of) experiences.
Right. So you would be weeded out by the culture fit, as I was. And in the long run I was glad for it. I think they made the right decision and I'm glad I didn't end up working for them. Even though it paid a little more and was half the commute of the job I did get.
Well that's exactly the point of the culture fit.
You should be a good fit for the company, and the company should be a good fit for you. It goes both ways.
You should be a good fit for the company, and the company should be a good fit for you. It goes both ways.
Let's try for a straightforward definition:
Culture is preference between two otherwise value-neutral positions.
For example: encouraging collaboration vs. encouraging independent work.
Or supporting self-organizing teams vs. all work having a WBS/charge code.
Culture is not choosing between being respectful and not; or choosing between being openminded and not; or choosing between being honest or not.
Culture is preference between two otherwise value-neutral positions.
For example: encouraging collaboration vs. encouraging independent work.
Or supporting self-organizing teams vs. all work having a WBS/charge code.
Culture is not choosing between being respectful and not; or choosing between being openminded and not; or choosing between being honest or not.
Saying they "can't tell you anything" is one-bit thinking. Yes, there is a lot that interviews don't tell you, but they are still a useful signal.
Yeah that's fair. Im just frustrated with how low-bandwidth those things are. I definitely get a bit of a sense of how a person thinks by watching them do those CS 201-style problems, which isn't nothing.
If the CS 201-style problems annoy you, then... stop doing them?
I don't ask algorithm questions, and I wouldn't even dream of asking brain teasers. I ask questions like "Here's a pile of text that claims to be CSV, let's explore how you'd generate an HTML report out of it", and branch out from there depending on how the interview goes. I've got all sorts of directions I can go from there, from screwing up the input in various real-world ways, discussing HTML security and injection attacks, algorithmic complexity of the report, how to build a service out of this, how we're going to handle reporting errors, there's just an endless number of ways you can take the interview from there.
CS 201 doesn't usually come up.
I don't ask algorithm questions, and I wouldn't even dream of asking brain teasers. I ask questions like "Here's a pile of text that claims to be CSV, let's explore how you'd generate an HTML report out of it", and branch out from there depending on how the interview goes. I've got all sorts of directions I can go from there, from screwing up the input in various real-world ways, discussing HTML security and injection attacks, algorithmic complexity of the report, how to build a service out of this, how we're going to handle reporting errors, there's just an endless number of ways you can take the interview from there.
CS 201 doesn't usually come up.
This specific question is new to me but I like it a lot. I have found that the most useful interview questions are technical but more conversational than a white board, more about how to approach and solve a realistic problem. I think your method is a good high-signal approach.
A little late but I wanna be clear that I don't ask them! I ask questions similar to you. My comments here largely come from my experience doing the interview problems. But yeah, i've tried to "be the change," so to speak.
I find them useful if you use a real world problem from your product, and the whiteboard is just a tool to help you collaborate as they brainstorm and discuss possible solutions with you. That reduces the pressure and you also get a read on their collaboration skills.
The ideal would be pair programming for an afternoon.
The ideal would be pair programming for an afternoon.
When I interview candidates for the company I work for I describe a key part of our system in general terms (20 possible elements, at least one active but any combination, items are single/set/hierarchy) then ask them to talk me through issues they can see writing generic code to handle data management and computations given these conditions. They don't have to write code, but they do have to be able to think logically and express themselves clearly. Some describe pretty much what we do, some get creative, and some are completely at a loss. Some pseudocode to help describe what they're thinking, most don't.
Even if their "solution" is incomplete I look at if they get the gist right.
Even if their "solution" is incomplete I look at if they get the gist right.
Eh I see where you're coming from, and most interviews are this way, but I've definitely seen and organized interviews that eschew leetcode problems for very simplified every day problems, and at least imo they can tell you a decent amount. Have 3 or 4 of those in varying skills and you can get a pretty decent idea.
coding portions of an interview should probably be considered as like a bloom filter. it doesn't tell you for sure whom to hire, but it can certainly expose whom not to hire.
THIS - my experience with interviewing with startups has been very poor. Generally startups are staffed by younger people.
Sometimes those people conducting the interviews are on their first or second job, and generally those younger coders have a tendency to emphasize things like obscure syntax for whatever programming language and the latest programming paradigms. It is overly language centric rather than dealing with how to solve problems. That is a terrible metric for the issue at hand "will this person be an effective at their job".
Sometimes those people conducting the interviews are on their first or second job, and generally those younger coders have a tendency to emphasize things like obscure syntax for whatever programming language and the latest programming paradigms. It is overly language centric rather than dealing with how to solve problems. That is a terrible metric for the issue at hand "will this person be an effective at their job".
[deleted]
It's not easy to see in the moment, and sometimes an individual's options are limited (though this seems rare for senior devs), but why would anyone want to continue to create value for someone who holds biases against them that are hidden as not being a 'cultural fit'?
>First of all, I want engineers that are good at working with others
Yes ! The worst engineers I have had to work with were sometimes pretty skilled technically, but their ego or shitty personality was preventing them from being somebody the team could benefit from.
I would have thought that it is why we have cultural fit interviews though.
Personally I would sooner drop whiteboards than cultural fit interviews, but the later probably need way more training for the interviewer than what I got.
Yes ! The worst engineers I have had to work with were sometimes pretty skilled technically, but their ego or shitty personality was preventing them from being somebody the team could benefit from.
I would have thought that it is why we have cultural fit interviews though.
Personally I would sooner drop whiteboards than cultural fit interviews, but the later probably need way more training for the interviewer than what I got.
Absolutely untrue.
Whiteboard problems absolutely do work.
The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.
Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises.
How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.
Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.
Source: I've interviewed a great deal of people for lots of positions over the years.
Whiteboard problems absolutely do work.
The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.
Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises.
How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.
Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.
Source: I've interviewed a great deal of people for lots of positions over the years.
+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them.
Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.
Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.
I used to give a whiteboard coding interview (for a QA engineer position) that started with "swap the values of two integer variables. Yes, you can use a temporary variable," then went on to find the highest element in an array, then implement any kind of sort for an array, then implement depth-first-search.
People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it.
It is very true that you need to qualify someone's ability to write code at all.
I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program.
There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."
People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it.
It is very true that you need to qualify someone's ability to write code at all.
I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program.
There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."
The best coding challenge for a hiring process I ever had happened, of all places, when I applied for a PHP development position at Fender.
At the time, their marketing department did all of their web development in-house. I don't recall all the specifics; there was a round table meeting between the manager of the unit, the team lead, and one of the senior developers. At the end of it, they sat me in the cubicle area with their other developers, gave me an MBP with MAMP on it, and a piece of paper outlining what they wanted me to code - a simple CRUD app. It didn't have to have any fancy styling, but it had to look ok, and it had to work. It was "open book" otherwise; use google or whatever other resource as you needed it. Also, all this happened while the other devs were in the area; it was basically a time slot from 2:30pm to closing time...
I'm thinking - really? Something this basic...
But given what you had to do - essentially from a blank slate, including the database, set up the tables, build the SQL, code the PHP, integrate the form to talk to the PHP "backend" and update things, refresh and show the updates, etc...
...well, isn't that basically what most software dev work is, at the core? And if you can't do any of that...
Of course I got the position, and worked there for a couple of years; not the easiest environment I've ever been in, but certainly very interesting.
During it, though, I got to experience, from the "other side" what I went through - and I was amazed and dismayed to see how many people were interviewed who couldn't do it. Who had what seemed like great resumes who couldn't even start. Who'd sit there for 2+ hours, and not type a thing. Who didn't even google up something, or ask a question, or...
We had one guy sit for a while, then just got up and walked out without a word.
As I read comments like yours, and others elsewhere, I can see that this is more common than not. You are right to believe that there will be those that will "memorize" fizzbuzz, which I why I think a challenge similar to what Fender asked for is a better test. I know that some developers would balk at it, but I think the time invested may be worth it, to show you are able to do the job, and can come up with your own solution to a problem, and not just some regurgitated answer.
Interesting aside:
A colleague of mine I had worked with prior, unknown to me, applied for the same position at Fender and was given the same laptop as I did. But they had forgotten to wipe it! He saw my code, and didn't know if he was supposed to expand on it or what; he told them "hey, this looks like my friend's code...?" - and they realized what they forgot. They thanked him for his honesty, wiped it, and continued on with the process. He also ended up getting the position as well.
At the time, their marketing department did all of their web development in-house. I don't recall all the specifics; there was a round table meeting between the manager of the unit, the team lead, and one of the senior developers. At the end of it, they sat me in the cubicle area with their other developers, gave me an MBP with MAMP on it, and a piece of paper outlining what they wanted me to code - a simple CRUD app. It didn't have to have any fancy styling, but it had to look ok, and it had to work. It was "open book" otherwise; use google or whatever other resource as you needed it. Also, all this happened while the other devs were in the area; it was basically a time slot from 2:30pm to closing time...
I'm thinking - really? Something this basic...
But given what you had to do - essentially from a blank slate, including the database, set up the tables, build the SQL, code the PHP, integrate the form to talk to the PHP "backend" and update things, refresh and show the updates, etc...
...well, isn't that basically what most software dev work is, at the core? And if you can't do any of that...
Of course I got the position, and worked there for a couple of years; not the easiest environment I've ever been in, but certainly very interesting.
During it, though, I got to experience, from the "other side" what I went through - and I was amazed and dismayed to see how many people were interviewed who couldn't do it. Who had what seemed like great resumes who couldn't even start. Who'd sit there for 2+ hours, and not type a thing. Who didn't even google up something, or ask a question, or...
We had one guy sit for a while, then just got up and walked out without a word.
As I read comments like yours, and others elsewhere, I can see that this is more common than not. You are right to believe that there will be those that will "memorize" fizzbuzz, which I why I think a challenge similar to what Fender asked for is a better test. I know that some developers would balk at it, but I think the time invested may be worth it, to show you are able to do the job, and can come up with your own solution to a problem, and not just some regurgitated answer.
Interesting aside:
A colleague of mine I had worked with prior, unknown to me, applied for the same position at Fender and was given the same laptop as I did. But they had forgotten to wipe it! He saw my code, and didn't know if he was supposed to expand on it or what; he told them "hey, this looks like my friend's code...?" - and they realized what they forgot. They thanked him for his honesty, wiped it, and continued on with the process. He also ended up getting the position as well.
>then implement any kind of sort for an array, then implement depth-first-search.
How have you not grokked how useless those questions actually are when it comes to knowledge about writing software? Those are both trivia in the same category as "implement the TCP acking mechanism".
How have you not grokked how useless those questions actually are when it comes to knowledge about writing software? Those are both trivia in the same category as "implement the TCP acking mechanism".
Not my experience, as long as you're prepared to accept that people may need some prompting, and won't necessarily find the optimal solutions.
Someone who knows the 'trivia' may remember how to implement quicksort without actually being any good.
But someone with even a little bit of understanding and some prodding to not worry about efficiency will be able to come up with some sort of solution, even if bubblesort. If people appear truly petrified, it's easy to give them a chance by breaking down the problem and see if they can reason about it. E.g.whay if you start with a two element array? Then how about 3? How do you generalise that?
Someone with both the trivia and the smarts will give you a good solution and be able to muse about tradeoffs of different implementation methods, pivot selection and the like.
It's usually fairly simple to find out if people understand the solution they offer up and can reason about it, and that's often a lot more important than whether they come up with a great solution.
Someone who knows the 'trivia' may remember how to implement quicksort without actually being any good.
But someone with even a little bit of understanding and some prodding to not worry about efficiency will be able to come up with some sort of solution, even if bubblesort. If people appear truly petrified, it's easy to give them a chance by breaking down the problem and see if they can reason about it. E.g.whay if you start with a two element array? Then how about 3? How do you generalise that?
Someone with both the trivia and the smarts will give you a good solution and be able to muse about tradeoffs of different implementation methods, pivot selection and the like.
It's usually fairly simple to find out if people understand the solution they offer up and can reason about it, and that's often a lot more important than whether they come up with a great solution.
Re-implementing bubble-sort is, I think, a pretty reasonable fizzbuzz-style question. Can people think in loops.
Depth first search I would now be a little less eager to do (I was asking these questions ten years ago), but there were a few things that I felt came out well from it: if someone wrote something like:
if (DFS(node.left) || DFS(node.right)) return true else return false
That seems to me like it demonstrates at the very least some immaturity of how to write professional code. If the person doesn't know how to do recursion, that stands out. If they fundamentally don't know how to deal with a stack, that stands out.
If someone has never encountered DFS and just gets fundamentally stock on what the algorithm is at all, then that's, I agree, not wildly meaningful. But that was not, in general, a reason why people didn't get the DFS question.
EDIT: I will also note that I've had a couple of people on HN react with horror at the notion that someone might be asked to impelement DFS or BFS. While I agree that these aren't perfect questions, I think they're pretty radically different than some of the puzzle-y or impossible-to-re-derive questions that you sometimes hear about. The algorithm for DFS is:
1. Check to see if the input is null. If it is, return false. 2. Check to see if the input's value is the searched operand. If it is, return true. 3. Return DFS(left) || DFS(right)
Breadth-first is a tiny bit harder, but it's still a while loop on a queue and just test equality and push the children onto the queue. It's about ten lines of code and it's far from rocket science. If nobody ever taught you about binary trees at all, you might still be a great programmer. But if you're a good programmer, and you ever got taught about binary trees (which most people who have traditional backgrounds have), then you should be able to recreate those algorithms from first principles in, I don't know, 15-30 minutes.
Depth first search I would now be a little less eager to do (I was asking these questions ten years ago), but there were a few things that I felt came out well from it: if someone wrote something like:
if (DFS(node.left) || DFS(node.right)) return true else return false
That seems to me like it demonstrates at the very least some immaturity of how to write professional code. If the person doesn't know how to do recursion, that stands out. If they fundamentally don't know how to deal with a stack, that stands out.
If someone has never encountered DFS and just gets fundamentally stock on what the algorithm is at all, then that's, I agree, not wildly meaningful. But that was not, in general, a reason why people didn't get the DFS question.
EDIT: I will also note that I've had a couple of people on HN react with horror at the notion that someone might be asked to impelement DFS or BFS. While I agree that these aren't perfect questions, I think they're pretty radically different than some of the puzzle-y or impossible-to-re-derive questions that you sometimes hear about. The algorithm for DFS is:
1. Check to see if the input is null. If it is, return false. 2. Check to see if the input's value is the searched operand. If it is, return true. 3. Return DFS(left) || DFS(right)
Breadth-first is a tiny bit harder, but it's still a while loop on a queue and just test equality and push the children onto the queue. It's about ten lines of code and it's far from rocket science. If nobody ever taught you about binary trees at all, you might still be a great programmer. But if you're a good programmer, and you ever got taught about binary trees (which most people who have traditional backgrounds have), then you should be able to recreate those algorithms from first principles in, I don't know, 15-30 minutes.
In my experience, the sweet spot is anything that involves recursion or pointers, preferably in combination. You get some false negatives, but not tons if you don’t disqualify non-elegant solutions.
a series of easy-medium-hard to gauge where someone is at might be that 'sweet spot' - there's not one question that would cover enough, although I think fizzbuzz tries to.
What do you mean by Fizzbuzz? Normal fizzbuzz or the pointless overengineering fizzbuzz?
This is incredible to me. How can one get to senior or middle software engineering positions without the ability to write such trivial code?
It was incredible to me too. But it’s reality.
As another poster said above, best guess is some version of copypasta and navigation of bureaucracy.
As another poster said above, best guess is some version of copypasta and navigation of bureaucracy.
TechLead said it best IMO. If a developer cannot understand basic concepts like recursion, then they are in the wrong industry.
It does seem incredible, but it happens.
One place I worked at, the company hired a developer who claimed to have a CompSci masters.
He was completely unable to code anything. I thought it strange.
I started to ask him some basic questions that any actual CompSci degree holder should be able to answer (and I don't have a degree in CompSci at all - everything I know I've learned on my own, from other sources, for the most part); I didn't make it like a grilling session, just polite conversation about a shared interest - but he either had difficulty, or couldn't answer at all.
He only stuck around a couple of weeks.
I've often joked that an interview question should be asked akin to "What basic logic function is needed to implement a computer? Show it's truth table, then design one in 2-dimensions on a whiteboard as a virtual 'rope-and-pulley' system."
Couple that with a random-style fizzbuzz-like challenge, and maybe a more difficult open-ended programming challenge (ie "build a simple CRUD app") - that would give you a good idea on their real skills.
Note: That first question I wouldn't expect many to be able to pass the last part; even the first two parts many perfectly capable developers would have difficulty with. But I would be disappointed if they claimed to have a CS degree and weren't able to at least tell me what it was and the truth table for it.
One place I worked at, the company hired a developer who claimed to have a CompSci masters.
He was completely unable to code anything. I thought it strange.
I started to ask him some basic questions that any actual CompSci degree holder should be able to answer (and I don't have a degree in CompSci at all - everything I know I've learned on my own, from other sources, for the most part); I didn't make it like a grilling session, just polite conversation about a shared interest - but he either had difficulty, or couldn't answer at all.
He only stuck around a couple of weeks.
I've often joked that an interview question should be asked akin to "What basic logic function is needed to implement a computer? Show it's truth table, then design one in 2-dimensions on a whiteboard as a virtual 'rope-and-pulley' system."
Couple that with a random-style fizzbuzz-like challenge, and maybe a more difficult open-ended programming challenge (ie "build a simple CRUD app") - that would give you a good idea on their real skills.
Note: That first question I wouldn't expect many to be able to pass the last part; even the first two parts many perfectly capable developers would have difficulty with. But I would be disappointed if they claimed to have a CS degree and weren't able to at least tell me what it was and the truth table for it.
shit, I'd have to look up NAND gates. also: that's EE, not CS.
There's actually two acceptable answers for the question...
I should note that my statements below may be FOC; I do not myself have a CS or EE degree, so take what I say with a modicum of salt...
But first, note that I wrote "function", not "circuit".
It could be argued that CS, on the whole, is a subset of mathematics, particularly that of boolean algebra and logic. As such, the functional equivalency between the abstract of boolean logic/algebra, and its implementation on a physical substrate, could be considered among the most important of CS concepts.
One could also argue (maybe?) that Turing's "equivalency theorem" might be related to such as well. Consider the case of an emulation of hardware done in software; one could consider that - at a base level, it is boolean logic expressed physically, being expressed equivalently as boolean software functions.
The opposite it also true, of course - that it is possible to express software boolean functionality in the equivalent physical form.
What form it physically takes does not matter (other than speed of course), which is why I also didn't ask for an implementation/representation in electrical terms or schematic form, but rather a diagram of something that could be expressed as a physical and mechanical object. If the person were so inclined, they could express it as a series of levers and marbles, or in LEGO, or Meccano, or any other similar option.
EE knowledge is not needed here, I don't believe (Martin Gardner might agree).
I should note that my statements below may be FOC; I do not myself have a CS or EE degree, so take what I say with a modicum of salt...
But first, note that I wrote "function", not "circuit".
It could be argued that CS, on the whole, is a subset of mathematics, particularly that of boolean algebra and logic. As such, the functional equivalency between the abstract of boolean logic/algebra, and its implementation on a physical substrate, could be considered among the most important of CS concepts.
One could also argue (maybe?) that Turing's "equivalency theorem" might be related to such as well. Consider the case of an emulation of hardware done in software; one could consider that - at a base level, it is boolean logic expressed physically, being expressed equivalently as boolean software functions.
The opposite it also true, of course - that it is possible to express software boolean functionality in the equivalent physical form.
What form it physically takes does not matter (other than speed of course), which is why I also didn't ask for an implementation/representation in electrical terms or schematic form, but rather a diagram of something that could be expressed as a physical and mechanical object. If the person were so inclined, they could express it as a series of levers and marbles, or in LEGO, or Meccano, or any other similar option.
EE knowledge is not needed here, I don't believe (Martin Gardner might agree).
> One could also argue (maybe?) that Turing's "equivalency theorem"
lol wat
did you talk like this to the CS masters, no wonder they left
lol wat
did you talk like this to the CS masters, no wonder they left
I once worked in a place where they wanted to hire a few contractors to help out, and I had to help phone-interview a few. I remember one guy whose resume claimed he was an expert in C++, so I simply asked him to tell me what a "class" was in C++. He couldn't answer.
I think some people's typical coding is call one API, and then send the result to another API, or just print it out. They never need to write anything like a loop or logic.
I think some just have outdated skills and don't know how in the environments they're faced with.
Sometimes people move between senior eng. and management positions and back depending on organization sizes. I certainly have had engineering manager positions where I went several years without needing to code for my job. If I'd stayed longer and not coded for fun, and then gone on to the type of positions I did next, which were much more hands on, and using different labguages I can imagine I might have found it hard.
Thankfully I've always enjoyed programming on side projects too, so staying up to date has never felt like a chore.
Sometimes people move between senior eng. and management positions and back depending on organization sizes. I certainly have had engineering manager positions where I went several years without needing to code for my job. If I'd stayed longer and not coded for fun, and then gone on to the type of positions I did next, which were much more hands on, and using different labguages I can imagine I might have found it hard.
Thankfully I've always enjoyed programming on side projects too, so staying up to date has never felt like a chore.
Are there a lot of senior people who don't interview? Fortunately most of my candidates have been at least marginal, but the first couple of useless ones years ago were all it took to convince me that we can't ever skip coding questions.
My frustration is that this is the only industry I know of that makes you perform a pre-hiring test. Can you imagine if a construction worker had 1 hour to assemble a dog house as proof that he can build?
The problem is there are a lot of people who are still good coders who suck at white-boarding for one reason or another. I became one of them due a combination of age, rustiness and an escalation of nervousness after failing a couple whiteboards out of the gate.
Of course once I did land a job it took about a week to shake off the rustiness, and the company that hired me is thrilled.
The point is that companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough, not trying to mimic the FAANGs and getting their leftovers.
Of course once I did land a job it took about a week to shake off the rustiness, and the company that hired me is thrilled.
The point is that companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough, not trying to mimic the FAANGs and getting their leftovers.
You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.
What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs.
As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details.
Thinking coding is important is a failure mode.
As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details.
Thinking coding is important is a failure mode.
FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews).
The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something.
And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with.
To see the second thing, I need to see concrete code.
The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something.
And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with.
To see the second thing, I need to see concrete code.
When I'm interviewing experienced people, I usually gauge technical skill by picking something out of their resume and digging into it with questions. If they don't really understand what happened technically, it's immediately apparent (this is also how you catch inflated resumes). And if they do, I can just keep asking more questions to get a better sense of it.
This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.
This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.
> This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.
But being able to map the macro to the micro is a vital part of being a competent SWE. This includes being an architect. If your plan only considers macro-issues, but is difficult to actually implement on a small scale, its not a good plan.
I want to gauge both, and a coding test is a good way to measure the micro.
But being able to map the macro to the micro is a vital part of being a competent SWE. This includes being an architect. If your plan only considers macro-issues, but is difficult to actually implement on a small scale, its not a good plan.
I want to gauge both, and a coding test is a good way to measure the micro.
Yeah this is much better.
This guy has the right approach imo: https://www.karllhughes.com/posts/rethinking-hiring
This guy has the right approach imo: https://www.karllhughes.com/posts/rethinking-hiring
Thanks for sharing! I read this post and thought the same thing.
I'm honestly nervous that next time I have to go out and interview, I'll be in the same shoes as OP. Despite many years of managing software for small companies, I have no desire to go back and re-learn Leetcode just to get a job.
I'm honestly nervous that next time I have to go out and interview, I'll be in the same shoes as OP. Despite many years of managing software for small companies, I have no desire to go back and re-learn Leetcode just to get a job.
One problem I have is at my level it's really more about architecting than coding. Although coding is still important.
(And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.)
But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems.
It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.
(And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.)
But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems.
It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.
> It also takes a good architect to interview an architect
And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively.
As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.
And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively.
As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.
Why is this getting downvoted?
Because I keep calling the coding test mentality "nonsense".
I think the most valuable engineering leader would be someone who can remove code, or at least prevent unnecessary code from being written and maintained.
Code is a liability as much as it is an asset.
Code is a liability as much as it is an asset.
Yeah but then inevitably the company starts grading on a curve. Did the dev nail every single possible mistake or bug? Did they add any extra flourishes? So you're not just testing for basic competence anymore. You're testing for devs who are really good at timed coding challenges - just like with challenges where it's tough to get the right answer in the allotted time.
Companies don't get excited about a dev who just passes. Even though that dev might be by far the best candidate - they just need a few days to chew on various architectures - or they take the test literally and don't add bells and whistles. Etc.
Companies get excited about a dev who aces it with flying colors.
Companies don't get excited about a dev who just passes. Even though that dev might be by far the best candidate - they just need a few days to chew on various architectures - or they take the test literally and don't add bells and whistles. Etc.
Companies get excited about a dev who aces it with flying colors.
That's what FB does these days: how fast can one code, how bug free, etc.
> inevitably the company starts grading on a curve
which explains the paradox of too many developers chasing too few jobs versus all these companies complaining that they cannot find enough good developers
which explains the paradox of too many developers chasing too few jobs versus all these companies complaining that they cannot find enough good developers
There's also a lot of senior devs who think they are a false negative who are not.
I speak from personal experience. I failed my first FAANG style interview both because I had not prepared nor understood how white board interviews really work and because a huge subset of my skill had gotten rusty over the years. But when I first failed I was really upset and very quickly wrote off the entire process as a ridiculous test. Looking back I was a true negative and needed to brush up on a range of skills.
When I was a junior dev I spent nearly all my time studying programming, CS and software. But as I got more senior I definitely relaxed a bit on all of that and coasted more on the inertia of past successes than I should have. Yes I was good at my current job, and the ones before it, but those only represent a small subset of the skills a senior engineer should have. What made me a great engineer in one specific company allowed me to let other skills that I wasn't using decline a bit.
By being a bit more honest with myself I spent a long time getting back into the things that I used to love and also learned how to practice whiteboards. All my white board interviews after that were a success.
I think a huge push back by senior devs against these interviews is that they don't want to admit that, while they have gained a ton of valuable experience, they might not be as strong of a software engineer as they once were.
I speak from personal experience. I failed my first FAANG style interview both because I had not prepared nor understood how white board interviews really work and because a huge subset of my skill had gotten rusty over the years. But when I first failed I was really upset and very quickly wrote off the entire process as a ridiculous test. Looking back I was a true negative and needed to brush up on a range of skills.
When I was a junior dev I spent nearly all my time studying programming, CS and software. But as I got more senior I definitely relaxed a bit on all of that and coasted more on the inertia of past successes than I should have. Yes I was good at my current job, and the ones before it, but those only represent a small subset of the skills a senior engineer should have. What made me a great engineer in one specific company allowed me to let other skills that I wasn't using decline a bit.
By being a bit more honest with myself I spent a long time getting back into the things that I used to love and also learned how to practice whiteboards. All my white board interviews after that were a success.
I think a huge push back by senior devs against these interviews is that they don't want to admit that, while they have gained a ton of valuable experience, they might not be as strong of a software engineer as they once were.
This is such a great response and I've had similar experiences. As you become more senior you also get more managerial responsibilities which can eat into your time/energy budget to stay up to date on tech not directly related to your job. You may also get more life responsibilities as you age (family...) that further erode your technical edge.
Good on you for having the introspective skills and awareness to identify the problem and do something about it.
Good on you for having the introspective skills and awareness to identify the problem and do something about it.
I don't understand how this is a problem? If OP is a Senior Dev and interviewing for another Senior Dev role, wouldn't you assume that this new role is probably going to require similar skills to perform similar managerial type responsibilities?
I mean, sure go ahead and prepare for interviewing, brush up on whatever you think will help. But if a company has a policy of consistently rejecting candidates based on testing of skills that are never used on the job, it sounds like there's a lot of room to improve that interview process.
I mean, sure go ahead and prepare for interviewing, brush up on whatever you think will help. But if a company has a policy of consistently rejecting candidates based on testing of skills that are never used on the job, it sounds like there's a lot of room to improve that interview process.
A lot of time people will move to a new job for a more senior position than their current job. Being a Sr. Engineer at a Series A funded startup can be very different than being a Sr. Engineer at Facebook (not always, but often). I would expect a higher bar at a larger engineering organization.
If someone is effectively testing for these more difficult subject matters then it's quite possible that they themselves and other co-workers are competent in them (as they passed the same test).
If someone is effectively testing for these more difficult subject matters then it's quite possible that they themselves and other co-workers are competent in them (as they passed the same test).
For sure I wasn't the software developer I once was when I was interviewing. I'd been in an architect role at a gargantuan company and mostly POCing things for a few years. Then I went on a 7 month road trip where the majority of my brain was dedicated to learning Spanish.
However I can confidently say that it only took a few weeks of being thrown back in the mix to shake the rust off and get going again.
If I was an employer and could extend contracts at fairly low risk, I'd give devs with a strong resume and a demonstrable open-source library a chance - despite them being a bit shaky on the whiteboard.
However I can confidently say that it only took a few weeks of being thrown back in the mix to shake the rust off and get going again.
If I was an employer and could extend contracts at fairly low risk, I'd give devs with a strong resume and a demonstrable open-source library a chance - despite them being a bit shaky on the whiteboard.
I don't think any good senior devs are under the illusion (privately) that they're rusty at whiteboard interviews. I'm certain my college grad self fresh out of practicing for the ACM contests could have run circles around my recent job search self when it comes to algorithm stuff. I had to practice and then pass a ton of whiteboard rounds to get my current senior developer job, so I'm not saying this out of bitterness.
However, and I think this is the crux of the problem, you're not paying senior developers for that. I've never had to actually do any algorithm slinging on this job. The fanciest it usually gets is chaining some maps and filters.
On the other hand, I have had to do "rocket surgery" on critical path legacy code, write business logic in a maximally predictable and readable way, figure out how to land a non-backwards compatible change with no downtime, convince other teams to help with an initiative my team is leading, design an internal API, etc.
Doing that stuff requires experience, rigor, resourcefulness, and I'm sure you can come up with more "senior" traits. My personal complaint about whiteboard interviews, even systems design interviews, is that they only indirectly measure those traits.
However, and I think this is the crux of the problem, you're not paying senior developers for that. I've never had to actually do any algorithm slinging on this job. The fanciest it usually gets is chaining some maps and filters.
On the other hand, I have had to do "rocket surgery" on critical path legacy code, write business logic in a maximally predictable and readable way, figure out how to land a non-backwards compatible change with no downtime, convince other teams to help with an initiative my team is leading, design an internal API, etc.
Doing that stuff requires experience, rigor, resourcefulness, and I'm sure you can come up with more "senior" traits. My personal complaint about whiteboard interviews, even systems design interviews, is that they only indirectly measure those traits.
Saying that "you're not payed for that" is risky. Yes, you're technically right but when you will be at your new fancy job you may need to do MANY things that you aren't technically being payed to do, so that you can deliver. That IMO is one of the essential skills a senior developer has, not that they can do things a junior developer can't, but that they have a breath of knowledge and skills that make them good junior developers at many things they aren't specialized for and are able to make use of them to get the job done. In that light, picking on "one little thing" such as the interview process using something you may not be used to or like or ever need to do when actually hired (whiteboard coding), seems wrong.
I don't think I understand your point. I was talking about how algorithms interviews map badly to the skills required by the job description. That's only tangentially related to whether you'll have to do things outside the strict job description.
My philosophy when hiring now is to be trying to answer the question of “how much responsibility could I give this candidate and feel confident they could flourish”. A junior engineer should be able to be given a clear spec and be able to implement it. A mid should be able to do the same thing with a poorly specified spec, in a domain they don’t necessarily have experience in. They should know how to learn. A good senior should be able to support a team to figure out what needs to be done, and move heaven and earth to get there. They should be able to fix (and anticipate) any and all problems that show up. Train people. And push back when they’re assigned a problem that doesn’t make sense, or given unreasonable deadlines. A good senior can be responsible for making sure a whole team delivers a working product.
From this perspective, a technical whiteboard interview is one of many tools. Interviews I give usually start with “so your boss asks you to solve problem X ... where do you start?”. Then I throw more and more problems at them (technical, organisational, etc) and see how they respond. “It’s in production and people start complaining that it’s slow. Where do you look first?”. “What problems do you foresee with this design down the line?”. “If you had $1m/yr budget to hire a team to scale this system, what would your ideal team look like? How would you spend the money?”. “An inexperienced team implements this and it’s buggy. What mistakes are you worried they might have made?”
Ultimately we get the traits we hire for. Being able to code (and debug!) is important. But I also want employees who I can delegate to, and trust that they’ll figure things out. I’ve been able to pass whiteboard interviews since second year uni. But I have not stopped learning, and the non technical skills I’ve gained since then are at least as important. Test for them.
From this perspective, a technical whiteboard interview is one of many tools. Interviews I give usually start with “so your boss asks you to solve problem X ... where do you start?”. Then I throw more and more problems at them (technical, organisational, etc) and see how they respond. “It’s in production and people start complaining that it’s slow. Where do you look first?”. “What problems do you foresee with this design down the line?”. “If you had $1m/yr budget to hire a team to scale this system, what would your ideal team look like? How would you spend the money?”. “An inexperienced team implements this and it’s buggy. What mistakes are you worried they might have made?”
Ultimately we get the traits we hire for. Being able to code (and debug!) is important. But I also want employees who I can delegate to, and trust that they’ll figure things out. I’ve been able to pass whiteboard interviews since second year uni. But I have not stopped learning, and the non technical skills I’ve gained since then are at least as important. Test for them.
FWIW - I'm not talking about no demonstration of coding ability at all. I'm just saying don't always assume the person who aces the coding challenge with time to spare is going to be a much better candidate for the job vs. say a dev with an interesting resume and orally demonstrated problem-solving skills - who just passed the coding challenge.
Your argument basically boils down to that you think your experience is the norm and OP's is the outlier.
Even FANGS need developers who can get stuff done to make up for all the JIRA jockeys.
> companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough
I'd say it's the opposite. Big companies can afford to take a shot on someone and miss without materially impacting the business.
If I'm hiring developer #2 at my 5 person startup, I want someone confident and cool under pressure who has done something similar to what I'm building so many times in real life that the coding test is a cake walk.
A dev hire on a small engineering team (< 5 people) can make or break the business. I'm trying to de-risk that hire as much as possible. I want to design a test that 90% of people will fail so I can find that top 10% developer.
Once I get to 15-20+ devs, I'm much more likely to relax my criteria and look for a diamond in the rough.
I'd say it's the opposite. Big companies can afford to take a shot on someone and miss without materially impacting the business.
If I'm hiring developer #2 at my 5 person startup, I want someone confident and cool under pressure who has done something similar to what I'm building so many times in real life that the coding test is a cake walk.
A dev hire on a small engineering team (< 5 people) can make or break the business. I'm trying to de-risk that hire as much as possible. I want to design a test that 90% of people will fail so I can find that top 10% developer.
Once I get to 15-20+ devs, I'm much more likely to relax my criteria and look for a diamond in the rough.
I agree. Hiring has both a non-trivial time and money cost. The very same companies that would benefit from finding diamonds in the rough usually don't have the resources to find these devs in the first place. The modern coding interview is designed for the processes and needs of larger tech cos with large amounts of resources. Cargo cult at your own discretion.
This is reasonable from your vantage point. But why should that talented person work for your fledgling startup? Wouldn't he or she have more options on the table?
Absolutely. Then it's all about selling the team, the company and it's potential. If you can't sell your vision to your employees you probably won't be able to sell to your customers either.
yes. also factor in the probability of receiving a huge number of qualified applicants: for Google it is as close to 1 as it is for any company. for the startup it's far lower. Google does not need to take these risks.
There exist automated processes[0] that efficiently reject such candidates - no need to bother staff with doing the same manually.
[0] https://www.codility.com/
[0] https://www.codility.com/
Soo ... not sure if you read the article, but that's exactly what it was discussing.
The article is down.
It's funny, the worst engineer I ever hired did great on our Codility tests. Maybe he just cheated, he actually scored higher than myself. Just a little anecdote but we no longer use Codility at my company. :)
[deleted]
> And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.
Seriously, Where are you finding these candidates? seriously.
I've worked at a number of mid-sized companies, and interviewed dozens of candidates, and I have never, ever, ever come across a candidate that couldn't write code on this level: "write a function that adds two numbers or counts the number of elements in a list".
Seriously, Where are you finding these candidates? seriously.
I've worked at a number of mid-sized companies, and interviewed dozens of candidates, and I have never, ever, ever come across a candidate that couldn't write code on this level: "write a function that adds two numbers or counts the number of elements in a list".
It happens if you don't do phone screens. People lie on their resumes.
This. I can't trust your résumé at all, but it does tell me what you think should be reasonable to ask.
Crappy head hunters. I have some outside firms who have sent me good people very reliably, and then once in a while HR will make me try another company who probably gave us a cheap quote, and I'll get a series of terrible candidates from them. I've even been given outright frauds -- people who paid someone else to phone screen for them.
Cut and paste answers to initial screening questions was my favorite. How I knew they were cut and pasted? I got paranoid after some suspicious answers and started doing searches for random lines from the answers.
The included such brilliant things as cut and pasting an answer from a forum that was followed by a dozen comments of people explaining how wrong that answer was, and someone who answered what should have needed a short sentence with two pages from an Oracle manual giving an answer that did not apply to the question. .
It's not that we expected everyone to be honest about not using Google - it didn't matter, it was an initial screening question. But we did expect them to at least bother to restate the answer in their own words if they looked it up. And get it right..
The included such brilliant things as cut and pasting an answer from a forum that was followed by a dozen comments of people explaining how wrong that answer was, and someone who answered what should have needed a short sentence with two pages from an Oracle manual giving an answer that did not apply to the question. .
It's not that we expected everyone to be honest about not using Google - it didn't matter, it was an initial screening question. But we did expect them to at least bother to restate the answer in their own words if they looked it up. And get it right..
I've used simple problems 'write a function to give me a maximum from a list' and 'provide a list of test scenarios to validate this function'.
This has a surprisingly high failure rate even in cases where we just email it to the candidate and discuss in a phone interview the next day. I don't think it has anything to do with a persons ability to program but likely derives from a person's ability to understand a work request.
This has a surprisingly high failure rate even in cases where we just email it to the candidate and discuss in a phone interview the next day. I don't think it has anything to do with a persons ability to program but likely derives from a person's ability to understand a work request.
It's generally a lack of problem solving skills in my experience. The main coding question I ask is actually a short word problem (less than 4 sentences for the entire problem statement).
Without giving away the question I ask, I can tell you the solution is a for loop and an if statement. If I told them exactly what they needed to solve the problem, I'm sure most could write the code (though honestly some would have still failed). It's a question I would think could fit as one of 5 on an intro to programming class final, yet I've had candidates with 10+ years of experience fail it. I even had one such candidate argue with me over asking a coding question when his resume shows so much experience at different roles.
Without giving away the question I ask, I can tell you the solution is a for loop and an if statement. If I told them exactly what they needed to solve the problem, I'm sure most could write the code (though honestly some would have still failed). It's a question I would think could fit as one of 5 on an intro to programming class final, yet I've had candidates with 10+ years of experience fail it. I even had one such candidate argue with me over asking a coding question when his resume shows so much experience at different roles.
I've come across them repeatedly and in some cases they have formed the majority of candidates that got to a phone screen. It's a result of our industry having many high paying jobs in relative physical comfort with no hard gatekeepers. Can you imagine what interviewing for a first year law associate's position at a BigLaw firm or a radiology residency would be like if there were no law and med schools and no board certifications?
Considering the rate of false positives in any software engineering interview process there is every incentive for the underqualified and unqualified to "fake it 'til they make it". It's also difficult to tell the difference between someone failing upwards and someone aggressively managing their career by switching positions with lateral raises in this hot job market, hence the need to distrust the skill of even senior developers and force this rigmarole on every level of engineering talent.
Considering the rate of false positives in any software engineering interview process there is every incentive for the underqualified and unqualified to "fake it 'til they make it". It's also difficult to tell the difference between someone failing upwards and someone aggressively managing their career by switching positions with lateral raises in this hot job market, hence the need to distrust the skill of even senior developers and force this rigmarole on every level of engineering talent.
"I need a function to add two numbers together."
Innumeracy is the norm: I'd guess > 85% of people don't understand the concept of a function.
And they probably can code if they were working independently. Or they've done some classes, wathced some videos and think they understand it.
But when you add the pressure of an interview, your unpracticed skills fall apart. Also, you have to think on your feet to fill in the blanks in a question.
That's how it should be, because we're not hiring hobbyists; candidates need to be able to demonstrate that they're pros, and able to do so under the pressure of an interview.
I've done my share of phone screens who were flatly unqualified as developers. (Thankfully we've never had someone completely clueless land an in-person interview. That's also a disservice to the candidate as we should provide better guidance through the phone screen.)
Some of them are junior, possibly they lie on their resume and simply keep applying to job after job. That's the 99% that Joel wrote about[1].
You also occasionally get guys who were in management or similar roles and are looking to transition to being engineers. And I think these may have a similar problem to the senior engineers: they have lost the skill (or never had it) and are finding out the hard way.
[1]: https://www.joelonsoftware.com/2005/01/27/news-58/
Innumeracy is the norm: I'd guess > 85% of people don't understand the concept of a function.
And they probably can code if they were working independently. Or they've done some classes, wathced some videos and think they understand it.
But when you add the pressure of an interview, your unpracticed skills fall apart. Also, you have to think on your feet to fill in the blanks in a question.
That's how it should be, because we're not hiring hobbyists; candidates need to be able to demonstrate that they're pros, and able to do so under the pressure of an interview.
I've done my share of phone screens who were flatly unqualified as developers. (Thankfully we've never had someone completely clueless land an in-person interview. That's also a disservice to the candidate as we should provide better guidance through the phone screen.)
Some of them are junior, possibly they lie on their resume and simply keep applying to job after job. That's the 99% that Joel wrote about[1].
You also occasionally get guys who were in management or similar roles and are looking to transition to being engineers. And I think these may have a similar problem to the senior engineers: they have lost the skill (or never had it) and are finding out the hard way.
[1]: https://www.joelonsoftware.com/2005/01/27/news-58/
I simply can't get behind the idea that having someone whiteboard an algorithm is analogous to either their programming skill or their ability to work within a company. I spend a minuscule fraction of my time writing algorithms in my daily practice, most of my time is spent integrating disparate technologies, data wrangling, and working across teams to get the information I need to make our product. Clearly there needs to be some vetting of someone's skill, but problem solving and troubleshooting are way more valued skills in my group than the ability to write a fibonacci sequence on the whiteboard. I have had far better success asking questions around diagnostic process and troubleshooting to find talented devs than I ever did using whiteboard like tests.
> I simply can't get behind the idea that having someone whiteboard an algorithm is analogous to either their programming skill or their ability to work within a company.
It's not an analog. It's the actual skill up close. They should be explaining their thoughts as they go, and you're asking why they do A instead of B.
> I spend a minuscule fraction of my time writing algorithms in my daily practice
A good problem isn't simply an algorithm, but also tests how they break a problem down, how they compose a solution, how they think through engineering tradeoffs, and how they communicate all this to you.
Consider the difference between an artist and an amateur painter. That the artist has practiced brush strokes is not surprising, anyone can practice painting a lot. What really matters is the artist can take the image in their mind and composing it into a complete scene and then express it all that through their medium of choice.
> but problem solving and troubleshooting are way more valued skills in my group
Is that a good thing? If your group wrote better code, wouldn't they have less troubleshooting to do?
Yes, that's a tautology, but I've worked on code that was kludges on top of kludges. And while kludges can be inevitable, if they persist, it indicates the person doesn't have the mastery to see a better way to express a problem. That's a skill deficit.
When I'm analyzing someone's ability to code, I'm presenting it as a problem to solve. We solve problems by restating them in such a way that the solution falls naturally from the question.
The candidates who can do this well will put together well structured, coherent code, and my team will spend more time delivering features and less time troubleshooting.
It's not an analog. It's the actual skill up close. They should be explaining their thoughts as they go, and you're asking why they do A instead of B.
> I spend a minuscule fraction of my time writing algorithms in my daily practice
A good problem isn't simply an algorithm, but also tests how they break a problem down, how they compose a solution, how they think through engineering tradeoffs, and how they communicate all this to you.
Consider the difference between an artist and an amateur painter. That the artist has practiced brush strokes is not surprising, anyone can practice painting a lot. What really matters is the artist can take the image in their mind and composing it into a complete scene and then express it all that through their medium of choice.
> but problem solving and troubleshooting are way more valued skills in my group
Is that a good thing? If your group wrote better code, wouldn't they have less troubleshooting to do?
Yes, that's a tautology, but I've worked on code that was kludges on top of kludges. And while kludges can be inevitable, if they persist, it indicates the person doesn't have the mastery to see a better way to express a problem. That's a skill deficit.
When I'm analyzing someone's ability to code, I'm presenting it as a problem to solve. We solve problems by restating them in such a way that the solution falls naturally from the question.
The candidates who can do this well will put together well structured, coherent code, and my team will spend more time delivering features and less time troubleshooting.
Same. I've never had someone come in for a face-to-face interview that literally couldn't code at all. I've worked at and interviewed loads of people from small startups all the way up to a top 5 US tech giant. Still have never came across that case.
> The vast majority of applicants cannot code at all.
I've been interviewing devs for years, and this is not my experience at all. The vast majority of applicants that I've interviewed can code, although they tend to be minimally competent at it.
I've been interviewing devs for years, and this is not my experience at all. The vast majority of applicants that I've interviewed can code, although they tend to be minimally competent at it.
You're probably using a different definition of "whiteboard problem" than is common for what is used a places like Google/Facebook/etc.
I agree with you 100% if "whiteboard problem" means, sit with them while they type up a function in an IDE that does something common (e.g. validates a string, implements some error handling, do a failure backoff, etc).
I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.
I agree with you 100% if "whiteboard problem" means, sit with them while they type up a function in an IDE that does something common (e.g. validates a string, implements some error handling, do a failure backoff, etc).
I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.
> I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.
From an interviewing perspective, asking someone to "solve" this kind of problem on a whiteboard would be interesting to see.
One thing I'd tell them is to not worry about the code; that is, if they just want to write the process in pseudocode or something like that - as long as the logic can be followed, that would be ok. In other words, give them the leeway to not worry about proper coding, knowledge of functions, etc - but instead let them concentrate on the problem.
I wouldn't expect anyone to solve such a question - but it would give a good insight into how they go about solving a problem. Do they ask questions? What happens when they get stuck? Can they explain their reasoning? And so forth.
Let them do what they can, give them 30 minutes or so; if they look lost, ask them some questions, see how they respond, etc.
I think such a question could be very valuable - if presented in the right way.
From an interviewing perspective, asking someone to "solve" this kind of problem on a whiteboard would be interesting to see.
One thing I'd tell them is to not worry about the code; that is, if they just want to write the process in pseudocode or something like that - as long as the logic can be followed, that would be ok. In other words, give them the leeway to not worry about proper coding, knowledge of functions, etc - but instead let them concentrate on the problem.
I wouldn't expect anyone to solve such a question - but it would give a good insight into how they go about solving a problem. Do they ask questions? What happens when they get stuck? Can they explain their reasoning? And so forth.
Let them do what they can, give them 30 minutes or so; if they look lost, ask them some questions, see how they respond, etc.
I think such a question could be very valuable - if presented in the right way.
The number of people I've had fail simple questions (not binary node problems, I mean problems where the optimal solution is basically a for loop with an if statement) is absolutely insane. I would say at least 50% of applicants fail to solve the coding question, and this is interviewing for a 100k+ US job in medium sized city (so low cost of living, and good salary for the area).
We have 'hard' questions in our pool we can ask (where optimization actually comes into play) but I've found that the easy questions weed out so many candidates it's not worth it. There's no room for debate if someone tries to write 15+ if statements rather than creating a loop and one if statement.
We have 'hard' questions in our pool we can ask (where optimization actually comes into play) but I've found that the easy questions weed out so many candidates it's not worth it. There's no room for debate if someone tries to write 15+ if statements rather than creating a loop and one if statement.
"The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list."
I'm genuinely curious how you manage to find all these folks. I've been on the interview team at my company for a several years now(mostly in house, some first pass phone screens) and I've never encountered a single person who was literally unable to code a trivial problem. The last time I met a "programmer" who couldn't code was first semester university, and I thought most of them quickly flunked out/changed majors. I wonder if there is something about your company/recruiting process that is particularly attractive to them, or if our prescreen(which I'm admittedly no expert on) is just particularly good at filtering them out, or if there's some other explanation.
I'm genuinely curious how you manage to find all these folks. I've been on the interview team at my company for a several years now(mostly in house, some first pass phone screens) and I've never encountered a single person who was literally unable to code a trivial problem. The last time I met a "programmer" who couldn't code was first semester university, and I thought most of them quickly flunked out/changed majors. I wonder if there is something about your company/recruiting process that is particularly attractive to them, or if our prescreen(which I'm admittedly no expert on) is just particularly good at filtering them out, or if there's some other explanation.
I've performed close to 400 screening interviews now for a range of companies. There's a good chunk of people that struggle to write a solution that correctly compiled to an "aggregate this data" style problem. People with the "correct" CV that have made it through the HR filter. It's a real problem.
There are people who overestimate their ability. For example, I've worked with a very junior programmer (too junior for a good whiteboarding performance) who took extensive notes about everything, appeared to learn quickly, was probably convinced that he was learning, but performed poorly because he failed to think enough.
I saw him do SQL joins on the wrong column, cause accidents in source control, lose changes because he wasn't looking at the file and folder names on screen, and so on. Hard to realize for him, and hard to guess in an interview.
I saw him do SQL joins on the wrong column, cause accidents in source control, lose changes because he wasn't looking at the file and folder names on screen, and so on. Hard to realize for him, and hard to guess in an interview.
I've also been doing interviews for a few years at three different companies, and I've encountered it. It depends heavily on the quality of the recruiter. Good recruiters will attempt to filter out complete duds, bad recruiters will pack a clown car full of "rockstar candidates" that just wasted my time. There was one particularly bad instance where a guy with 10 years of experience and a masters degree got stuck for an hour trying to write a for loop. With unfettered access to Google.
Sounds like you don't phone screen.
I've screened people like you describe, but the only time I've interviewed them face-to-face was when they didn't have a technical phone screen for whatever reason.
FWIW, one of the ways I screen companies when I'm looking is whiteboard problems. I refuse them and move on. In my experience, only HugeCos and places with problems use them. I'm sure that's not true, but I have a necessarily small sample-size, and skipping over firms that do it has worked well for me so far, and there are plenty of fish in the sea. (I do in fact suck at writing on whiteboards, I just don't consider it a skill worth developing to pursue jobs I probably don't want.)
I've screened people like you describe, but the only time I've interviewed them face-to-face was when they didn't have a technical phone screen for whatever reason.
FWIW, one of the ways I screen companies when I'm looking is whiteboard problems. I refuse them and move on. In my experience, only HugeCos and places with problems use them. I'm sure that's not true, but I have a necessarily small sample-size, and skipping over firms that do it has worked well for me so far, and there are plenty of fish in the sea. (I do in fact suck at writing on whiteboards, I just don't consider it a skill worth developing to pursue jobs I probably don't want.)
FTFY:
Absolutely untrue in my experience, I can't speak for other people. To imply that this is absolutely untrue in the global space would require that I have interviewed everyone.
Whiteboard problems absolutely do work in my interviews. Again, use of the word absolute indicates that I've never interviewed without a whiteboard. Given the high number of candidates I've interviewed, this might indicate a flaw in the interview process.
The vast majority of applicants I select for interviews cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. I should consider the possibility that I'm selecting the wrong people for interviews.
Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. Clearly other companies are making the same mistakes I am making in their candidate selection process.
How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.
Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.
Source: I've interviewed a great deal of poorly selected people for lots of positions over the years.
Absolutely untrue in my experience, I can't speak for other people. To imply that this is absolutely untrue in the global space would require that I have interviewed everyone.
Whiteboard problems absolutely do work in my interviews. Again, use of the word absolute indicates that I've never interviewed without a whiteboard. Given the high number of candidates I've interviewed, this might indicate a flaw in the interview process.
The vast majority of applicants I select for interviews cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. I should consider the possibility that I'm selecting the wrong people for interviews.
Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. Clearly other companies are making the same mistakes I am making in their candidate selection process.
How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.
Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.
Source: I've interviewed a great deal of poorly selected people for lots of positions over the years.
May be the company you hire for has a mediocre reputation. So that people with average programming skills don't mind applying. People are generally good at self sorting. At some level they must be thinking they can get this job and end up being surprised that all the rounds are not behavioral rounds.
>Whiteboard problems absolutely do work.
>The vast majority of applicants cannot code at all.
You kinda set up a strawman here. If the purpose of the whiteboard problem was just to establish some very low baseline of coding ability then I doubt many people would argue about their effectiveness. But companies don't use whiteboard problems for that purpose. In my experience (on both sides of the table) they are given with increasing levels of difficulty to see how far the candidate can go. They do not simply ask a few basic questions like "how would you write a function that returned the sum of two numbers" or "count the number of elements in a given array."
I'm not saying there is a really good answer to this. The best I've seen is that some people just seem to be good at hiring and others are not. I am one who is not. I am also a terrible interviewee. The whole process whigs me out.
>The vast majority of applicants cannot code at all.
You kinda set up a strawman here. If the purpose of the whiteboard problem was just to establish some very low baseline of coding ability then I doubt many people would argue about their effectiveness. But companies don't use whiteboard problems for that purpose. In my experience (on both sides of the table) they are given with increasing levels of difficulty to see how far the candidate can go. They do not simply ask a few basic questions like "how would you write a function that returned the sum of two numbers" or "count the number of elements in a given array."
I'm not saying there is a really good answer to this. The best I've seen is that some people just seem to be good at hiring and others are not. I am one who is not. I am also a terrible interviewee. The whole process whigs me out.
The vast majority of applicants cannot code at all. And I mean that literally.
No, you mean that hyperbolically.
Not only does it simply not happen that "the vast majority of applications cannot code at all" -- this literally has never happened at all, in my experience.
What does happen is that you get a range of people on a spectrum. And yeah, a fair number of them can't code very well. They're slow, they don't see smart solutions, whatever - or are just plain sloppy. But that's quite different from "not being able to code at all."
As to those people who (supposedly) can't "write a function that adds two numbers or counts the number of elements in a list" -- most likely they're simply freezing up from the anxiety of being whiteboarded by a perfect stranger for the first time in a great while - or perhaps ever. (In fact that's exactly what happened to me, on my very first on-site interview after college).
Or that is to say: they haven't internalized -- and produced defenses for -- the (intentionally) awkward and humiliating ritual of the modern tech interview process.
And again, you should only be actually seeing these people once in a blue moon. Unless the people running your incoming "pipeline" are utterly incompetent, and are constantly feeding you a stream of unqualified candidates. In which case your companies much bigger problem a lack of engineers who are able to "ace" HackerRank problems in 59 minutes or less.[1]
[1] Which, lest be honest now -- basically can only happen after extensive time spent on practicing these problems in advance. Or that is, by blatantly gaming your hiring "filter".
And one more thing:
How, you ask? By ... dodging responsibility.
No - their jobs just have different metrics for "responsibility" than yours. That's just the way many businesses are run, whether you like it or not.
No, you mean that hyperbolically.
Not only does it simply not happen that "the vast majority of applications cannot code at all" -- this literally has never happened at all, in my experience.
What does happen is that you get a range of people on a spectrum. And yeah, a fair number of them can't code very well. They're slow, they don't see smart solutions, whatever - or are just plain sloppy. But that's quite different from "not being able to code at all."
As to those people who (supposedly) can't "write a function that adds two numbers or counts the number of elements in a list" -- most likely they're simply freezing up from the anxiety of being whiteboarded by a perfect stranger for the first time in a great while - or perhaps ever. (In fact that's exactly what happened to me, on my very first on-site interview after college).
Or that is to say: they haven't internalized -- and produced defenses for -- the (intentionally) awkward and humiliating ritual of the modern tech interview process.
And again, you should only be actually seeing these people once in a blue moon. Unless the people running your incoming "pipeline" are utterly incompetent, and are constantly feeding you a stream of unqualified candidates. In which case your companies much bigger problem a lack of engineers who are able to "ace" HackerRank problems in 59 minutes or less.[1]
[1] Which, lest be honest now -- basically can only happen after extensive time spent on practicing these problems in advance. Or that is, by blatantly gaming your hiring "filter".
And one more thing:
How, you ask? By ... dodging responsibility.
No - their jobs just have different metrics for "responsibility" than yours. That's just the way many businesses are run, whether you like it or not.
When I do whiteboard questions, I write in pseudocode. It takes some companies by surprise, but in the end they usually understand my reasoning:
Whiteboards are for writing down algorithms and quick charts and other design-phase stuff, not writing compilable code.
Whiteboards are for writing down algorithms and quick charts and other design-phase stuff, not writing compilable code.
I explicitly tell candidates that they should use pseudocode. Nitpicking stupid syntax that the compiler can catch in a whiteboard interview is pretty pointless.
Culture fit is a thing, especially when working remote. You have to trust people you work with. Of course it can be abused.
I presume you haven't submitted candidates to a fizzbuzz test. Try it. The test is well known and out there in the wild. It's almost part of programmer culture. Yet it is absolutely shocking how many candidates that apply to jobs that involve programming will fail that simple test or some minor variation of it. Almost as shockingly, they will also fail to spot their bug after producing a solution that doesn't work as expected.
From what I gather, what is most shocking of all is that candidate still fail this test, despite it being so common, despite there being an several github repos devoted to it, as well as other pages and articles about it (somewhere out there was a page or a repo or something I encountered that had it written in almost every programming language out there, include whitespace and brainf*ck).
Even when given as a "take home" challenge, they can't even copy-pasta an example off the internet...
Even when given as a "take home" challenge, they can't even copy-pasta an example off the internet...
> include whitespace and brainfuck
make part of the test a reverse question where the interviewers have to work out what language your solution is in
make part of the test a reverse question where the interviewers have to work out what language your solution is in
1:v!`*5*54p2*62*77,*5<
v _@>v >v>:#<.>1+:2^
>:3%|>:5%|> 1#^_^
v"z"<pvv<"p
:>v>v2,"-z2
"",8**,B5"*
iF,622#"::4
"",,3*^<^<3
>^>^>^>,8#^6#*<> We call it "culture fit" but we're really just trying to vet their personalities
I've seen this end up in teams that lack diversity several times. My last company was big on interviewing for fit. Then a year goes by and you realize most of the people you've hired are a clone of everyone else. I had a co-worker that once argued that you can't judge people based on personality in an interview and I tend to agree with that now
I've seen this end up in teams that lack diversity several times. My last company was big on interviewing for fit. Then a year goes by and you realize most of the people you've hired are a clone of everyone else. I had a co-worker that once argued that you can't judge people based on personality in an interview and I tend to agree with that now
way too cynical.
We need to admit that interviewing is hard, and we aren't good at it. In fact, we don't need to admit it, we know it already.
We need to admit that interviewing is hard, and we aren't good at it. In fact, we don't need to admit it, we know it already.
All interviewing techniques are broadly disliked. A quick summary of complaints found on HN every time we discuss this (about once a week):
- Whiteboarding: algorithmic knowledge not relevant to daily tasks, we have google, obtuse coding environment
- Take home exams: companies have less incentive to respect time of candidate, favors candidates with lots of time to spend interviewing
- Small consulting gigs: not practical for programmers with existing jobs, draws out job search
- Informal conversations, reading resumes: not stringent, susceptible to talented bullshitters
To be 100% clear, none of the above is my opinion, I am simply restating what is regularly posted at this online watering whole.
A discussion of the failings of white-boarding without the context of alternatives is meaningless because interviewing techniques are search functions that all have precision/recall tradeoffs. That there are negatives to white-boarding is a given.
For example, consider that white boarding interviews are short (3 hours). This naturally limits the company's ability to evaluate candidates (less precision), BUT it saves time for the candidate and company (more recall).
So what happens here at HN every week is you get five people all bad mouthing a different interviewing technique, but we never get any closer to a consensus on a technique that would please even a simple majority of programmers (let alone everyone).
TLDR; you don't like white boarding, so what about making a compelling case for something else?
- Whiteboarding: algorithmic knowledge not relevant to daily tasks, we have google, obtuse coding environment
- Take home exams: companies have less incentive to respect time of candidate, favors candidates with lots of time to spend interviewing
- Small consulting gigs: not practical for programmers with existing jobs, draws out job search
- Informal conversations, reading resumes: not stringent, susceptible to talented bullshitters
To be 100% clear, none of the above is my opinion, I am simply restating what is regularly posted at this online watering whole.
A discussion of the failings of white-boarding without the context of alternatives is meaningless because interviewing techniques are search functions that all have precision/recall tradeoffs. That there are negatives to white-boarding is a given.
For example, consider that white boarding interviews are short (3 hours). This naturally limits the company's ability to evaluate candidates (less precision), BUT it saves time for the candidate and company (more recall).
So what happens here at HN every week is you get five people all bad mouthing a different interviewing technique, but we never get any closer to a consensus on a technique that would please even a simple majority of programmers (let alone everyone).
TLDR; you don't like white boarding, so what about making a compelling case for something else?
So there are multiple things that are true with people applying for development roles:
1. These "dev gate" programming challenges are filtering out senior devs, talented devs, creative devs etc. people who would be great at the role.
2. There are people applying for these roles who can't knock out a decent Fizzbuzz solution (in any amount of time).
3. For many roles, there's a flood of applicants
Any solutions to this need must address all three of these things simultaneously which seems astoundingly difficult.
1. These "dev gate" programming challenges are filtering out senior devs, talented devs, creative devs etc. people who would be great at the role.
2. There are people applying for these roles who can't knock out a decent Fizzbuzz solution (in any amount of time).
3. For many roles, there's a flood of applicants
Any solutions to this need must address all three of these things simultaneously which seems astoundingly difficult.
It's a sad fact that interviewing sucks for both sides. Nobody trains us to conduct interviews, so we all just wing it.
I hate wasting time on candidates that can't answer rudimentary programming questions and I hate being in interviews where I'm asked questions which I feel are silly or irrelevant. I can't even trust my results sometimes because there's always that feeling that perhaps a candidate missed a question because I was a poor communicator.
Listening in on interviews with my team mates has really opened my eyes to the random nature of hiring. I'm certain I would not have passed the bar if interviewed by Team Member B instead of Team Member A.
I hate wasting time on candidates that can't answer rudimentary programming questions and I hate being in interviews where I'm asked questions which I feel are silly or irrelevant. I can't even trust my results sometimes because there's always that feeling that perhaps a candidate missed a question because I was a poor communicator.
Listening in on interviews with my team mates has really opened my eyes to the random nature of hiring. I'm certain I would not have passed the bar if interviewed by Team Member B instead of Team Member A.
> I can't even trust my results sometimes because there's always that feeling that perhaps a candidate missed a question because I was a poor communicator.
This sentence shows a level of awareness sadly uncommon, that I don't believe I've encountered in... thousands of interviews.
This sentence shows a level of awareness sadly uncommon, that I don't believe I've encountered in... thousands of interviews.
It does scare me when experienced developers can't write FizzBuzz though, in any language of their choosing, in a reasonable time frame. The thing I tell myself is that there are so many "gotcha" style programming interview questions that people might just be nervous that there's some trap waiting for them in the question.
A few years ago I instituted an "interviewing code of conduct" for my teams with a few tenants that we've refined over the years, but the first one was "We will treat every candidate with respect and empathy in our interview process". The team has adopted some attitudes and techniques to do so while also not compromising on the talent or skills we are looking for. We've gotten very positive feedback on our interviews, so we think it's working.
A few years ago I instituted an "interviewing code of conduct" for my teams with a few tenants that we've refined over the years, but the first one was "We will treat every candidate with respect and empathy in our interview process". The team has adopted some attitudes and techniques to do so while also not compromising on the talent or skills we are looking for. We've gotten very positive feedback on our interviews, so we think it's working.
Can you share some concrete examples of techniques?
I can tell you something that has worked very well for me:
1. Grab a sub-set of the competencies that you NEED to have https://sijinjoseph.com/programmer-competency-matrix/
2. From that subset, setup questions for the different levels For example, for the VCS competency we have:
source code version control Lvl 1 questions: "- What is the difference between Git and Github? - What is a branch? - What is a pull or merge-request? - What is a commit?
Lvl 2 questions: - Mention other VCS besides Git - Mention good practices of a Commit (short title, description content, etc) - Describe one branching model (aka gitflow or other) - What is a cherry-pick? - Describe good practices of a Pull/Merge request
Lvl 3 questions - What is the difference between a Merge and a Rebase? When to use them? - What is Git Bisect? how to use it? - Git vs Mercural or other DVCS. - What is partial clone? - What is a Git Submodule? - What are Git Hooks
3. Split your 1 hour interview into 2 parts: Coding and Q&A. For the coding part, ask them to build something, in their machine, with the language of their choice, sharing screen. The problem should be something for 1 hour, and split in steps (I usually do 6). With this problem you will score coding ability, cleanliness, defensive coding and similar stuff. I usually score between 1 and 3 (1 - Below Average I have seen, 2 - Above Average I have seen, 3 - Amazing/Impressive)
The second 30min part is Q&A, use the questions to check whether they are a 1, 2 or 3 (or maybe 0 if they cannot answer a Lvl1 question).
Then combine those scores anyway you want (average, weighted average with extra weight for code or for some question) and see what % of the max score the candidate gets.
The key during the Q&A is that you start with 1 or 2 lvl1 questions, and then if they answer, you go to lvl2 questions, and if they get them, go to lvl3 questions. The idea is, to never make the candidate feel like they don't know. With experience you can get very good at seeing what levels of questions a specific candidate will answer.
1. Grab a sub-set of the competencies that you NEED to have https://sijinjoseph.com/programmer-competency-matrix/
2. From that subset, setup questions for the different levels For example, for the VCS competency we have:
source code version control Lvl 1 questions: "- What is the difference between Git and Github? - What is a branch? - What is a pull or merge-request? - What is a commit?
Lvl 2 questions: - Mention other VCS besides Git - Mention good practices of a Commit (short title, description content, etc) - Describe one branching model (aka gitflow or other) - What is a cherry-pick? - Describe good practices of a Pull/Merge request
Lvl 3 questions - What is the difference between a Merge and a Rebase? When to use them? - What is Git Bisect? how to use it? - Git vs Mercural or other DVCS. - What is partial clone? - What is a Git Submodule? - What are Git Hooks
3. Split your 1 hour interview into 2 parts: Coding and Q&A. For the coding part, ask them to build something, in their machine, with the language of their choice, sharing screen. The problem should be something for 1 hour, and split in steps (I usually do 6). With this problem you will score coding ability, cleanliness, defensive coding and similar stuff. I usually score between 1 and 3 (1 - Below Average I have seen, 2 - Above Average I have seen, 3 - Amazing/Impressive)
The second 30min part is Q&A, use the questions to check whether they are a 1, 2 or 3 (or maybe 0 if they cannot answer a Lvl1 question).
Then combine those scores anyway you want (average, weighted average with extra weight for code or for some question) and see what % of the max score the candidate gets.
The key during the Q&A is that you start with 1 or 2 lvl1 questions, and then if they answer, you go to lvl2 questions, and if they get them, go to lvl3 questions. The idea is, to never make the candidate feel like they don't know. With experience you can get very good at seeing what levels of questions a specific candidate will answer.
I've been on both sides of this. As an applicant, sometimes it's a crapshoot in terms of getting lucky that they asked me the right question. On the other hand, as a hiring manager or interviewer, I see lots and lots of candidates who can't write out a fizzbuzz solution, and it wastes a lot of my time (I'm a sucker and will take a lot of time guiding interviewees to the right solution, even on a simple problem when I know the interview is over, but I don't want to bruise their ego too much).
I don't have a silver bullet solution to this, but I think a few things go in the right direction:
1) Candidates should have to write code in interviews. But they shouldn't have to solve puzzle problems with "gotcha" solutions. If there's a specific trick that requires an "aha" moment, you are really testing how well a candidate solves puzzles under pressure, not how they code.
2) Test candidates on what they are best at. If someone has been working in C# for the last 5 years, don't ask them to whiteboard in Python, which they used in college. Picking up new languages/frameworks is quick for someone who knows what they are doing [0].
3) Offer candidates a choice between an in person interview or a take home coding test, the latter of which would take more time. Some candidates don't want to deal with doing a 6 hour take-home coding problem [1]. Other candidates suck at whiteboarding under pressure. So more options seems better.
[0] There are exceptions to this. You might have a unique problem and the budget/resources to hire a rockstar for a specific role. Desirable companies willing to dole out big salaries do this all the time. But much more often, I see companies offering average salaries for very very specific roles. One company near me told me that I was one of the best candidates they've seen, but they are looking specifically for someone with 1+ years of Java experience. I could have picked up the basics of Java in a month, and been fairly proficient in 2-4 months. Meanwhile, they are still looking to fill that role and it's been over 2 years.
[1] I've had a few companies that insist on this, but I haven't had a period of unemployment where I have the time for this. Good developers tend to be/stay employed, so if you are looking to hire senior devs, you probably need to consider their schedules. Unless I'm desperate to leave a job, I can only make so much time for interviews.
I don't have a silver bullet solution to this, but I think a few things go in the right direction:
1) Candidates should have to write code in interviews. But they shouldn't have to solve puzzle problems with "gotcha" solutions. If there's a specific trick that requires an "aha" moment, you are really testing how well a candidate solves puzzles under pressure, not how they code.
2) Test candidates on what they are best at. If someone has been working in C# for the last 5 years, don't ask them to whiteboard in Python, which they used in college. Picking up new languages/frameworks is quick for someone who knows what they are doing [0].
3) Offer candidates a choice between an in person interview or a take home coding test, the latter of which would take more time. Some candidates don't want to deal with doing a 6 hour take-home coding problem [1]. Other candidates suck at whiteboarding under pressure. So more options seems better.
[0] There are exceptions to this. You might have a unique problem and the budget/resources to hire a rockstar for a specific role. Desirable companies willing to dole out big salaries do this all the time. But much more often, I see companies offering average salaries for very very specific roles. One company near me told me that I was one of the best candidates they've seen, but they are looking specifically for someone with 1+ years of Java experience. I could have picked up the basics of Java in a month, and been fairly proficient in 2-4 months. Meanwhile, they are still looking to fill that role and it's been over 2 years.
[1] I've had a few companies that insist on this, but I haven't had a period of unemployment where I have the time for this. Good developers tend to be/stay employed, so if you are looking to hire senior devs, you probably need to consider their schedules. Unless I'm desperate to leave a job, I can only make so much time for interviews.
> they shouldn't have to solve puzzle problems with "gotcha" solutions.
I’ve never come across this myself, but I always figured that sort of interviewing would correct itself over time - if you ask questions that nobody is going to know the answer to, eventually when three years have gone by and you still haven’t hired anybody, you’re going to have to adjust your tactics.
I’ve never come across this myself, but I always figured that sort of interviewing would correct itself over time - if you ask questions that nobody is going to know the answer to, eventually when three years have gone by and you still haven’t hired anybody, you’re going to have to adjust your tactics.
There are different philosophies, but it comes down to how you want to balance type I and type II error, where:
Type I error == false positive == hiring someone who isn't qualified
Type II error == false negative == failing to hire someone who is qualified
I think a lot of companies are obsessed with minimizing Type I error. They really don't want to hire bad developers. As a hiring manager, your ass is on the line if you make too many of these mistakes (when your own manager asks, why are we paying 100k/year for someone who you are telling me isn't very good?). And perhaps you'll have to fire someone, which is painful for most people to do [0].
On the other hand, the costs of Type II error fly under the radar. Your manager comes to you and asks why haven't you hired anyone yet? "Well, I haven't found someone qualified yet" is the only answer you need to give. So it's easy to avoid culpability and it's harder to measure the costs associated with the work not getting done (generally, it's easy to measure a developer's cost, which is their salary + benefits + time they spend using others' time multiplied by those employees compensation. It's much harder to measure the value of their output in most cases, unless they are working alone on a revenue generating project.
I think there's a problem (at many companies) of people being held accountable for Type I but not Type II error. And so naturally, people worry more about Type I.
[0] On a tangential note, I had a boss once who made a good point to me. He encouraged me to take risks in hiring, but he said tgat the worst person to hire is someone who is mediocre. If someone is really bad, it's easier to fire them. If someone is really good, then everyone is happy. But if someone is bad, but not bad enough to fire, then they stick around and cause the most damage.
Type I error == false positive == hiring someone who isn't qualified
Type II error == false negative == failing to hire someone who is qualified
I think a lot of companies are obsessed with minimizing Type I error. They really don't want to hire bad developers. As a hiring manager, your ass is on the line if you make too many of these mistakes (when your own manager asks, why are we paying 100k/year for someone who you are telling me isn't very good?). And perhaps you'll have to fire someone, which is painful for most people to do [0].
On the other hand, the costs of Type II error fly under the radar. Your manager comes to you and asks why haven't you hired anyone yet? "Well, I haven't found someone qualified yet" is the only answer you need to give. So it's easy to avoid culpability and it's harder to measure the costs associated with the work not getting done (generally, it's easy to measure a developer's cost, which is their salary + benefits + time they spend using others' time multiplied by those employees compensation. It's much harder to measure the value of their output in most cases, unless they are working alone on a revenue generating project.
I think there's a problem (at many companies) of people being held accountable for Type I but not Type II error. And so naturally, people worry more about Type I.
[0] On a tangential note, I had a boss once who made a good point to me. He encouraged me to take risks in hiring, but he said tgat the worst person to hire is someone who is mediocre. If someone is really bad, it's easier to fire them. If someone is really good, then everyone is happy. But if someone is bad, but not bad enough to fire, then they stick around and cause the most damage.
You would think that. But there's that saying about how "the market can stay irrational longer than you can stay solvent." It's true.
I've seen many places sit on job reqs for a year or two after I applied and would have done quite well. Sure, I may have needed to study a week or two. Then they'd have a solution ~11 months earlier.
I've seen many places sit on job reqs for a year or two after I applied and would have done quite well. Sure, I may have needed to study a week or two. Then they'd have a solution ~11 months earlier.
I think my team has gotten pretty good at this. We address the "flood of applicants" by tossing out any resumes that don't have some sort of CS or programming on them (about 25%), and favoring, in order, people who have held a programming job, people who have done programming internships, and people who have taken CS classes. A decent GitHub profile will bump you up in the two later categories.
Next is a five minute phone screen. We're a Java shop, so I ask them something dumb, like "what's the difference between public, private, and protected?" Something any Java dev would know; I'm just trying to find out if they have ever actually used the language.[1]
People that pass the phone screen get a Skype interview, where they write code in an IDE. The first half hour or so is chat and trivial problems like "sort this array" or "return true of this String starts with a letter between A-Z, inclusive." They're allowed to Google and use the standard libraries.
Finally, we have a "close to real world" problem for them to work on. It's a standalone, mostly-toy CRUD application, and we'll ask them to add a feature that represents the kind of work they'd be doing. Again, they have their IDE of choice, Stack Overflow, etc.
I don't think we've had a bad hire since we started using this process. Have we turned aside some all-stars that interview poorly? Maybe, but the team we've built is really good at what they do, so I'm pretty happy with the results.
[1] We have hired Senior devs that don't know Java. One of our team leads was a C# guy for a decade or so, but he was smart and available, so we scooped him up. Java is easy to learn. Programming well isn't.
Next is a five minute phone screen. We're a Java shop, so I ask them something dumb, like "what's the difference between public, private, and protected?" Something any Java dev would know; I'm just trying to find out if they have ever actually used the language.[1]
People that pass the phone screen get a Skype interview, where they write code in an IDE. The first half hour or so is chat and trivial problems like "sort this array" or "return true of this String starts with a letter between A-Z, inclusive." They're allowed to Google and use the standard libraries.
Finally, we have a "close to real world" problem for them to work on. It's a standalone, mostly-toy CRUD application, and we'll ask them to add a feature that represents the kind of work they'd be doing. Again, they have their IDE of choice, Stack Overflow, etc.
I don't think we've had a bad hire since we started using this process. Have we turned aside some all-stars that interview poorly? Maybe, but the team we've built is really good at what they do, so I'm pretty happy with the results.
[1] We have hired Senior devs that don't know Java. One of our team leads was a C# guy for a decade or so, but he was smart and available, so we scooped him up. Java is easy to learn. Programming well isn't.
About your last comment - c# was explicitly made similar to java (at least at first, it diverged in time but the basics are close to being a superset of java).
My first job using c# was in 2010, and I have been programming in java since 2002 at that point. I was productive pretty much since the first day & not because I'm a genius - c# is that similar to java...
I suspect that if you'd have hired a php or a python expert they would have taken more time to get used to java (not that that would have meant you shouldn't hire them!)
My first job using c# was in 2010, and I have been programming in java since 2002 at that point. I was productive pretty much since the first day & not because I'm a genius - c# is that similar to java...
I suspect that if you'd have hired a php or a python expert they would have taken more time to get used to java (not that that would have meant you shouldn't hire them!)
Oh absolutely. I used to joke that you could convert C# to Java by replacing "string" with "String" and changing the extension.
But really, most of the C-family of languages are similar enough that you can kind of hack your way through pretty quickly, and become mostly-productive in a few weeks.
The family of Go, Java, C#, Python, Kotlin, Javascript, etc etc are all similar enough in theory that "working code" is as close as Googling the right syntax.
But really, most of the C-family of languages are similar enough that you can kind of hack your way through pretty quickly, and become mostly-productive in a few weeks.
The family of Go, Java, C#, Python, Kotlin, Javascript, etc etc are all similar enough in theory that "working code" is as close as Googling the right syntax.
I have a degree in physics and 20 years of programming. Just out of curiosity, would I be weeded out in the first 25%?
> any resumes that don't have some sort of CS or programming on them
> I have a degree in physics and 20 years of programming
Depends, do you mention your 20 years of programming on your resume?
> I have a degree in physics and 20 years of programming
Depends, do you mention your 20 years of programming on your resume?
After you've been coding for a few years, I think your degree is largely irrelevant. A guy with 20 years of programming knowledge has far, far more than a degree.
Similarly, a candidate could have graduated top of their class from the most prestigious university in the world, but if they've never been able to hold a job for more than six months, that tells me something.
Similarly, a candidate could have graduated top of their class from the most prestigious university in the world, but if they've never been able to hold a job for more than six months, that tells me something.
Your last point is interesting and hits close to home for me, from the other end. My current gig is python, but when I got hired I new exactly zero python. But I had been writing software a long time and in the same area (networking & automation) so they scooped me up. Let's just say it's worked out very well, for everyone involved.
I still don't know Java that well, though ;-)
I still don't know Java that well, though ;-)
filtering for cs is short sighted imo. You're going to see less and less folks holding a cs degree as more folks wisen up to the trap of student debt in the us.
Instead put folks on trials and keep the good performers.
Instead put folks on trials and keep the good performers.
I agree; that requirement was pushed down on me from on high. I think we're starting to loosen up about it, though.
I used to just look at someone's resume and then start asking them, in a collegial engineer fashion, about technical questions that come to mind about things they've worked on, and go from there, perhaps in speculative directions. But that's not good, now that everyone is concerned about real or perceived IP taint.
There's now a better way, now that a lot of people have open source contributions. Look at their open source contributions, especially if they're involved in public discussions as well as in code. Then you can followup and ask them about those.
Open source behavior is not necessarily quite the same as workplace behavior, especially if their participation was unpaid, and they had limited time, and the team dynamics were different, but there can be a lot of overlap.
(Simple example, using someone famous: if you did not know anything about Linus Torvalds, and didn't trust his resume and references, you could learn from looking at his open source participation that he knows how to code, has managed ambitious projects with cat-herding, is knowledgable and conscientious, historically has a very frank manner that some might find discouraging, and has recently reflected on manner and is modifying it. If that isn't enough, start discussing a technical topic with him that doesn't seem to involve proprietary IP.)
One engineer taking a quick glance at open source participation, and then asking questions about that, is arguably more useful than the engineer spending the same amount of time asking some contrived question and sitting in a stuffy room while the candidate does a theatre performance under conditions that aren't representative of real work.
Also, before considering dumping many hours of take-home makework programming on someone, it's respectful to first take a look at their open source. (Especially with a person who does open source on the side. There's an extra frustration with takehome, which is that they probably have backlogs of unpaid open source things they'd like to spend time on, and the takehome is hours of similar work in free time, but gets thrown away.)
There's now a better way, now that a lot of people have open source contributions. Look at their open source contributions, especially if they're involved in public discussions as well as in code. Then you can followup and ask them about those.
Open source behavior is not necessarily quite the same as workplace behavior, especially if their participation was unpaid, and they had limited time, and the team dynamics were different, but there can be a lot of overlap.
(Simple example, using someone famous: if you did not know anything about Linus Torvalds, and didn't trust his resume and references, you could learn from looking at his open source participation that he knows how to code, has managed ambitious projects with cat-herding, is knowledgable and conscientious, historically has a very frank manner that some might find discouraging, and has recently reflected on manner and is modifying it. If that isn't enough, start discussing a technical topic with him that doesn't seem to involve proprietary IP.)
One engineer taking a quick glance at open source participation, and then asking questions about that, is arguably more useful than the engineer spending the same amount of time asking some contrived question and sitting in a stuffy room while the candidate does a theatre performance under conditions that aren't representative of real work.
Also, before considering dumping many hours of take-home makework programming on someone, it's respectful to first take a look at their open source. (Especially with a person who does open source on the side. There's an extra frustration with takehome, which is that they probably have backlogs of unpaid open source things they'd like to spend time on, and the takehome is hours of similar work in free time, but gets thrown away.)
Not only that, but they sometimes even yield False-Positives, like in my experience:
I have been in charge of smallish engineering teams for around 5 years (as head of engineering for different startups). In the past, I used to actually do the 3-HackerRank-timed question as a 1st automated filter.
The problem is that, by testing for "fundamentals" (algorithms and data structure really) I skewed my hiring pool to the ones that were best at those.
Who is the people that are best at solving those kind of puzzle problems? (like the ones in HR, Codility, CodeFight, Codewars, etc), those most likely are Jr developers that are in Uni or recently graduated and spent their Uni free time in coding competitions.
The problem with that is that, these are a very particular type of programmers: They are super-effective in writing tiny one-of code to solve a specific "closed" problem. They usually don't care about testing, code reading quality, interactions, maintainability, etc. Given that they optimize for time and "pass the test cases".
Because of that, suddenly I had like 10 devs that were very good at algorithms but very Jr with regards to Software Engineering, architecture, maintainability, business understanding, etc.
Nowadays I have developed an automated challenge that 1. Requires coding, 2. Requires HTTP requests interaction, 3. Requires thinking and allows me to filter out people that really don't know what they are doing ( https://paystand.ml/challenge/ ).
WRT the 1 hour interview, I have always used a modified version of ( https://sijinjoseph.com/programmer-competency-matrix/ ) to be as objective as possible, and to be able to score Developers in a wide range of skills, and not only "they don't know how to solve the problem of returning a correct sub-tree from a BST within certain ranges". Sure, Algorithms and Data Structures are part of the requirements, but even knowing little of that should not disqualify you.
I have been in charge of smallish engineering teams for around 5 years (as head of engineering for different startups). In the past, I used to actually do the 3-HackerRank-timed question as a 1st automated filter.
The problem is that, by testing for "fundamentals" (algorithms and data structure really) I skewed my hiring pool to the ones that were best at those.
Who is the people that are best at solving those kind of puzzle problems? (like the ones in HR, Codility, CodeFight, Codewars, etc), those most likely are Jr developers that are in Uni or recently graduated and spent their Uni free time in coding competitions.
The problem with that is that, these are a very particular type of programmers: They are super-effective in writing tiny one-of code to solve a specific "closed" problem. They usually don't care about testing, code reading quality, interactions, maintainability, etc. Given that they optimize for time and "pass the test cases".
Because of that, suddenly I had like 10 devs that were very good at algorithms but very Jr with regards to Software Engineering, architecture, maintainability, business understanding, etc.
Nowadays I have developed an automated challenge that 1. Requires coding, 2. Requires HTTP requests interaction, 3. Requires thinking and allows me to filter out people that really don't know what they are doing ( https://paystand.ml/challenge/ ).
WRT the 1 hour interview, I have always used a modified version of ( https://sijinjoseph.com/programmer-competency-matrix/ ) to be as objective as possible, and to be able to score Developers in a wide range of skills, and not only "they don't know how to solve the problem of returning a correct sub-tree from a BST within certain ranges". Sure, Algorithms and Data Structures are part of the requirements, but even knowing little of that should not disqualify you.
HN has discussed HackerRank and the like before: https://news.ycombinator.com/item?id=15182952
Can someone describe what is a 'senior'? This might be controversial but I see senior title promotions being thrown around just for retention reasons, could it be possible that once you start looking for another 'senior' role at another company they have different expectations of that title? Not to mention you can obtain a 'senior' title by mastering your team's code base and who knows if that knowledge is transferable to X team and Y company.
Most people self-label themselves "senior developers" after 5 years of experience. However, it also refers to developers at risk of ageism (i.e. over the age of 40 or 50)
I know this sounds conspiratorial, but I think the leetcode tests are there to keep older people out. Because the whole "leetcode culture" stereotype of the junior/senior bachelor's CS student "grinding leetcode to land his Big-N job" means that younger grads are going to have seen these problems before and know how to rattle back the solutions without even thinking. Whereas an older dev is more likely to have a family or be secure in his/her years of experience to not waste time calculating the Big-O bullshit of reversing linked lists while merge sorting. They are more likely to have not seen the problem before and have to run the gauntlet with no practice. The motivation to discriminate is purely financial: a fresh grad is half the cost of a 20 year veteran.
> They are more likely to have not seen the problem before and have to run the gauntlet with no practice.
The other possibility is that they have seen the problem before, fixed it, but didn't know it was called "calculating the Big-O bullshit of reversing linked lists while merge sorting"...
I have 25+ years of experience; in a month I will turn 46. I don't have a CS degree, nor even a BS. I'm one of those devs who started basically fresh out of high school, and made a career out of it. I'm not even sure that is possible to do any longer.
What I don't have is all of that CS knowledge and terminology. That isn't to say that I could solve all of those problems, or that I have encountered them, or come up with the correct or practical solutions. To be fair, I am always learning something new (and I like it that way). Also, to the "example" you give, I'd have to look up how to reverse a linked list and what a merge sort exactly was. Hopefully, there's some kind of standard library for both in the language I was using, but if I had to do it from scratch, right now off the top of my head, I couldn't do it.
But I would know how to figure out and ask the right questions on how to do it, and go from there.
And that's really one of the best skills as a developer to have, imho. There have been times where I have had a problem, tried to google for it - thinking it was a common issue - found that it was a common issue, with people asking the questions - but either no solutions, or worse:
https://xkcd.com/979/
...and so, by breaking the problem down, figuring out the answer to those questions (with either more googling, or implementing a custom solution), then pulling all those parts back into one coherent answer for the initial problem - that greater issue can be solved.
Then I find a forum or something and post the solution there, so that future coders can at least have one good reference point, for as long as the forum exists. Nowadays, I'd probably put it on my github repo or something.
Ultimately - there are a lot of "senior devs" (both in age and ability) who are currently in my place; people who didn't go the tradition educational route; people who were coding in their bedrooms on 8-bit home computers in assembler and BASIC because that's all we had at the time. We may or may not have run across those CS-level problems. If we did, we didn't know their names (much like not knowing the names for certain "patterns" - yet another similar thing) - but we still may have implemented solutions for them anyhow.
The other possibility is that they have seen the problem before, fixed it, but didn't know it was called "calculating the Big-O bullshit of reversing linked lists while merge sorting"...
I have 25+ years of experience; in a month I will turn 46. I don't have a CS degree, nor even a BS. I'm one of those devs who started basically fresh out of high school, and made a career out of it. I'm not even sure that is possible to do any longer.
What I don't have is all of that CS knowledge and terminology. That isn't to say that I could solve all of those problems, or that I have encountered them, or come up with the correct or practical solutions. To be fair, I am always learning something new (and I like it that way). Also, to the "example" you give, I'd have to look up how to reverse a linked list and what a merge sort exactly was. Hopefully, there's some kind of standard library for both in the language I was using, but if I had to do it from scratch, right now off the top of my head, I couldn't do it.
But I would know how to figure out and ask the right questions on how to do it, and go from there.
And that's really one of the best skills as a developer to have, imho. There have been times where I have had a problem, tried to google for it - thinking it was a common issue - found that it was a common issue, with people asking the questions - but either no solutions, or worse:
https://xkcd.com/979/
...and so, by breaking the problem down, figuring out the answer to those questions (with either more googling, or implementing a custom solution), then pulling all those parts back into one coherent answer for the initial problem - that greater issue can be solved.
Then I find a forum or something and post the solution there, so that future coders can at least have one good reference point, for as long as the forum exists. Nowadays, I'd probably put it on my github repo or something.
Ultimately - there are a lot of "senior devs" (both in age and ability) who are currently in my place; people who didn't go the tradition educational route; people who were coding in their bedrooms on 8-bit home computers in assembler and BASIC because that's all we had at the time. We may or may not have run across those CS-level problems. If we did, we didn't know their names (much like not knowing the names for certain "patterns" - yet another similar thing) - but we still may have implemented solutions for them anyhow.
yeah I just grunt and snarl when I google and find a forum post from 2007. I wish there were an easy way to filter by date.
I have faith in your problem solving abilities. I'm 35 and have a CS degree. The only time I've needed to know Big-O or how sorting algos worked was in college and during interviews. I've literally never been in a situation where the code functionally worked, but ran too slowly because of an inefficient algorithm (and this is with 13 years as a C++ developer).
As for your situation, I suspect many shops would turn you down because you didn't rattle back the answer from memory. But the concern isn't that you aren't smart enough, it's that you're "old" and cost too much. The kid who memorized leetcode can be bought cheaply and discarded easily if it comes to light that he/she can't figure out how to solve a tech bug. If you "follow the money", these interviews could be seen as purely "cheap-but-comptetent people-filters". Because if an old programmer tried to sue them for age discrimination, they could point to leetcode as evidence that all the tests were administered "fairly".
I have faith in your problem solving abilities. I'm 35 and have a CS degree. The only time I've needed to know Big-O or how sorting algos worked was in college and during interviews. I've literally never been in a situation where the code functionally worked, but ran too slowly because of an inefficient algorithm (and this is with 13 years as a C++ developer).
As for your situation, I suspect many shops would turn you down because you didn't rattle back the answer from memory. But the concern isn't that you aren't smart enough, it's that you're "old" and cost too much. The kid who memorized leetcode can be bought cheaply and discarded easily if it comes to light that he/she can't figure out how to solve a tech bug. If you "follow the money", these interviews could be seen as purely "cheap-but-comptetent people-filters". Because if an old programmer tried to sue them for age discrimination, they could point to leetcode as evidence that all the tests were administered "fairly".
My very first entry-level job was as a 'senior'. I don't think it means anything.
There are many levels.
When you first get out of college you can write a 500 line program, and you get dropped you into a million line program. You get assigned a senior engineer to help you over the hump this takes a few years while you learn things that "everybody knows" but are not taught in school. Hopefully you get the first part of this over as an intern, but there is still more to learn.
Once you get over that hump you can do okay on your own. You can be assigned to write code and you rarely need help (you will always need help, but this point not often). You are still learning, but overall you get things done.
Senior engineer is you have been around for a enough years for a few of the following. Different companies value different things, and I've surely forgot something. I know engineers who never made the senior level because they refused to do something on this list even though if forced they were proven to do well.
You start to teach the other junior engineers how to be better engineers.
You start to see the larger picture of the whole system and how it should be changed for the better.
You start to see how the work individual developers do fits together and get involved with planning on how it is done (breakdown and ordering) so that the project finishes on time.
You become a specialist in something that is important to your company. This can be company specific, or a generic skill that applies elsewhere. (note that if the company doesn't realize how important the area is you won't be rewarded - preventing a problem the company never knew they had won't help)
When you first get out of college you can write a 500 line program, and you get dropped you into a million line program. You get assigned a senior engineer to help you over the hump this takes a few years while you learn things that "everybody knows" but are not taught in school. Hopefully you get the first part of this over as an intern, but there is still more to learn.
Once you get over that hump you can do okay on your own. You can be assigned to write code and you rarely need help (you will always need help, but this point not often). You are still learning, but overall you get things done.
Senior engineer is you have been around for a enough years for a few of the following. Different companies value different things, and I've surely forgot something. I know engineers who never made the senior level because they refused to do something on this list even though if forced they were proven to do well.
You start to teach the other junior engineers how to be better engineers.
You start to see the larger picture of the whole system and how it should be changed for the better.
You start to see how the work individual developers do fits together and get involved with planning on how it is done (breakdown and ordering) so that the project finishes on time.
You become a specialist in something that is important to your company. This can be company specific, or a generic skill that applies elsewhere. (note that if the company doesn't realize how important the area is you won't be rewarded - preventing a problem the company never knew they had won't help)
I've never really cared about it. I've oscillated between regular and senior positions so many times through my career that I think it's meaningless. Also, recruiters seem inclined to lie about titles, I've applied for high level roles but when the offer letter comes, the job title is regular engineer.
I recent left a level 5 of 7 job for a title level 2 of 6 and still managed a 30% pay raise. On paper, it looks like a huge step back (Consulting Data Scientist to Software Engineer), but in practice, it's actually more of a technical leadership role.
I recent left a level 5 of 7 job for a title level 2 of 6 and still managed a 30% pay raise. On paper, it looks like a huge step back (Consulting Data Scientist to Software Engineer), but in practice, it's actually more of a technical leadership role.
It's seriously as arbitrary as calling oneself a "software engineer" when all one is doing is maintaining WordPress instances. I've seen resumes of those only 2 years out of a defunct coding bootcamp label themselves senior.
Depends on where you go. In the Big Tech cos, you usually have this hierarchy:
1) Junior Engineer - can write basic code, but usually needs help for bigger projects or navigating a code base.
2) Engineer - Is pretty independent and can whip together what they need based on a design.
3) Senior Engineer - Can take a problem and build a design for it, can lead a team of lower-level engineers to properly implement the design.
There are higher levels like staff and principal engineer, these ones typically are the same as senior engineers but are at larger scopes.
At levels 3 and higher, you tend to write more English than code. You're there to decide what code gets written, rather than the specifics on how it gets written. That's what levels 1 and 2 do, they'll take your designs and implement them.
1) Junior Engineer - can write basic code, but usually needs help for bigger projects or navigating a code base.
2) Engineer - Is pretty independent and can whip together what they need based on a design.
3) Senior Engineer - Can take a problem and build a design for it, can lead a team of lower-level engineers to properly implement the design.
There are higher levels like staff and principal engineer, these ones typically are the same as senior engineers but are at larger scopes.
At levels 3 and higher, you tend to write more English than code. You're there to decide what code gets written, rather than the specifics on how it gets written. That's what levels 1 and 2 do, they'll take your designs and implement them.
https://twitter.com/gankro/status/1046438955439271936
Mozilla engineer leveling chart is a good example. There are probably other companies that expose the criteria they use as well.
Mozilla engineer leveling chart is a good example. There are probably other companies that expose the criteria they use as well.
At this point it seems like a tired HN discussion.
1. Everybody agrees interviews and tests have some signal, some noise.
2. Some interviews are systematically biased toward skills that aren't a good sample of what work is. But people just want to whine about it rather than propose a better solution.
3. Nobody can agree on what the important skills are for engineering anyways. Which is natural, since it varies situationally.
1. Everybody agrees interviews and tests have some signal, some noise.
2. Some interviews are systematically biased toward skills that aren't a good sample of what work is. But people just want to whine about it rather than propose a better solution.
3. Nobody can agree on what the important skills are for engineering anyways. Which is natural, since it varies situationally.
Actually I would say there are plenty of counterpoints in this thread to your second and third points.
shrug Seems dubious to me...
Likeliest scenario people say a bunch of vague phrases like "communication skill" and "culture fit" and "diligence" at each other, forget they had this conversation, and thread continues to happen every 2 weeks for the next 10 years (I guarantee this conversation has happened no less than 100 times here already).
Hypothetically not-meaningless form of collaboration that would never happen on HN -- people form a google doc and come up with concrete questions that they upvote/downvote to come up with a great engineering interview, and each new discussion adds to the list.
Likeliest scenario people say a bunch of vague phrases like "communication skill" and "culture fit" and "diligence" at each other, forget they had this conversation, and thread continues to happen every 2 weeks for the next 10 years (I guarantee this conversation has happened no less than 100 times here already).
Hypothetically not-meaningless form of collaboration that would never happen on HN -- people form a google doc and come up with concrete questions that they upvote/downvote to come up with a great engineering interview, and each new discussion adds to the list.
Well I mean even that suggestion you just made for a collaborative google doc is excellent and is the kind of counter point I was talking about.
The main contention developers seem to have (in my mind) isn't necessarily all whiteboarding interviews. Its the ones with ridiculous problem complexity and timelimits of under an hour that require inordinate amounts of study every time someone begins their job search (Dynamic programming in 45 min comes to mind). I think there are plenty of good alternatives in this thread: take-home assignments, paying developers to study and take these exams, github code reviews, even just restricting the problem space of a whiteboard interview to less complicated problems are all good suggestions.
The other point I was trying to make was that generally the skills you want to test for in an interview are those applicable to the job. Others in this thread have argued that these whiteboarding problems do in fact test some important subset of the skills needed by most developers. Others have pointed out that at some point though, its gotten ridiculous, and knowing how to sort and array in O(nlogn) is not really applicable to all the jobs interviewing for that knowledge, and it would be a better use of everybody's time to instead test for some other subset of knowledge (SQL use, CRUD application construction, etc.)
Finally I just wanted to point out I am an interviewer at my current company. I do take a lot of these conversations to heart. I have tried to experiment with the interviews I give to make them better for the candidate, and better for the company. Anyways, just pointing out I do think these conversations have an impact :)
The main contention developers seem to have (in my mind) isn't necessarily all whiteboarding interviews. Its the ones with ridiculous problem complexity and timelimits of under an hour that require inordinate amounts of study every time someone begins their job search (Dynamic programming in 45 min comes to mind). I think there are plenty of good alternatives in this thread: take-home assignments, paying developers to study and take these exams, github code reviews, even just restricting the problem space of a whiteboard interview to less complicated problems are all good suggestions.
The other point I was trying to make was that generally the skills you want to test for in an interview are those applicable to the job. Others in this thread have argued that these whiteboarding problems do in fact test some important subset of the skills needed by most developers. Others have pointed out that at some point though, its gotten ridiculous, and knowing how to sort and array in O(nlogn) is not really applicable to all the jobs interviewing for that knowledge, and it would be a better use of everybody's time to instead test for some other subset of knowledge (SQL use, CRUD application construction, etc.)
Finally I just wanted to point out I am an interviewer at my current company. I do take a lot of these conversations to heart. I have tried to experiment with the interviews I give to make them better for the candidate, and better for the company. Anyways, just pointing out I do think these conversations have an impact :)
Senior Developers are often running the interviews. If the Senior decides you need to know a certain set of questions for the job, and you fail those questions, then they feel you aren't ready for the job. That's not to say these questions aren't often ridiculous, but we're also forgetting that many Seniors (such as myself) don't ask these questions, asking simpler, more practical questions, and probing for industry knowledge. It's my own finding that around 50% or more of candidates can't write a single line of code at all. So asking a question like "reduce this array" is sufficient enough to judge that person's ability for the job that I need most of the time.
I agree with the basic sentiment of the article, but the question that always pops in my mind is, based on your real life work experience, what kind of (simplified) question would you ask in a 60 minute interview to gauge someone's ability to write, say, a distributed service?
It goes without saying that 60 minutes is too short a time to ask someone to solve a real life business problem, but real life business problems tend to be broken up into many small problems, which can in turn be simplified and presented to the interviewee.
The discussion I've been having with colleagues is how to do precisely this - eschewing the typical leet code/hacker rank problem, what problem can we come up with that has high fidelity to real life work, without being too complex for the 60 minute interview? I definitely think this is possible, and normally you get to that kind of question by working backwards - what is a real life feature I'd implement, and how can I ask a version of that during an interview. One example would be a graph of similar categories. Categorization is a common issue, and graphs are a common data structure.
Side rant - I've seen a lot of hate for things like data structure questions and algorithms associated with data structures. It's definitely possible to have an entire career of programming where all you do is build CRUD endpoints and design relationships between objects, but sitting down and learning about these amazing data structures that have been refined over decades of work can seriously improve a lot of code. A common problem I've seen is people building rigid object hierarchies (by composition, not inheritance) where a tree would have been way more flexible and easier to understand.
It goes without saying that 60 minutes is too short a time to ask someone to solve a real life business problem, but real life business problems tend to be broken up into many small problems, which can in turn be simplified and presented to the interviewee.
The discussion I've been having with colleagues is how to do precisely this - eschewing the typical leet code/hacker rank problem, what problem can we come up with that has high fidelity to real life work, without being too complex for the 60 minute interview? I definitely think this is possible, and normally you get to that kind of question by working backwards - what is a real life feature I'd implement, and how can I ask a version of that during an interview. One example would be a graph of similar categories. Categorization is a common issue, and graphs are a common data structure.
Side rant - I've seen a lot of hate for things like data structure questions and algorithms associated with data structures. It's definitely possible to have an entire career of programming where all you do is build CRUD endpoints and design relationships between objects, but sitting down and learning about these amazing data structures that have been refined over decades of work can seriously improve a lot of code. A common problem I've seen is people building rigid object hierarchies (by composition, not inheritance) where a tree would have been way more flexible and easier to understand.
> what kind of (simplified) question would you ask in a 60 minute interview to gauge someone's ability to write, say, a distributed service?
I've used the last question from Stripe's last CTF for this. Roughly speaking: Given a 5 node SQL database cluster, how do I make it behave as a single server? I don't ask them to write code, I ask them them to walk me through how they would approach this problem and how they would deal with various failures (network interruptions mostly to keep it simple).
I've used the last question from Stripe's last CTF for this. Roughly speaking: Given a 5 node SQL database cluster, how do I make it behave as a single server? I don't ask them to write code, I ask them them to walk me through how they would approach this problem and how they would deal with various failures (network interruptions mostly to keep it simple).
A simple question can weed out the bozos, but a hard/tricky question won't select for the exceptional. The reason being that most folks can't solve a hard problem they've never seen with a gun to their head and no time for research.
A hard problem with no practice is effectively impossible unless lucky enough to have faced the exact same on in the last month. Selecting for the lucky at that point.
Lets dispense with the fantasy we can select the "best" in an hour, and move toward short contracts instead.
A hard problem with no practice is effectively impossible unless lucky enough to have faced the exact same on in the last month. Selecting for the lucky at that point.
Lets dispense with the fantasy we can select the "best" in an hour, and move toward short contracts instead.
Required reading on the subject: https://erikbern.com/2018/05/02/interviewing-is-a-noisy-pred...
I realize that there are problems with it, but I'm a huge fan of take-home problems that are similar to real problems the candidate would face on the job.
I realize that there are problems with it, but I'm a huge fan of take-home problems that are similar to real problems the candidate would face on the job.
Thanks, that was a great article and well researched. Also discovered a few other interesting tidbits on that fellow’s site.
[deleted]
What ever happened to using a portfolio and references? If a candidate is 10+ years in the business and they don't have a long list of products built and people who can verify the quality of those products, then what information is a fizz-buzz going to give you?
Most egregious example: I interviewed at a household name company, whose entire web stack was built upon a technology I created, and they still gave me a whiteboard test.
Most egregious example: I interviewed at a household name company, whose entire web stack was built upon a technology I created, and they still gave me a whiteboard test.
Sorry to hear that buddy :(
A senior developer should have a CV, maybe some hobby code, some references, a commercial product they can describe or point at.
Giving them programming puzzles is a waste of time. I get that they can be useful to filter out some bad recently-graduated-from-a-bootcamp developers.
The antipattern here isn't that there are puzzles. The antipattern is using some external screening service using the same process for all candidates. There shouldn't even be a HR person screening before the team and hiring manager is.
The antipattern here isn't that there are puzzles. The antipattern is using some external screening service using the same process for all candidates. There shouldn't even be a HR person screening before the team and hiring manager is.
The problem is that if you don't have any screening, then you get a flood of candidates, and it takes someone's full time job to sift through them. HR needs to be well trained on what to look for, but they are often a necessary gatekeeper in my experience on the hiring side. The goal is to keep the number of qualified candidates who get filtered out at a reasonable level.
(I completely get that this is unfair. If you went to MIT and have a high GPA, you are gonna make it past the gate more often. Community college, but an excellent coder? Unfortunately you will be rejected more often by HR. It's completely unfair, but companies can't reasonably interview every candidate who submits a resume.)
(I completely get that this is unfair. If you went to MIT and have a high GPA, you are gonna make it past the gate more often. Community college, but an excellent coder? Unfortunately you will be rejected more often by HR. It's completely unfair, but companies can't reasonably interview every candidate who submits a resume.)
When I get a lot of responses it has been ~100. I have found it pretty easy to read all resumes and pick 10 or so candidates to interview. Compared to the amount of time the interviews take, the sifting through resumes is pretty quick work I think. If there were 500 or 1000 resumes the situation would be different, but then I’d perhaps use a HR/recruiter person to just give me the 100 that meet the requirements. No phone screen or coding challenge needed.
This. I think it's just laziness to not even consider publicly -available hobby code. I get that some people don't have time to create hobby code. But if it's there, I don't see why programming trivia and timed programming challenges should take precedence.
Sorry but interviews at the big tech companies have become so easy these days, due to their insatiable demand for "talent", that I can't really hear these whinings about difficult interviews anymore. The candidates we usually get are just absolutely inadequate at coding and behavioral questions. This is not something you can overlook. They just lack the very basic skills to express themselves in code even when disregarding the correctness of their solutions.
"You can't invert a binary tree". Well doh! Maybe you should go through the effort of at least looking at some of the basic algorithmic concepts again, you know just to show that you even remotely care to be hired by the company. They have a much harder job than you do. They get hundred thousands of applicants per month and need to filter them out. You are one person applying at maybe 2-3 companies a month or week.
To me, this sounds like someone who thinks too highly of himself and "he doesn't need to prove himself to a FANNG company". Well think again, writing Homebrew doesn't mean anything. Pretty much anyone at a FANNG company could do that, but not everyone wants to do it. If you want to work at FANNG instead Homebrew, you need to prove yourself to them, not vice versa...
Is it really too much to ask to spend a few days solving some programming puzzles on a whiteboard? If few days are not enough, then maybe you really aren't as smart as you think?
I think people these days really tend to always put the blame on others. What about starting to look at yourself more critically, think about if you are really a "senior" engineer? I work in tech for years now at FANNG companies and "senior engineers" are in a different league. I think I will get there in one or two years but it has been a long ride. These people are paradigms of programming that can always give you useful insights and advise. They excel at a wide range of soft skills and management too.
If you see what most companies (outside of FANNG) consider "senior" you will know why (1) senior engineer means absolutely nothing and (2) why FANNG is not interested whatsoever if you were a senior engineer somewhere else...
"You can't invert a binary tree". Well doh! Maybe you should go through the effort of at least looking at some of the basic algorithmic concepts again, you know just to show that you even remotely care to be hired by the company. They have a much harder job than you do. They get hundred thousands of applicants per month and need to filter them out. You are one person applying at maybe 2-3 companies a month or week.
To me, this sounds like someone who thinks too highly of himself and "he doesn't need to prove himself to a FANNG company". Well think again, writing Homebrew doesn't mean anything. Pretty much anyone at a FANNG company could do that, but not everyone wants to do it. If you want to work at FANNG instead Homebrew, you need to prove yourself to them, not vice versa...
Is it really too much to ask to spend a few days solving some programming puzzles on a whiteboard? If few days are not enough, then maybe you really aren't as smart as you think?
I think people these days really tend to always put the blame on others. What about starting to look at yourself more critically, think about if you are really a "senior" engineer? I work in tech for years now at FANNG companies and "senior engineers" are in a different league. I think I will get there in one or two years but it has been a long ride. These people are paradigms of programming that can always give you useful insights and advise. They excel at a wide range of soft skills and management too.
If you see what most companies (outside of FANNG) consider "senior" you will know why (1) senior engineer means absolutely nothing and (2) why FANNG is not interested whatsoever if you were a senior engineer somewhere else...
> "You can't invert a binary tree". Well doh! Maybe you should go through the effort of at least looking at some of the basic algorithmic concepts again, you know just to show that you even remotely care to be hired by the company.
Who cares if you can invert a binary tree? Who cares if you can write a binary tree? I know what I've needed to know really well, because when it hit me in the face, I learned it. If I need a self-balancing whatever, chances are I'm gonna grab one off the shelf and call SomeBTree.new(args).
The problem with "maybe you should have just learned those simple concepts" is that there are an infinite number of clever questions interviewers try to ask, and close to none of those questions matter. The management that wants to have confidence that applicants can verse a binary tree is also the management that would not let you budget the time to create a binary tree if you actually needed one from scratch... "you shouldn't have to worry about that, just ship it and move on".
Most of my job as a dev seems to be cleaning up the messes of someone that cleverly coded everyone else into a slow, unmaintainable mess. How interviewing for that?!
Who cares if you can invert a binary tree? Who cares if you can write a binary tree? I know what I've needed to know really well, because when it hit me in the face, I learned it. If I need a self-balancing whatever, chances are I'm gonna grab one off the shelf and call SomeBTree.new(args).
The problem with "maybe you should have just learned those simple concepts" is that there are an infinite number of clever questions interviewers try to ask, and close to none of those questions matter. The management that wants to have confidence that applicants can verse a binary tree is also the management that would not let you budget the time to create a binary tree if you actually needed one from scratch... "you shouldn't have to worry about that, just ship it and move on".
Most of my job as a dev seems to be cleaning up the messes of someone that cleverly coded everyone else into a slow, unmaintainable mess. How interviewing for that?!
Ha, I have not had the same experience as you on senior programmers at FANG companies.
> Is it really too much to ask to spend a few days solving some programming puzzles on a whiteboard?
Yes.
It's not a matter of capability - in over 20 professional years I've yet to run into a problem I couldn't solve when I was motivated to do so - either because my job required it, or just because it was interesting.
It's a matter of valuing my time. I do. Companies that want to put me through 12+ hours of interviews and exercises do not. And if they can't value it for interviewing purposes, chances seem very low that they'll value it when I'm an employee.
Yes.
It's not a matter of capability - in over 20 professional years I've yet to run into a problem I couldn't solve when I was motivated to do so - either because my job required it, or just because it was interesting.
It's a matter of valuing my time. I do. Companies that want to put me through 12+ hours of interviews and exercises do not. And if they can't value it for interviewing purposes, chances seem very low that they'll value it when I'm an employee.
The answer 10 minutes ago was I can't invert a binary tree - I didn't know what that meant. I just did a google, and now I can. How did I become more valuable of a hire?
Is this 'invert a binary tree' really nothing but a simple puzzle, solved by swapping left and right children? There are probably better examples then this case.
Crap like this is why I won't interview with a few larger companies and are a major turn off when smaller ones pull this garbage. I'm one of the people that when you try to quiz me my mind blanks. I hate whiteboard programming and prefer solutioning instead. If you want to see code I have a github I can send you. Or you can send me a programming challenge I can complete on my own time. Things like this have actually led me to basically tell at least one large company to cease and desist all recruitment efforts with me.
I straight up refuse coding challenges. I code in the open on GitHub quite often and have built plenty of very high quality (and complex) web applications which I can go into intricate detail about. If your company can’t figure out I’m a good hire without having me jump through your hoops then your process is trash and I have no interest in working for you.
In fact, I’ve been thinking how I would approach interviewing candidates. It seems to me a much better way to interview would be to have candidates do a bit of a show and tell with a project they found challenging. Come in, bring your computer, show me what you’ve built. I’ll do my best to understand it, then I’ll ask questions about it: which aspect was the most technically challenging and why, what was your favourite part to work on, least favourite and why, what would be your scaling strategy and have them go into detail about that, etc. I’d much rather hear how a person answers questions about a project they’re very familiar with than have them do a bunch of arbitrary code problems. What’s wrong with this approach?
In fact, I’ve been thinking how I would approach interviewing candidates. It seems to me a much better way to interview would be to have candidates do a bit of a show and tell with a project they found challenging. Come in, bring your computer, show me what you’ve built. I’ll do my best to understand it, then I’ll ask questions about it: which aspect was the most technically challenging and why, what was your favourite part to work on, least favourite and why, what would be your scaling strategy and have them go into detail about that, etc. I’d much rather hear how a person answers questions about a project they’re very familiar with than have them do a bunch of arbitrary code problems. What’s wrong with this approach?
That’s great. But for some reason every github profile I get to review is just an empty shell or a bunch of one commit Mooc templates. I’ve almost stopped looking at them.
You could take that a great filter: if people explicitly lead you to their empty GitHub account, what does it say about their judgement?
There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments and cannot talk about the projects they are working/worked on recently without violating contracts.
Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. They basically shut down. Doing the process you outline will optimize for talkers, and the industry is full of people that can talk but can't do.
Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. They basically shut down. Doing the process you outline will optimize for talkers, and the industry is full of people that can talk but can't do.
> There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments
Don't take those jobs if you want to be hireable I guess? You'd have to be joking to think a HackerRank quiz is going to help you glean any information about their expertise. Such expertise, by the way, is something I'd like to know about. Figure out a way to talk about it. Tell me the situation (you can't disclose real details) and then tell me about a hypothetical project with similar parameters in a way that doesn't break your contract. Or make up an imaginary project -- if you're actually a good programmer you can come up with something that sheds light on your technical ability and understanding.
> Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily.
I'm sorry, soft skills are essential at my imaginary company. You need to be able to explain your thinking at an abstract level. I don't care if you can't do whiteboard problems, I get that - I can't either - but you do have to be able to walk through problems with other people. Especially problems that you know and understand well. If it's the interview environment that's the problem, well I'd like to informalize that process as well too so people don't feel so nervous about the whole thing. But if you can't explain a problem to somebody 1 on 1 then you'll probably be a very annoying person to work with.
> Doing the process you outline will optimize for talkers
It would optimize for "explainers", not "talkers". Talkers are usually people who can't explain something, and they're fairly easy to weed out from the people who actually know their stuff.
Don't take those jobs if you want to be hireable I guess? You'd have to be joking to think a HackerRank quiz is going to help you glean any information about their expertise. Such expertise, by the way, is something I'd like to know about. Figure out a way to talk about it. Tell me the situation (you can't disclose real details) and then tell me about a hypothetical project with similar parameters in a way that doesn't break your contract. Or make up an imaginary project -- if you're actually a good programmer you can come up with something that sheds light on your technical ability and understanding.
> Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily.
I'm sorry, soft skills are essential at my imaginary company. You need to be able to explain your thinking at an abstract level. I don't care if you can't do whiteboard problems, I get that - I can't either - but you do have to be able to walk through problems with other people. Especially problems that you know and understand well. If it's the interview environment that's the problem, well I'd like to informalize that process as well too so people don't feel so nervous about the whole thing. But if you can't explain a problem to somebody 1 on 1 then you'll probably be a very annoying person to work with.
> Doing the process you outline will optimize for talkers
It would optimize for "explainers", not "talkers". Talkers are usually people who can't explain something, and they're fairly easy to weed out from the people who actually know their stuff.
You misunderstand. There is a very common class of engineers that have no problem describing and explaining their work to their peers.
They do have a problem with doing it in an adversarial and stressful situation like an interview. I've seen it happen to engineers I _know_ are good.
Also, over years of actually engineering hiring pipelines for software engineers, I've seen no evidence that its easy to weed out the good talkers. Quite the opposite I think it's one of he hardest things about designing these pipelines.
> Don't take those jobs if you want to be hireable I guess?
My point about this is not on behalf of the person being hired, its the person doing the hiring. Your process creates false negatives. False negatives in hiring pipelines is nearly as expensive as false positives.
They do have a problem with doing it in an adversarial and stressful situation like an interview. I've seen it happen to engineers I _know_ are good.
Also, over years of actually engineering hiring pipelines for software engineers, I've seen no evidence that its easy to weed out the good talkers. Quite the opposite I think it's one of he hardest things about designing these pipelines.
> Don't take those jobs if you want to be hireable I guess?
My point about this is not on behalf of the person being hired, its the person doing the hiring. Your process creates false negatives. False negatives in hiring pipelines is nearly as expensive as false positives.
The best interview I had, we worked through a real world project - a like button widget to allow 3rd party sites to embed. We talked about the DB choice, the front end structure, etc. It was great.
Unfortunately that was the company that was all 25-year-olds and had a terrible commute, and when they heard my previous salary all interest dried up. But all interviews should be like that imo.
Unfortunately that was the company that was all 25-year-olds and had a terrible commute, and when they heard my previous salary all interest dried up. But all interviews should be like that imo.
I reject senior software engineers all the time. I give interviews on whatever language you're most comfortable in, I'm not interested in time or space complexity, I just care about how well you can use your tools and debug.
I'm continually astounded at the number of people who can't sort a list (with their language's standard library), clone an array, or do basic string manipulation. I've had a staff engineer at Google ask what the sleep command is in JavaScript. A senior engineer from Twitter didn't know how to use arrays ("We don't really use arrays in Scala").
I don't disagree that many companies do interviews wrong. But there's also a huge number of "senior" engineers who simply shouldn't be senior in the first place. Perhaps it's a result of companies handing out promotions to keep folks around rather than to recognize talent.
I'm continually astounded at the number of people who can't sort a list (with their language's standard library), clone an array, or do basic string manipulation. I've had a staff engineer at Google ask what the sleep command is in JavaScript. A senior engineer from Twitter didn't know how to use arrays ("We don't really use arrays in Scala").
I don't disagree that many companies do interviews wrong. But there's also a huge number of "senior" engineers who simply shouldn't be senior in the first place. Perhaps it's a result of companies handing out promotions to keep folks around rather than to recognize talent.
Lol. At my job, I code in several different languages. Sometimes, a new project requires me to to learn to write in a new language. It's not a big deal... Programming is pretty general, so new syntax doesn't slow me down too much.
But I can't tell you what the sleep command is any of these languages. I look it up every single time :P
But I can't tell you what the sleep command is any of these languages. I look it up every single time :P
Same here. Also using sleep for anything other than debug is code smell.
I’m starting to experience that too, where as the breadth of languages learned widens I forget the language specifics and really keep the generic terminology keen. Searching questions like how to sleep in LanguageX, how to iterate, create a thread, whatever need be.
https://en.wikipedia.org/wiki/Interference_theory#Retroactiv...
https://en.wikipedia.org/wiki/Interference_theory#Retroactiv...
Me too. But how do you deal with this when you're interviewing? I'm more skilled and productive than ever but I feel like an idiot without access to documentation.
LOL, agreed.
I'm good with the sleep command in my many different languages. It's dealing with dates in any language...
I suspect 10% of of StackOverFlow hits are developers remembering how to parse a date in some form or another.
I'm good with the sleep command in my many different languages. It's dealing with dates in any language...
I suspect 10% of of StackOverFlow hits are developers remembering how to parse a date in some form or another.
I'm in exactly the same boat. I've used 4 different stacks in the last year. It's too much. I can easily get in and debug and write code in basically any environment, but I don't have time to learn all the string methods of any particular language. Google all the way, and official docs (if they're any good). I rewrote an entire huge module in C#/.NET, have zero experience with that environment in the past. I would absolutely flunk a C# interview but I'm pretty confident in my ability to get work done.
I don't think there's a sleep command in Javascript. It is against the "entire browser runs in a single thread" model, and it would make no sense up to very recently before promises were created (what it would do? start a call-back?).
If the question is from somebody with extensive experience in JS, that's a clear red flag (I don't have any extensive experience in JS). If it's from somebody with passing experience, it's not that bad. That said, I have no idea how to call sleep in any of the ~4 languages I'm currently using either.
If the question is from somebody with extensive experience in JS, that's a clear red flag (I don't have any extensive experience in JS). If it's from somebody with passing experience, it's not that bad. That said, I have no idea how to call sleep in any of the ~4 languages I'm currently using either.
They wanted the sleep command...so they could wait for an XHR to complete. So in context, it was a pretty massive red flag.
[deleted]
This. A million times over. I lead the engineering and run the hiring and I too just turn down senior engineers left and right at times.
We run about as practical a process as I can imagine. A short take home exercise where you use your own environment and build a very small project and are free to even have a starter ready to go ahead of time to focus on the question asked.
In house we have a project you work on on our code base. Very small. Maybe ends up requiring less than 20-30 lines of code for the day. Most people who come in are always familiar with our stack.
The amount of people that just fall on their face is astonishing. Many people will be fine with Greenfield development but then have zero skills being able to deal with an existing code base with places stubbed out with //todos and the ability to pair with people on the team.
I'm convinced people are getting turned down not because of the interview process, but because they just aren't that good at the end of the day.
Yes. I do not need a bunch of code wizards, we aren't solving if p=np daily. But that doesn't mean I should accept people who can't code I'm hopes of them growing into fine developers. I can do that worth one person, but not when bringing on 8.
We run about as practical a process as I can imagine. A short take home exercise where you use your own environment and build a very small project and are free to even have a starter ready to go ahead of time to focus on the question asked.
In house we have a project you work on on our code base. Very small. Maybe ends up requiring less than 20-30 lines of code for the day. Most people who come in are always familiar with our stack.
The amount of people that just fall on their face is astonishing. Many people will be fine with Greenfield development but then have zero skills being able to deal with an existing code base with places stubbed out with //todos and the ability to pair with people on the team.
I'm convinced people are getting turned down not because of the interview process, but because they just aren't that good at the end of the day.
Yes. I do not need a bunch of code wizards, we aren't solving if p=np daily. But that doesn't mean I should accept people who can't code I'm hopes of them growing into fine developers. I can do that worth one person, but not when bringing on 8.
I've met a ton of people like this. They were all people who used to be engineers, but moved into more management centric roles. Their title was still "Senior Engineer" or something similar, but their skill set was almost entirely cat wrangling.
I had one guy get very angry with me when I asked him a programming question; he insisted that that just wasn't what a senior dev did.
I had one guy get very angry with me when I asked him a programming question; he insisted that that just wasn't what a senior dev did.
I've written in so many languages that I wouldn't be able to answer how to sleep in language X off the top of my head. Is it time.Sleep()? delay()? wait_for()? nsleep()? timer().delayUntil()? something else? No clue, but I know how to find out.
You're not hiring me for my encyclopedic knowledge; you're hiring me because I get the job done quickly and effectively, using a proper design and clean, tested code.
You're not hiring me for my encyclopedic knowledge; you're hiring me because I get the job done quickly and effectively, using a proper design and clean, tested code.
Not to mention, there is no sleep command (I assume he meant setTimeout, which has very different functionality than a typical language's sleep command) in javascript, which kind of makes me question the credibility of someone insisting on gatekeeping the senior developer title so hard.
Maybe that was the OPs point? The paradigm of Javascript is incompatible with having a sleep() command, and an experienced Javascript programmer should know that?
There is no sleep command. They didn't understand how callbacks worked at all. In JavaScript, that's fundamental. He wanted to poll with sleeps.
Memorizing the method for sleep in javascript is the least of a staff engineer's concerns at Google. Besides, with something as easy to google and aided by the IDE, do you REALLY care? What matters is that the guy is able to design and structure a solution, google whatever he needs and build it. At his level, he'd guide a team working on such projects and be concerned with high level design, working with management and managing large $$$ projects.
Do your engineers work out of a cave with no internet and code on cave walls?
Do your engineers work out of a cave with no internet and code on cave walls?
There is no sleep command in JavaScript. He fundamentally didn't understand that JavaScript used callbacks and wanted to poll for an XHR's completion.
The job was to write JavaScript, not to do any architecting. There was nothing unclear about the job role. And they had claimed to have built [a very important dashboard that I won't mention to keep them anonymous] mostly themselves, which was quickly disproved.
The job was to write JavaScript, not to do any architecting. There was nothing unclear about the job role. And they had claimed to have built [a very important dashboard that I won't mention to keep them anonymous] mostly themselves, which was quickly disproved.
I can write fizzbuzz and while I don’t code in JavaScript I could take a guess at sleep from ruby, python and java. I’ve interviewed lately so I’m trained up and could print all paths in a binary tree or all permutations of a set, or detect cycles in a linked list. It’s not all rote, I can adapt and apply these techniques. I have done so at work.
But I couldn’t find all matching sub trees within a binary tree at the whiteboard in an hour (45 min really). I haven’t done a formal survey, but my extensive experience and discussions with a lot of devs tells me that this really isn’t about fizzbuzz or other simple things.
It’s time to stop pretending this is about weeding out people who can’t code. Companies by their own admission set a very high false negative rate.
Then they claim there is a shortage and successfully lobby the government to create a shadow immigration system putting tech companies in charge of who gets to work in the US and the conditions under which they are allowed to remain.
But I couldn’t find all matching sub trees within a binary tree at the whiteboard in an hour (45 min really). I haven’t done a formal survey, but my extensive experience and discussions with a lot of devs tells me that this really isn’t about fizzbuzz or other simple things.
It’s time to stop pretending this is about weeding out people who can’t code. Companies by their own admission set a very high false negative rate.
Then they claim there is a shortage and successfully lobby the government to create a shadow immigration system putting tech companies in charge of who gets to work in the US and the conditions under which they are allowed to remain.
When the next recession hits, this will be even more of a problem.
I think Software Development has a problem in that there is no space for a middle-ground career path. I typically compare myself to a studio musician. I'm never going to be a Rock Star, but you can plug me into any band and we'll make a good recording. That's why I like contract work... nobody cares about my age or history, I can just hit my marks and do what I love. I'm not Senior, but I don't know if I really ever want to be either.
I think Software Development has a problem in that there is no space for a middle-ground career path. I typically compare myself to a studio musician. I'm never going to be a Rock Star, but you can plug me into any band and we'll make a good recording. That's why I like contract work... nobody cares about my age or history, I can just hit my marks and do what I love. I'm not Senior, but I don't know if I really ever want to be either.
What exactly is the "sleep" command in javascript?
There isn't one. The candidate didn't know how callbacks worked.
You're missing the forest for the trees here. In these larger companies, senior engineers tend not to work directly with code that much anymore, they're usually working on higher level problems like system design or management. These require different skill sets such as leadership and social skills that take years to develop; the ability to google quickly for a function name isn't really valued as much.
If you're working in a small company or a startup, then you don't need BigCo senior engineers, you can get away with people who haven't developed these skill sets. However if you have intentions of growing, either in your system size or in your headcount, you shouldn't discount these engineers over minor details like this. Ask them higher-level design questions if you actually want to test their abilities, otherwise you're looking at the wrong metrics.
If you're working in a small company or a startup, then you don't need BigCo senior engineers, you can get away with people who haven't developed these skill sets. However if you have intentions of growing, either in your system size or in your headcount, you shouldn't discount these engineers over minor details like this. Ask them higher-level design questions if you actually want to test their abilities, otherwise you're looking at the wrong metrics.
> you shouldn't discount these engineers over minor details like this.
Then they should apply for a job where their skills are relevant. If you're applying for a job where you're writing code (like all of the ones I described), you'd better be able to code.
Edit: and we let you Google whatever you need in the interview. If you can't figure out how to clone an array (an implementation detail of the interview question) on your own, I don't know what role you think you're applying for.
Then they should apply for a job where their skills are relevant. If you're applying for a job where you're writing code (like all of the ones I described), you'd better be able to code.
Edit: and we let you Google whatever you need in the interview. If you can't figure out how to clone an array (an implementation detail of the interview question) on your own, I don't know what role you think you're applying for.
> If you're applying for a job where you're writing code (like all of the ones I described), you'd better be able to code.
That's fair. No sense in bringing in architecture astronauts who can't translate their dreams to reality.
> we let you Google whatever you need in the interview
Right, rejecting someone who can't Google things properly is the correct choice. That's a skill that's useful at all levels.
That's fair. No sense in bringing in architecture astronauts who can't translate their dreams to reality.
> we let you Google whatever you need in the interview
Right, rejecting someone who can't Google things properly is the correct choice. That's a skill that's useful at all levels.
I call shenanigans on this comment. Weeding out folks for not knowing how to sleep in a particular language or array syntax in another is not warranted. I think the response that Scala doesn't have arrays is totally legitimate. You should have asked them what was the project/problem they were most proud of and suss out the details of that.
Moreover, keep in mind that for some orgs a Senior dev is actually someone that does more systems design, i.e. an architect. Make sure you ask them those sorts of questions before discounting their abilities. You don't want to be having an architect refactoring your frontend, that's a silly way to spend your money.
Moreover, keep in mind that for some orgs a Senior dev is actually someone that does more systems design, i.e. an architect. Make sure you ask them those sorts of questions before discounting their abilities. You don't want to be having an architect refactoring your frontend, that's a silly way to spend your money.
In all of the above cases, the candidate had no fundamental knowledge of their chosen language. All of the jobs I was hiring for were for positions that involved writing code. None of these were roles that involved more thought leadership than coding.
I should have been more clear about the JavaScript issue: there is no sleep command. The candidate didn't know how callbacks worked. In JavaScript. Callbacks in JavaScript are how _everything_ works.
I should have been more clear about the JavaScript issue: there is no sleep command. The candidate didn't know how callbacks worked. In JavaScript. Callbacks in JavaScript are how _everything_ works.
just give fizzbuzz and call it a day. It sounded like you were asking about array to someone who doesn't use them and penalizing them.
Someone who's been writing code professionally at a software company (especially google or twitter), definitely has at least a moderate if not high level of proficiency in software engineering.
if these highly competent people can't answer your questions, you really need to take a second look at your Questions.
if these highly competent people can't answer your questions, you really need to take a second look at your Questions.
I'm suggesting that they weren't highly competent.
Wow. So you base your hire decisions on pop quiz answers?
Have you worked in the industry for longer than 2 years?
> ask what the sleep command is in JavaScript.
> We don't really use arrays in Scala
These all seem like genuine things. In more complex companies, people may use more exotic data structures and/or have abstractions around data access.
Silly comment overall.
Have you worked in the industry for longer than 2 years?
> ask what the sleep command is in JavaScript.
> We don't really use arrays in Scala
These all seem like genuine things. In more complex companies, people may use more exotic data structures and/or have abstractions around data access.
Silly comment overall.
None of the examples were trivia. These were examples of what the candidates got stuck on in a larger interview question, with the ability to use Google to look things up.
I don't care what kind of abstractions you have at your current company. We don't (/didn't) have those abstractions. If you can't show me that you can do CS101 basics (appending to an array?) in the language that you claim to write day to day, how can I trust you to be able to write the code that we describe in the job description?
I don't care what kind of abstractions you have at your current company. We don't (/didn't) have those abstractions. If you can't show me that you can do CS101 basics (appending to an array?) in the language that you claim to write day to day, how can I trust you to be able to write the code that we describe in the job description?
> CS101 basics (appending to an array?)
Probably because most professionals are not fresh out of CS101 & most data structures aren't arrays or exposed as arrays.
List, Collections, Map, Trees, home-rolled data structures better suited to domain - how do you not get this?
Your opinion sounds like that of someone just out of a bootcamp. You're putting all the weight on irrelevant syntax issues. A lot of devs use multiple languages day to day amongst other things.
Probably because most professionals are not fresh out of CS101 & most data structures aren't arrays or exposed as arrays.
List, Collections, Map, Trees, home-rolled data structures better suited to domain - how do you not get this?
Your opinion sounds like that of someone just out of a bootcamp. You're putting all the weight on irrelevant syntax issues. A lot of devs use multiple languages day to day amongst other things.
We need to take this to its logical conclusion. If the claim is that these kinds of interviews don't work, then what should we be seeing out there? Are companies that employ these techniques less successful, or less productive, or less something-else? Because its not easy to tell someone they're doing it wrong, when what they're doing is working for them and making money. Without actually showing how these kinds of interviews are detrimental to their bottom line, its only going to fall on deaf ears.
I take a completely different approach to hiring, and I've gotten fantastic results.
Instead of throwing tricky algorithm questions at a candidates, I scour their detailed employment records for the most relevant experience for the first project. In other words, I'm looking for relevant experience rather than top-of-the-head algorithmic brilliance. In the interview, I pose our project problem, and the candidate who gives me the most impressive proposal to get that done gets a chance to solve it.
I hire from an international pool, often on Upwork, so I can start developers on a project basis.
If the developer does a great job, we hire him/her for another project, and so on. At some point, this becomes a full-time relationship, with stock options and other perks.
Using this approach, we value experience over "raw intelligence," per se, and we end up with a team of self-directed developers who are fabulous at delivering great finished products.
It's amazing how well this has worked out for us. I think there's an arbitrage opportunity to avoid coding tests and hire on this basis.
Instead of throwing tricky algorithm questions at a candidates, I scour their detailed employment records for the most relevant experience for the first project. In other words, I'm looking for relevant experience rather than top-of-the-head algorithmic brilliance. In the interview, I pose our project problem, and the candidate who gives me the most impressive proposal to get that done gets a chance to solve it.
I hire from an international pool, often on Upwork, so I can start developers on a project basis.
If the developer does a great job, we hire him/her for another project, and so on. At some point, this becomes a full-time relationship, with stock options and other perks.
Using this approach, we value experience over "raw intelligence," per se, and we end up with a team of self-directed developers who are fabulous at delivering great finished products.
It's amazing how well this has worked out for us. I think there's an arbitrage opportunity to avoid coding tests and hire on this basis.
Yeah this somehow still works for pretty much every other profession, and worked fine for programming until a few years ago when everyone decided timed programming challenges were the way to go.
I wish all jobs could just hire devs for short contracts then convert the keepers to full time. I'd be more than happy in that scenario because I know they'll want to convert me and now it's up to me.
I wish all jobs could just hire devs for short contracts then convert the keepers to full time. I'd be more than happy in that scenario because I know they'll want to convert me and now it's up to me.
The big problem with this is that the short contract does not guarantee continuity of health insurance coverage, and this is a dealbreaker for a lot of folks. The pool of applicants who would accept these offers excludes the top-performing folks who have much better alternatives than contract-to-hire.
Developers who have great insurance coverage at their current job and require it at their next job aren't candidates for startups like mine. We don't have health insurance for employees - it's just too expensive for all but the very well-funded startups.
For this reason, experienced developers from other countries which have universal healthcare coverage and low cost of living, such as many Eastern European Countries, are very attractive to many startups.
For this reason, experienced developers from other countries which have universal healthcare coverage and low cost of living, such as many Eastern European Countries, are very attractive to many startups.
Yup. If you need to hire a juggler, throw them some balls and get them to juggle for you.
You'll get the talented, flexible people that can get things done.
You'll get the talented, flexible people that can get things done.
For our last hire, I was the only one on the hiring committee to ask about past projects. The others defaulted to "fundamentals" questions.
I think the reason people do this is a mix of 1) not knowing what traits to look for 2) not comfortable with unstructured conversation 3) frankly that it takes work to evaluate each resume and research projects enough to have a useful conversation.
For me though, how they achieve success at past work is the best indicator of future success.
I think the reason people do this is a mix of 1) not knowing what traits to look for 2) not comfortable with unstructured conversation 3) frankly that it takes work to evaluate each resume and research projects enough to have a useful conversation.
For me though, how they achieve success at past work is the best indicator of future success.
Yeah this is the M.I.T. and Harvard "process". Hire success, instead of fostering success. Works well for small companies. If you need to hire 10.000 to 30.000 people a year, this approach is absolutely useless.
Also just because someone can't come up with the coolest solution for your project, doesn't mean they aren't good developers. This is even more biased than algorithmic interviews, because algorithmic interviews have structure. I actually CAN solve a puzzle in 20 mins. You definitely can not solve a project in 20 minutes or even an hour. It is impossible. And the best candidates will be those who sit back, analyze the problem for days or even weeks and come up with a good solution for your project. This approach is so infeasible for general interviewing that I don't even know where to begin. You are basically filtering out EVERYONE and take the one person who knew enough upfront to accidentially solve your problem best...
Also just because someone can't come up with the coolest solution for your project, doesn't mean they aren't good developers. This is even more biased than algorithmic interviews, because algorithmic interviews have structure. I actually CAN solve a puzzle in 20 mins. You definitely can not solve a project in 20 minutes or even an hour. It is impossible. And the best candidates will be those who sit back, analyze the problem for days or even weeks and come up with a good solution for your project. This approach is so infeasible for general interviewing that I don't even know where to begin. You are basically filtering out EVERYONE and take the one person who knew enough upfront to accidentially solve your problem best...
He said "impressive proposal", not "coolest solution".
To me, "impressive proposal" means "articulation of a workable plan", the components of which are relatively small, actionable, and take into accounts requirements, and that demonstrates a good understanding of risk. In fact I'd argue that the ability to do this kind of top-level break-down well is one of the best indicators of seniority. The downside is that to do it well requires knowledge of a very specific process, architecture, and technology stack. That is, if you're good at breaking down problems use stateful Erlang and OpenBSD running on bare-metal with web clients, you might have an issue breaking down using stateless C# on Azure with Android native clients. Some combinations are more compatible than others, of course, but any senior dev in one stack is going to have to recapitulate the learning curve of another stack before they can regain this superpower! (We may like to think that only architecture matters, but it is relatively rare that an architecture rendered in one stack is actually isomorphic to the same architecture rendered in another!)
To me, "impressive proposal" means "articulation of a workable plan", the components of which are relatively small, actionable, and take into accounts requirements, and that demonstrates a good understanding of risk. In fact I'd argue that the ability to do this kind of top-level break-down well is one of the best indicators of seniority. The downside is that to do it well requires knowledge of a very specific process, architecture, and technology stack. That is, if you're good at breaking down problems use stateful Erlang and OpenBSD running on bare-metal with web clients, you might have an issue breaking down using stateless C# on Azure with Android native clients. Some combinations are more compatible than others, of course, but any senior dev in one stack is going to have to recapitulate the learning curve of another stack before they can regain this superpower! (We may like to think that only architecture matters, but it is relatively rare that an architecture rendered in one stack is actually isomorphic to the same architecture rendered in another!)
> I hire from an international pool, often on Upwork, so I can start developers on a project basis.
I wish I could always hire developers to start on a project basis, but that's just not possible for many (most?) of the best local candidates. Someone who is great who has a full time job at company A is very, very rarely interested in leaving for company B on a project basis.
I wish I could always hire developers to start on a project basis, but that's just not possible for many (most?) of the best local candidates. Someone who is great who has a full time job at company A is very, very rarely interested in leaving for company B on a project basis.
Here's the problem with doing this in the US: if you're out of a job, you're out of health insurance. If your whole family is on your health insurance plan, you'll never accept a project-based gig that might not become full time. So with this approach, you're filtering out a new and different subset of the applicant pool before they even interview.
Data point: A friend of mine with 20+ years of experience in programming and security (she's been a code-level security analyst for the past decade plus) was asked in an interview the other day to implement a binary tree.
Why the fuck is someone asking a lead-level expert with over two decades of experience a first-year CS question? Because that's the process? It's a total failure. Asking senior people to do basic things like that is insulting. Don't you have anything better to ask?
Why the fuck is someone asking a lead-level expert with over two decades of experience a first-year CS question? Because that's the process? It's a total failure. Asking senior people to do basic things like that is insulting. Don't you have anything better to ask?
Why don’t learn this thing for once? It is not difficult, and everybody will benefit from doing that at least once, even the most senior and accoladed engineers.
She learned it, in college. Her job isn't to write code. And I can't even remember the last time I implemented a damn binary tree.
It's not that it's difficult. It's that it's stupid.
edit: Let me put it this way... if you're hiring a senior/lead level code security analyst, the odds that they will be implementing (or even reading for comprehension) a binary tree are effectively nil. The odds of having to show how to mark false positives in a Fortify scan are very, very high. Can they explain buffer overflows, html encoding, etc? Can they write a description of unsafe practices in plain English, for both developers and managers? Do they have experience in conducting training classes for developers to reduce security problems? Do they have a working knowledge of HIPAA, SOX, or other relevant industry regulations? Can they do good Powerpoint presentations on this stuff?
Being a security analyst isn't about writing homework assignments from freshman year of college. It's about regulations, about training others, about using high end tools that aren't taught in college, and a bunch of other stuff. Ask questions about the actual job.
It's not that it's difficult. It's that it's stupid.
edit: Let me put it this way... if you're hiring a senior/lead level code security analyst, the odds that they will be implementing (or even reading for comprehension) a binary tree are effectively nil. The odds of having to show how to mark false positives in a Fortify scan are very, very high. Can they explain buffer overflows, html encoding, etc? Can they write a description of unsafe practices in plain English, for both developers and managers? Do they have experience in conducting training classes for developers to reduce security problems? Do they have a working knowledge of HIPAA, SOX, or other relevant industry regulations? Can they do good Powerpoint presentations on this stuff?
Being a security analyst isn't about writing homework assignments from freshman year of college. It's about regulations, about training others, about using high end tools that aren't taught in college, and a bunch of other stuff. Ask questions about the actual job.
Well, sure, inverting a binary tree isn't hard to learn. But there's countless interview questions, not just that one. A lot are more tricky - and not everyone is good at coming up with such solutions from first principles under interview pressure.
While I'm reasonably good at these style of questions, I'd be very unsurprised if there were a few that'd just catch me cold, even today. And I'm probably working in a field that's a lot more day-to-day data structure heavy than most (RDBMS internals).
While I'm reasonably good at these style of questions, I'd be very unsurprised if there were a few that'd just catch me cold, even today. And I'm probably working in a field that's a lot more day-to-day data structure heavy than most (RDBMS internals).
Well, did she actually not know, or was she offended by the simplicity of the question? I graduated in ’95, and I still remember how to implement a binary tree, so it’s not like it’s something that’s so irrelevant you’ll forget a few years after graduation like, say, polynomial long division.
She was offended by it, as were a lot of her friends (all industry people with similar experience levels).
Imagine if someone asked you to conjugate verbs or graph sentences to demonstrate your English skills. Would you do well at it, even if you're a native speaker? After all, you learned that stuff in elementary school.
Imagine if someone asked you to conjugate verbs or graph sentences to demonstrate your English skills. Would you do well at it, even if you're a native speaker? After all, you learned that stuff in elementary school.
Is there a market for a licensing body for this stuff? If you believe what you read on Blind, the top companies all test the same material: leetcode, CTCI, design system primer, Designing Data-Intensive Applications, etc.
Why can't I prove that I passed this screen once, then take a piece of paper to each of my FANG interviews and skip the technical part. Then maybe retake it every 5 years if I'm interviewing.
Why can't I prove that I passed this screen once, then take a piece of paper to each of my FANG interviews and skip the technical part. Then maybe retake it every 5 years if I'm interviewing.
I think we’re in the minority around here, but I’d like to see something like a bar exam for professional developers, too. The immediate benefit is that I don’t have to waste time proving that I know how to program a computer over and over again and you don’t have to waste time checking, but it would also be incredibly helpful to know that my coworkers have also passed it, so I know what I can assume they already understand, and what I might need to explain. Of course, I've always been a good test-taker, so maybe I'm biased.
I've passed the bar exam.
It is not a good indicator of competence.
Most people pay a third party (after having paid for law school) to cram the information into their head in a short period of time.
RHCE for example isn't great, but having passed both I think it's actually better than the bar exam, since they at least hand you a live broken server.
It is not a good indicator of competence.
Most people pay a third party (after having paid for law school) to cram the information into their head in a short period of time.
RHCE for example isn't great, but having passed both I think it's actually better than the bar exam, since they at least hand you a live broken server.
This happened to me recently.
I have over 8 years experience as a developer and applied for a Senior .Net Developer role. I have plenty of experience in the technology stack and worked as lead developer on some high profile projects in my current role which have been successful. I'm no rock star but I get stuff done and I work well with others.
The company liked my CV and cover letter and send out a HackerRank link for me to work on. My first thought was "sh*t" as I struggle with these things but also how impersonal it was. The everything was weighted on the HackerRack test. At least speak with the candidate and get a feel for them. Even a phone call.
Hiring as they say is one of the hardest things you can do. It's time consuming and costly so I think they have these tests as away to cull the herd so to speak but it's obviously not ideal. Basecamp have a podcast called rework and one of their episodes called "Hazing not Hiring" deals with this. It's really interesting.
For me, I'm going to try to work on a side project and use this as another part of my application. Almost like a portfolio. Hopefully this will be enough going forward.
I have over 8 years experience as a developer and applied for a Senior .Net Developer role. I have plenty of experience in the technology stack and worked as lead developer on some high profile projects in my current role which have been successful. I'm no rock star but I get stuff done and I work well with others.
The company liked my CV and cover letter and send out a HackerRank link for me to work on. My first thought was "sh*t" as I struggle with these things but also how impersonal it was. The everything was weighted on the HackerRack test. At least speak with the candidate and get a feel for them. Even a phone call.
Hiring as they say is one of the hardest things you can do. It's time consuming and costly so I think they have these tests as away to cull the herd so to speak but it's obviously not ideal. Basecamp have a podcast called rework and one of their episodes called "Hazing not Hiring" deals with this. It's really interesting.
For me, I'm going to try to work on a side project and use this as another part of my application. Almost like a portfolio. Hopefully this will be enough going forward.
I interviewed ~500 people in a fairly large (~2000 devs) company.
Interviews used to take about 6-8 hours of my week, and I was usually completely destroyed by the context switch. I remember many days when a deadline was very close, and I absolutely did not want to do the interview, but had to.
In general some days I was in good mood, some in bad mood and even though I tried to make the interview as objective as possible, I am absolutely sure I failed. Keep in mind, one interview has 5 interviewers and guess what they had bad days too.
From those 500 interviews, I was certain for about ~5 cases, for the rest I could not say if it was my fault, or the candidate's fault that the interview went south, in that case I pretty much voted as the majority was voting.
I still feel very bad about people's livelihood being decided in such shitty process, there is absolutely no way that in 1 hour I can find out if someone is good. I knew that, my managers knew that, their managers knew that, and yet we kept going..
I feel that adding more time/people to the process only increases the variance, adding more structure to the process only increases the bias (like we get people who can pass interviews, but not do their job).
Interviews used to take about 6-8 hours of my week, and I was usually completely destroyed by the context switch. I remember many days when a deadline was very close, and I absolutely did not want to do the interview, but had to.
In general some days I was in good mood, some in bad mood and even though I tried to make the interview as objective as possible, I am absolutely sure I failed. Keep in mind, one interview has 5 interviewers and guess what they had bad days too.
From those 500 interviews, I was certain for about ~5 cases, for the rest I could not say if it was my fault, or the candidate's fault that the interview went south, in that case I pretty much voted as the majority was voting.
I still feel very bad about people's livelihood being decided in such shitty process, there is absolutely no way that in 1 hour I can find out if someone is good. I knew that, my managers knew that, their managers knew that, and yet we kept going..
I feel that adding more time/people to the process only increases the variance, adding more structure to the process only increases the bias (like we get people who can pass interviews, but not do their job).
I am pretty sure I'm a terrible interviewer and interviewee. I've had generally bad experiences all the way around. Interviewing (both sides of the table) has been a big time-suck, yielded mostly unsatisfactory results, and has been an emotionally draining process.
I noticed that my job enjoyment took a hit during a period of heavy interviewing for new devs for all the reasons you mention.
A one hour interview required a minimum of 30 minutes prep to read the resume, etc and generate questions. Then at least 30 minutes to write up my findings in a way that would allow me to participate in the roundup, which could be up to a month away if I was the phone screen. The roundup itself accounted for at least another 30 minutes. So you were 2 hours and 30 minutes into it assuming everything goes perfectly. It's a huge time suck.
But beyond the time that I lost, it's a very difficult and crushing experience to have candidate fail and have to be the one that says "no" (and that is happening way way more than yes, especially if you are interviewing early in the pipeline). But it's equally disheartening to see a spark of something in an interview, tease it out, imagine that the person can be raised up to become a good developer only to have the candidate get shot down by all your colleagues because they didn't have a similar experience.
I disliked losing time during the day, but I really disliked the emotional burden of interviewing and saying "no." I empathize with the person on the other side as I've been there.
A one hour interview required a minimum of 30 minutes prep to read the resume, etc and generate questions. Then at least 30 minutes to write up my findings in a way that would allow me to participate in the roundup, which could be up to a month away if I was the phone screen. The roundup itself accounted for at least another 30 minutes. So you were 2 hours and 30 minutes into it assuming everything goes perfectly. It's a huge time suck.
But beyond the time that I lost, it's a very difficult and crushing experience to have candidate fail and have to be the one that says "no" (and that is happening way way more than yes, especially if you are interviewing early in the pipeline). But it's equally disheartening to see a spark of something in an interview, tease it out, imagine that the person can be raised up to become a good developer only to have the candidate get shot down by all your colleagues because they didn't have a similar experience.
I disliked losing time during the day, but I really disliked the emotional burden of interviewing and saying "no." I empathize with the person on the other side as I've been there.
I really hated the cases were when "no" can not be explained.
In some cases when there is "no" it comes with clear instructions like: hey you need to know v8 more or understand hotspot better and try again in 6 months, but then there were those cases where the committee was incapable of giving feedback.
In some cases when there is "no" it comes with clear instructions like: hey you need to know v8 more or understand hotspot better and try again in 6 months, but then there were those cases where the committee was incapable of giving feedback.
I despise HackerRank and that ilk. I am a (actual) senior engineer at a FAANG in Silicon Valley and can barely do those contrived problems but am approaching my second year at one of the biggest companies in the world working on “serious” build engineering stuff and never once have had to invert a binary tree and display my results using STDOUT.
Honestly, command line Linux skills and a take home (<1 hour) “build an app in <relevant language> that does x” is far more relevant to my work than some timeboxed HackerRank contrived example.
My favorite screening tools have typically been “here is an app with failing tests, fix the failures.” I have been screened out of all manner of dinky companies from these contrived tools. A reasonable oral technical interview to ensure the candidate can communicate within the domain is far more valuable than contrived tests of solving problems unrelated to the actual job. I can learn more about a candidate asking about use cases of SOA than I can by watching them calculate prime numbers.
Honestly, command line Linux skills and a take home (<1 hour) “build an app in <relevant language> that does x” is far more relevant to my work than some timeboxed HackerRank contrived example.
My favorite screening tools have typically been “here is an app with failing tests, fix the failures.” I have been screened out of all manner of dinky companies from these contrived tools. A reasonable oral technical interview to ensure the candidate can communicate within the domain is far more valuable than contrived tests of solving problems unrelated to the actual job. I can learn more about a candidate asking about use cases of SOA than I can by watching them calculate prime numbers.
Interviewing is broken. Whiteboard tests with a bunch of algorithm and data structures questions are meaningless and have no relevance to reality. If I ran engineering, this is what I'd have candidates do.
1. Initial video conf meeting to make sure he/she can communicate well. Talk about the role. Have a technical discussion covering candidate's past experiences to evaluate whether they really did what they claimed to have done. Discuss a technical subject that the candidate is passionate about. If satisfied, go to Step 2
2. If the candidate is a strong referral, go to Step 3. Otherwise, do a technical phone interview where the candidate solves a simple problem (more complex than FizzBuzz but not the standard algo/DS/string manipulation question)
3. Onsite Interview. Session 1 - write a simple service (todo list, twitter clone, etc) - 2 hours. 4. Session 2 - Ask the candidate to do a code review where the code in question has bugs and is poorly designed. 5. Session 3 - Candidate does a presentation of some technical topic to the team or at least a few people in the team. 6. Session 4 - Lunch 7. Session 5 - System Design exercise focusing on testing candidate's depth
Train interviewers to provide objective feedback. Calibrate scores for each question ahead of time. Interviewers should be calibrated as well. Ideally, same pool of interviewers for each question.
1. Initial video conf meeting to make sure he/she can communicate well. Talk about the role. Have a technical discussion covering candidate's past experiences to evaluate whether they really did what they claimed to have done. Discuss a technical subject that the candidate is passionate about. If satisfied, go to Step 2
2. If the candidate is a strong referral, go to Step 3. Otherwise, do a technical phone interview where the candidate solves a simple problem (more complex than FizzBuzz but not the standard algo/DS/string manipulation question)
3. Onsite Interview. Session 1 - write a simple service (todo list, twitter clone, etc) - 2 hours. 4. Session 2 - Ask the candidate to do a code review where the code in question has bugs and is poorly designed. 5. Session 3 - Candidate does a presentation of some technical topic to the team or at least a few people in the team. 6. Session 4 - Lunch 7. Session 5 - System Design exercise focusing on testing candidate's depth
Train interviewers to provide objective feedback. Calibrate scores for each question ahead of time. Interviewers should be calibrated as well. Ideally, same pool of interviewers for each question.
Presumably you would only hire people for a very high level, very well compensated role, and those individuals would plan on staying for a decade or more?
I'm not saying your process wouldn't be effective, but it is asking for a very big commitment for one interview for one position at one company. (And that same commitment would have to come from your company and all the interviewers involved!)
I'm not saying your process wouldn't be effective, but it is asking for a very big commitment for one interview for one position at one company. (And that same commitment would have to come from your company and all the interviewers involved!)
Not sure why I understand why this is a big commitment. The first two steps (manager call and a tech interview) are already happening. I'm changing the onsite to exclude whiteboard programming and do real hands-on keyboard programming plus code reviews and presentation which are all things that an engineer is expected to do.
I'm a senior developer, and my wife is a corporate recruiter (at another company). The frustration both parties experience with the hiring process is palpable, and leads to some of our most eye-opening dinner table conversations.
On the developer side, whiteboards feel like having to study for the SATs again, which is doubly frustrating at the senior level because you know better than before how little these questions correlate to qualification. Irrelevant, spam-esque LinkedIn messages from recruiters confirm how sloppy the whole process feels. And you spend the whole time thinking, there just HAS to be a better way.
On the recruiter side, they have to wade through a horrifyingly-unmanageable torrent of unqualified resumes with the help of bad tools. When a great candidate fails their test and can't move forward through the process, the recruiter is almost as frustrated with the process as the applicant (management, I'm told, remains unwavering in their commitment to "establishing a baseline"). Even worse are the candidates who are filtered out from the process by Applicant Tracking Systems because their resume lists "8+ years of experience with a wide variety of NoSQL databases" and not "MongoDB"
I think both parties recognize the inefficiencies in the process. Where we've landed is the following:
- Developers need to learn to play the game. Understand how much of a black hole "Easy Apply" buttons can be and not rely on them, optimize their resumes for the role (including anticipation of boolean searches based on the job posting), and make meaningful connections with their local tech communities so recruiters know where to find them.
- Recruiters need to advocate for flexibility and transparency in the process. Workflows involving "shoving as many people into the funnel as possible and use an ATS to sort through the noise" are untenable. Reconsider systems that treat whiteboards or tests as requirements and not just data points. Offer up relevant information earlier, with the hope that good applicants will use that info, and their honesty, to help you figure out if they're a good fit.
On the developer side, whiteboards feel like having to study for the SATs again, which is doubly frustrating at the senior level because you know better than before how little these questions correlate to qualification. Irrelevant, spam-esque LinkedIn messages from recruiters confirm how sloppy the whole process feels. And you spend the whole time thinking, there just HAS to be a better way.
On the recruiter side, they have to wade through a horrifyingly-unmanageable torrent of unqualified resumes with the help of bad tools. When a great candidate fails their test and can't move forward through the process, the recruiter is almost as frustrated with the process as the applicant (management, I'm told, remains unwavering in their commitment to "establishing a baseline"). Even worse are the candidates who are filtered out from the process by Applicant Tracking Systems because their resume lists "8+ years of experience with a wide variety of NoSQL databases" and not "MongoDB"
I think both parties recognize the inefficiencies in the process. Where we've landed is the following:
- Developers need to learn to play the game. Understand how much of a black hole "Easy Apply" buttons can be and not rely on them, optimize their resumes for the role (including anticipation of boolean searches based on the job posting), and make meaningful connections with their local tech communities so recruiters know where to find them.
- Recruiters need to advocate for flexibility and transparency in the process. Workflows involving "shoving as many people into the funnel as possible and use an ATS to sort through the noise" are untenable. Reconsider systems that treat whiteboards or tests as requirements and not just data points. Offer up relevant information earlier, with the hope that good applicants will use that info, and their honesty, to help you figure out if they're a good fit.
For those folks who work for companies that ask these puzzle questions during the interviews, have you guys ever brought on a "bad" candidate? And, would you say that your colleagues produce better work than the average engineer?
> Prepare for the programming test gates now while you have the luxury of time.
Yep. If you're asking for hundreds of thousands of dollars a year in compensation, then you'd better be prepared to jump through some hoops.
Yep. If you're asking for hundreds of thousands of dollars a year in compensation, then you'd better be prepared to jump through some hoops.
Knowing how to do something before I've done it hasn't ever stopped me from doing it, or doing it right.
The important skill to learn is figuring out how to do it. Coding is no different. For example, I've yet to use React to build an app, but I have taken the time to learn the basics of how it works. If I needed to use it I could, and would, and it wouldn't slow me down much, if at all.
I think what's important is discovering how adaptable one is. If one gets whiny about using a specific toolset they're going to be a problem no matter what you put them on that requires something different than their existing skill set.
The important skill to learn is figuring out how to do it. Coding is no different. For example, I've yet to use React to build an app, but I have taken the time to learn the basics of how it works. If I needed to use it I could, and would, and it wouldn't slow me down much, if at all.
I think what's important is discovering how adaptable one is. If one gets whiny about using a specific toolset they're going to be a problem no matter what you put them on that requires something different than their existing skill set.
> ”I’ve yet to use React to build an app, but I have taken the time to learn the basics of how it works. If I needed to use it I could, and would, and it wouldn't slow me down much, if at all.”
TripleByte has a very clear process which leads to a two-hour frontend interview, an hour of which will be dedicated to building something with React.
Give it a try: https://triplebyte.com/iv/NKCtNG2/it
You’ll surely learn something.
I did.
TripleByte has a very clear process which leads to a two-hour frontend interview, an hour of which will be dedicated to building something with React.
Give it a try: https://triplebyte.com/iv/NKCtNG2/it
You’ll surely learn something.
I did.
That's actually good as long as there are companies out there that get it right https://github.com/poteto/hiring-without-whiteboards
Avoid the type of corporations that sleepwalk into that type of interviewing out of boredom or lack of knowing any better and head for the type of companies that seem to know what they're looking for. In most cases you'll land in a place you will actually like rather than in yet another freaking soul-less corp job that it just pays the bills.
As an older, experienced developer, this is honestly just a sign of a changing shift in the nature of software companies, and, like it or not, if you want to survive you have to adapt.
I started in software over 10 years ago. At that time all of the exciting jobs where for small startups and the best way to get hired was to have a great github profile or some cool projects to show off.
But small startups need a hand full of really talented devs who can solve a variety of problems, and quickly get up to speed on new domains and tech stacks. A few good developers could make a company. So hiring focused on individuals who stood out and had something unique they could bring to the team.
But FAANG companies want to hire engineers that they can treat as replaceable parts. The "rockstar" talent that was required a decade ago is a liability. This may sound like a critique but it makes perfect sense from the business standpoint, and while you can protest this all you want it won't change a landscape dominated by large software giants to one fill with disrupting startups.
It's just a different world and if you want to show that your "experienced" and not just "old" you need to show that you can adapt just as well as a decade ago. I had a moment of enlightenment when waxing nostalgic about github profiles to a really talented new engineer doing prestigious work in deep learning. I told them how much better profiles based interviews where and they reacted with horror. "How am I supposed to build a profile when I'm so busy with school, interning on the side and studying for interviews!?"
Software used to be dominated by passionate hackers, and now it's one increasingly of skilled professionals. The best work people just as hard but in a very different way.
Like it or not, software is not like it was a decade a go, and if you still want to be seen as a top tier engineer you're going to have to do it by the standard of today.
I started in software over 10 years ago. At that time all of the exciting jobs where for small startups and the best way to get hired was to have a great github profile or some cool projects to show off.
But small startups need a hand full of really talented devs who can solve a variety of problems, and quickly get up to speed on new domains and tech stacks. A few good developers could make a company. So hiring focused on individuals who stood out and had something unique they could bring to the team.
But FAANG companies want to hire engineers that they can treat as replaceable parts. The "rockstar" talent that was required a decade ago is a liability. This may sound like a critique but it makes perfect sense from the business standpoint, and while you can protest this all you want it won't change a landscape dominated by large software giants to one fill with disrupting startups.
It's just a different world and if you want to show that your "experienced" and not just "old" you need to show that you can adapt just as well as a decade ago. I had a moment of enlightenment when waxing nostalgic about github profiles to a really talented new engineer doing prestigious work in deep learning. I told them how much better profiles based interviews where and they reacted with horror. "How am I supposed to build a profile when I'm so busy with school, interning on the side and studying for interviews!?"
Software used to be dominated by passionate hackers, and now it's one increasingly of skilled professionals. The best work people just as hard but in a very different way.
Like it or not, software is not like it was a decade a go, and if you still want to be seen as a top tier engineer you're going to have to do it by the standard of today.
When I was involved in hiring at a company, we found some amazing candidates through code screens whom we never even would have interviewed otherwise. They were terrible at resume writing, didn’t present themselves well, but could code well and were very engaging once they got past initial discomfort.
I get the frustration of senior devs at going through this stuff, but the alternative is a weird form of credentialism based on seniority.
I get the frustration of senior devs at going through this stuff, but the alternative is a weird form of credentialism based on seniority.
I wrote up a similar experience a little less than a year ago: https://medium.com/@suzzer99/how-not-to-do-a-job-search-1e99...
I was rusty from traveling from 6 months and definitely wasn't prepared. But I finally landed a job at a place that was a little more old-school in their hiring process, and as soon as they could they converted me from contractor to full time. So I guess it's working out for them (and me).
I was rusty from traveling from 6 months and definitely wasn't prepared. But I finally landed a job at a place that was a little more old-school in their hiring process, and as soon as they could they converted me from contractor to full time. So I guess it's working out for them (and me).
Timed programming puzzles are silly and self-defeating, for the simple reason that writing software is a creative process, not a production process. It's the same reason why kloc metrics were dumb and have been mostly and justly relegated to history's dustbin. These things are dreamed up by hiring managers to cut their workload, and for the non-technical ones it gives them some simple thing they can comprehend and make a decision on.
I understand the attraction of simple decision metrics, more so if you're in the unfortunate position of having to make a technical hire with no experience of your own to guide you. But consider the referenced tweet that implied 250 resumes were too many to read. You're going to hire someone to do a highly complex job, spend months getting them up to speed, probably work with that person for at least a few years, and you can't come up with a way for your company to at least scan 250 resumes? I mean it's like pretty close to the one main thing you're there to do: find and hire the right people.
I understand the attraction of simple decision metrics, more so if you're in the unfortunate position of having to make a technical hire with no experience of your own to guide you. But consider the referenced tweet that implied 250 resumes were too many to read. You're going to hire someone to do a highly complex job, spend months getting them up to speed, probably work with that person for at least a few years, and you can't come up with a way for your company to at least scan 250 resumes? I mean it's like pretty close to the one main thing you're there to do: find and hire the right people.
In a little over a month, I'll be turning 46. I've been doing software development professionally since I was 18. I have no formal education in it, except for a couple classes taken at a CC for C++.
Between hearing things like this, the way the internet is going, the way cell phones are becoming more closed up and walled in...just everything about the way the world is going...
...I honestly am beginning to think my best course of action would be to (somehow) change jobs entirely, move out to the middle of nowhere on 40 acres, drop off the internet, build my own cellphone (which I've mentioned), and just go back to hacking on my TRS-80 Color Computer. If I ever accessed the internet again, it would only be for email and maybe the occasional "telnet BBS" - and that would only be after a 50 mile drive into "town".
While I know and understand that despite 25+ years of experience I may not be at the same level as others with fewer years, that time should count for something. In my case, what I lack mostly has been any sort of opportunity for a "management" role; I have never been a team lead, for instance. It pains me. It does nothing for my self-esteem as a software engineer.
But that shouldn't count against me. Nor should being able to solve some rando problem concocted as a gatekeeper. I've worked at places for short periods, and I've stuck around at places far longer than I should have. But lately things have been hovering around jumping at 3 years, and that time seems to be coming up for me at my current place of employment.
The thing is - I don't want to leave. I like it where I'm at. I enjoy the problems. I enjoy my coworkers. I enjoy the development environment. But more often than not, it seems, outside forces seem to conspire to kick me out whether I want to go or not.
Maybe I'll get lucky once more and land a new position. Maybe I can use the fledgling skills I have in ML in some manner. Or I might have to drop my salary requirements down and take something lesser, just to stay employed?
But at some point in the future - the near future - it feels like it won't matter what I do or don't do, I won't be allowed to "make the cut" any longer.
Thank $DEITY I have no debt other than my mortgage...
Between hearing things like this, the way the internet is going, the way cell phones are becoming more closed up and walled in...just everything about the way the world is going...
...I honestly am beginning to think my best course of action would be to (somehow) change jobs entirely, move out to the middle of nowhere on 40 acres, drop off the internet, build my own cellphone (which I've mentioned), and just go back to hacking on my TRS-80 Color Computer. If I ever accessed the internet again, it would only be for email and maybe the occasional "telnet BBS" - and that would only be after a 50 mile drive into "town".
While I know and understand that despite 25+ years of experience I may not be at the same level as others with fewer years, that time should count for something. In my case, what I lack mostly has been any sort of opportunity for a "management" role; I have never been a team lead, for instance. It pains me. It does nothing for my self-esteem as a software engineer.
But that shouldn't count against me. Nor should being able to solve some rando problem concocted as a gatekeeper. I've worked at places for short periods, and I've stuck around at places far longer than I should have. But lately things have been hovering around jumping at 3 years, and that time seems to be coming up for me at my current place of employment.
The thing is - I don't want to leave. I like it where I'm at. I enjoy the problems. I enjoy my coworkers. I enjoy the development environment. But more often than not, it seems, outside forces seem to conspire to kick me out whether I want to go or not.
Maybe I'll get lucky once more and land a new position. Maybe I can use the fledgling skills I have in ML in some manner. Or I might have to drop my salary requirements down and take something lesser, just to stay employed?
But at some point in the future - the near future - it feels like it won't matter what I do or don't do, I won't be allowed to "make the cut" any longer.
Thank $DEITY I have no debt other than my mortgage...
> I honestly am beginning to think my best course of action would be to (somehow) change jobs entirely, move out to the middle of nowhere on 40 acres, drop off the internet
In my mid-30s and this feeling is only growing stronger. I don't even have a demanding job, I never work more than 40 hours and I get to implement the latest and greatest (.NET Core, Vue).
In the last 6 months I've applied to several remote jobs. I always do well on the sample projects they give me and I have a good personality during the interviews... cracking a few jokes to lighten things up a bit. However because remote jobs are so damn competitive they always focus on one stupid question I didn't answer exactly the way they expected or something I slightly missed and I end up getting rejected. "We're looking for someone with more experience" - I have over a decade of experience, I've demonstrated as much and I can solve pretty much any business problem.
All of it just makes me feel defeated despite the massive progress I've made in my career, all the awards, back to back promotions... all feels meaningless anymore.
In my mid-30s and this feeling is only growing stronger. I don't even have a demanding job, I never work more than 40 hours and I get to implement the latest and greatest (.NET Core, Vue).
In the last 6 months I've applied to several remote jobs. I always do well on the sample projects they give me and I have a good personality during the interviews... cracking a few jokes to lighten things up a bit. However because remote jobs are so damn competitive they always focus on one stupid question I didn't answer exactly the way they expected or something I slightly missed and I end up getting rejected. "We're looking for someone with more experience" - I have over a decade of experience, I've demonstrated as much and I can solve pretty much any business problem.
All of it just makes me feel defeated despite the massive progress I've made in my career, all the awards, back to back promotions... all feels meaningless anymore.
My first thought upon reading this was: "If you don't want to quit your job, then just stay."
So, is it you are working on a project, and when the project is finnished there is no work left, or do you think thay you will get fired, or what am I missing here?
So, is it you are working on a project, and when the project is finnished there is no work left, or do you think thay you will get fired, or what am I missing here?
> My first thought upon reading this was: "If you don't want to quit your job, then just stay."
Well - that's always what I try to do, but the last several places I've worked, the decision was effectively made for me, either due to a layoff, or because the company closed down, or because it was bought out (and I was given a real stupid offer to stay), etc.
> So, is it you are working on a project, and when the project is finnished there is no work left, or do you think thay you will get fired, or what am I missing here?
> My first thought upon reading this was: "If you don't want to quit your job, then just stay."
Well - that's always what I try to do, but the last several places I've worked, the decision was effectively made for me, either due to a layoff, or because the company closed down, or because it was bought out (and I was given a real stupid offer to stay), etc.
Currently, it's because the client I work for, on behalf of my company (I'm part of a small team here, but the client is international, and the larger dev team they have in place is the same), has made a decision to outsource the work we do here in the USA for a different international team (who likely is cheaper). We will be training our replacements on how the system is designed/working. Once they are "up to speed" (we imagine), our team will be cut loose.
Our boss (owner of the company - it's a small boutique web application business) has assured us that we have an internal project waiting for us, which we've been told about and have discussed, for us to continue on with. It is supposedly fully funded, which I don't have any reason to doubt. The owner is a great guy, and has been up-front about everything going on, and I trust that this will work out. I've told him that so long as the paychecks don't bounce and I still have health coverage, I'll stick around. I really do like our team and environment. I also like the idea and concept of this new internal project.
But I've been doing this long enough that even that may not be enough. Things have a way of turning in business where at one point, things might seem ok, but then overnight a painful adjustment has to be made and you find yourself without a job. I've also told my boss as much, not to sacrifice his business on account of trying to keep us all employed, because I've seen in the past employers with similar small companies I've worked for completely implode because they kept trying to make things work and keep their people employed, when scaling back would have been the better option. It's noble and nice to know when an employer acts that way, but from a business perspective it really is the wrong decision at times. So I've let my boss know that I understand this, because he's that kind of guy - he doesn't want to lose us, we're a good team (talent-wise and such), but I don't want to see him lose the business either.
I'd rather he would stay in business, and maybe I could return in a few years or something when things are looking better.
But so far - there's nothing to indicate that anything like that is going to happen. We're all still employed by this client. The company I work for, itself, has other clients (I am part of a small team tasked to work with this singular client; there are other devs who work with other clients on other web application projects), and this new internal application could turn out to be something wonderful for the company, if we play our cards right.
But I worry because our team lead left for a new position, because he has a family and needed more stability. I worry that the remainder of the team may take that same option, due to similar reasons. I don't have to worry about such issues; I don't have kids - but I do need to be paid to pay my bills, and I need health coverage (more a necessity as I get older).
But there's the possibility - if the rest of my team leaves for "greener pastures" - that the internal project may be shelved, or that I can't work alone on bringing another foreign team up to speed on our current project, or whatever, and at that point, it may be more beneficial for my employer to let me go than to keep me (and, after all, I've told him that he should do as much, right?).
I wouldn't begrudge my employer making that decision, but it doesn't mean I don't worry about it, either. The one thing that keeps me from worrying too much, at least in the short term, is knowing that I am "debt free" (except a mortgage), I have plenty of savings (enough to cover 2-3 years of salary if needed), and that I don't have to provide for a family other than my wife and dogs. In short, I can make things work for a while, until I can find something else or do something else. But it doesn't mean I don't worry about the whole situation...
Well - that's always what I try to do, but the last several places I've worked, the decision was effectively made for me, either due to a layoff, or because the company closed down, or because it was bought out (and I was given a real stupid offer to stay), etc.
> So, is it you are working on a project, and when the project is finnished there is no work left, or do you think thay you will get fired, or what am I missing here?
> My first thought upon reading this was: "If you don't want to quit your job, then just stay."
Well - that's always what I try to do, but the last several places I've worked, the decision was effectively made for me, either due to a layoff, or because the company closed down, or because it was bought out (and I was given a real stupid offer to stay), etc.
Currently, it's because the client I work for, on behalf of my company (I'm part of a small team here, but the client is international, and the larger dev team they have in place is the same), has made a decision to outsource the work we do here in the USA for a different international team (who likely is cheaper). We will be training our replacements on how the system is designed/working. Once they are "up to speed" (we imagine), our team will be cut loose.
Our boss (owner of the company - it's a small boutique web application business) has assured us that we have an internal project waiting for us, which we've been told about and have discussed, for us to continue on with. It is supposedly fully funded, which I don't have any reason to doubt. The owner is a great guy, and has been up-front about everything going on, and I trust that this will work out. I've told him that so long as the paychecks don't bounce and I still have health coverage, I'll stick around. I really do like our team and environment. I also like the idea and concept of this new internal project.
But I've been doing this long enough that even that may not be enough. Things have a way of turning in business where at one point, things might seem ok, but then overnight a painful adjustment has to be made and you find yourself without a job. I've also told my boss as much, not to sacrifice his business on account of trying to keep us all employed, because I've seen in the past employers with similar small companies I've worked for completely implode because they kept trying to make things work and keep their people employed, when scaling back would have been the better option. It's noble and nice to know when an employer acts that way, but from a business perspective it really is the wrong decision at times. So I've let my boss know that I understand this, because he's that kind of guy - he doesn't want to lose us, we're a good team (talent-wise and such), but I don't want to see him lose the business either.
I'd rather he would stay in business, and maybe I could return in a few years or something when things are looking better.
But so far - there's nothing to indicate that anything like that is going to happen. We're all still employed by this client. The company I work for, itself, has other clients (I am part of a small team tasked to work with this singular client; there are other devs who work with other clients on other web application projects), and this new internal application could turn out to be something wonderful for the company, if we play our cards right.
But I worry because our team lead left for a new position, because he has a family and needed more stability. I worry that the remainder of the team may take that same option, due to similar reasons. I don't have to worry about such issues; I don't have kids - but I do need to be paid to pay my bills, and I need health coverage (more a necessity as I get older).
But there's the possibility - if the rest of my team leaves for "greener pastures" - that the internal project may be shelved, or that I can't work alone on bringing another foreign team up to speed on our current project, or whatever, and at that point, it may be more beneficial for my employer to let me go than to keep me (and, after all, I've told him that he should do as much, right?).
I wouldn't begrudge my employer making that decision, but it doesn't mean I don't worry about it, either. The one thing that keeps me from worrying too much, at least in the short term, is knowing that I am "debt free" (except a mortgage), I have plenty of savings (enough to cover 2-3 years of salary if needed), and that I don't have to provide for a family other than my wife and dogs. In short, I can make things work for a while, until I can find something else or do something else. But it doesn't mean I don't worry about the whole situation...
I'm in a similar boat -- my educational background is hardware engineering, but, I've been a Linux nerd/SRE for the last 20 years. Ask me to test an 3x10 LED array? Can do it in my sleep, without even looking things up. Ask me to do a B-Tree? I'm pulling up documentation. Ask me to do a deployment in AWS, GCE, or Azure, and I've got the code to make the API calls without the help of boto...but ask me to do the same in VMWare, and I'm a fish out of water.
I've got a technical interview on Thursday, and they use Hackerrank for their coding platform. I'm seriously hoping that they have something that's specific to SRE tasks, because, if they ask me an algorithm question, I'm almost 100% certain I'm going to fail -- these weren't things that I studied in my EE degree, but, I've learned how to implement things from my positions over the last ten years.
I know what I'm doing, and I feel comfortable thinking and looking for solutions that aren't "inside the box" -- delivering an OS and DB upgrade to 8000+ stores via a USB Stick -- complete with a dashboard that I wrote, microservices soup to nuts (meaning: I worked with the developers to make better containers, and then wrote the ansible playbooks to deploy OpenShift in EC2) for a major hotel company, web governance/best practices for a top 5 Quick-Serve Restaurant chain. Asking me the difference between a Markov Chain and a B-Tree isn't something that I've ever needed to do...
On the other hand, when I was hiring in the Washington DC area, the number of Senior developers that I'd get from government contractors who couldn't count to 1000 by 5's in a language of their choosing really hurt my soul.
I've got a technical interview on Thursday, and they use Hackerrank for their coding platform. I'm seriously hoping that they have something that's specific to SRE tasks, because, if they ask me an algorithm question, I'm almost 100% certain I'm going to fail -- these weren't things that I studied in my EE degree, but, I've learned how to implement things from my positions over the last ten years.
I know what I'm doing, and I feel comfortable thinking and looking for solutions that aren't "inside the box" -- delivering an OS and DB upgrade to 8000+ stores via a USB Stick -- complete with a dashboard that I wrote, microservices soup to nuts (meaning: I worked with the developers to make better containers, and then wrote the ansible playbooks to deploy OpenShift in EC2) for a major hotel company, web governance/best practices for a top 5 Quick-Serve Restaurant chain. Asking me the difference between a Markov Chain and a B-Tree isn't something that I've ever needed to do...
On the other hand, when I was hiring in the Washington DC area, the number of Senior developers that I'd get from government contractors who couldn't count to 1000 by 5's in a language of their choosing really hurt my soul.
>> I've got a technical interview on Thursday, and they use Hackerrank for their coding platform. I'm seriously hoping that they have something that's specific to SRE tasks...
If you want to do well on the interview, you should brush up on recursion, binary trees and hashtables. If they are using HackerRank, it is almost guaranteed that the questions will be algorithmic rather than SRE based.
If you want to do well on the interview, you should brush up on recursion, binary trees and hashtables. If they are using HackerRank, it is almost guaranteed that the questions will be algorithmic rather than SRE based.
I'm a senior developer myself.
I have seen too many very senior engineers in the company that is more of a testing engineer nowadays, they do well in analyzing the issue at certain level, document them etc, but they're unable to fix anything that is deep and really complicated in a new code base that is huge(e.g. linux kernel, android framework), each meeting I kept hearing "I know exactly where the problem is..." but after many weeks there is still no fix, or the fix broke more things that it fixed.
A few weeks later a junior guy(not fresh-out though) came in and dove in and dug in then fixed it in a few days.
Senior developer means a lot only if you keep learning, keep coding, resharpen all your skill daily, and stay current. Otherwise, the title is a big negative to many companies, as the performance to price ration is totally unjustified.
I have seen too many very senior engineers in the company that is more of a testing engineer nowadays, they do well in analyzing the issue at certain level, document them etc, but they're unable to fix anything that is deep and really complicated in a new code base that is huge(e.g. linux kernel, android framework), each meeting I kept hearing "I know exactly where the problem is..." but after many weeks there is still no fix, or the fix broke more things that it fixed.
A few weeks later a junior guy(not fresh-out though) came in and dove in and dug in then fixed it in a few days.
Senior developer means a lot only if you keep learning, keep coding, resharpen all your skill daily, and stay current. Otherwise, the title is a big negative to many companies, as the performance to price ration is totally unjustified.
An open question. I'm currently writing a book on TDD for a publisher with a good reputation. Out of curiosity, should I expect to still be run through the interview ringer, or does that hold enough clout to demonstrate competency and possibly the ability to be successful at my job. I'm curious to hear peoples opinions on this.
Expect to be run through the ringer.
I've been rejected by companies who were using open source code I wrote.
I've been rejected by companies who were using open source code I wrote.
whiteboard interviewers like to ask dynamic programming, I really don't understand it. I have asked around and have never seen a single programmer used dynamic programming at work once.
Other skills, such as multi-thread programming, debugging skills, get less coverage. Many whiteboard coders who know how to solve dynamic programming on a whiteboard, don't know how to use mutex and semaphore.
I think the whiteboard interview process is broken.
Other skills, such as multi-thread programming, debugging skills, get less coverage. Many whiteboard coders who know how to solve dynamic programming on a whiteboard, don't know how to use mutex and semaphore.
I think the whiteboard interview process is broken.
People do use dynamic programming. But, yeah debugging skills should be given more coverage. A lot of people I've seen programming struggle or don't know how to debug code.
sure, I know fast Fourier transform and reinforcement learning use dynamic programming. but those don't represent most people's daily work. checking http://oj.leetcode.com/problems/ , you will see that the problem selection is very biased and academic focused.
it's like recruiting warriors based on gymnastics skills. I think it makes more sense to look for street fighters.
it's like recruiting warriors based on gymnastics skills. I think it makes more sense to look for street fighters.
must be nice getting so much traffic that it brings your server down. Geez.
I think this is an important essay. The advice at the end is good: these tests are inevitable, and if you want to stay in the biz by applying for dev jobs at companies, you must accept that you will retake you college CS exams over and over for the rest of your life.
Alternatively you could look for a different path in life. Best to get out of the coding jobs early in your career. Don’t look back.
That said, there are some good reasons to do the coding path. At the high end, they pay very very well, and there's no bar organization forcing you to get a $200K 3 year degree. Salaries start higher, and working your way up in other job ladders can be a grind and take quite a while to get up to SWE salaries.
I’ll leave the paradox of industry claims of a shortage as an exercise for the reader.
Alternatively you could look for a different path in life. Best to get out of the coding jobs early in your career. Don’t look back.
That said, there are some good reasons to do the coding path. At the high end, they pay very very well, and there's no bar organization forcing you to get a $200K 3 year degree. Salaries start higher, and working your way up in other job ladders can be a grind and take quite a while to get up to SWE salaries.
I’ll leave the paradox of industry claims of a shortage as an exercise for the reader.
Recently went through a process that had 5 hours of interviews, then a take-home (said 8 hours, took 16), then a full day on-site, then a reference check. Then not advanced with one sentence from a stranger ("We've decided not to move forward...") Asked for feedback nicely twice, no response, ghosted.
--
Been my experience with multiple SV startups now. In some cases went through back-channels to find out what happened (In one case - whole team loved you, CTO had your offer, CEO overrode at least minute and wanted a non-US contractor to avoid benefits pay)
--
Utterly absurd amounts of time and you still can't be sure!
--
My proposals -
#1) Companies that want take-home work or multiple day interview processes after initial screening /pay/ for them. You are already paying for your engineers to be inteviewing/etc. Pay the applicants. Keeps incentives aligned (you only advance ppl you really want to see how they work, you don't expect 40 hours + of work from me because I should feel blessed to get the opportunity to work for you...)
#2) More conversation. You can get way more ideas about someone's technical acumen by asking them how they know when to refactor, what they think about tradeoffs around technical debt, how they would think about data modelling something, etc than writing code. A brand new programmer maybe do some pairing, a person that has been writing production code for 3,5,10 years? Ask them the interesting questions and just talk!
#3) Hire quicker/Fire quicker - I think Riot for example will pay you money if you decide it isn't a good fit and you leave. Everyone is already employed at-will. I'd rather have a 3 month probationary period than try to find time for 40 hours of interviews while working my day job.
--
Been my experience with multiple SV startups now. In some cases went through back-channels to find out what happened (In one case - whole team loved you, CTO had your offer, CEO overrode at least minute and wanted a non-US contractor to avoid benefits pay)
--
Utterly absurd amounts of time and you still can't be sure!
--
My proposals -
#1) Companies that want take-home work or multiple day interview processes after initial screening /pay/ for them. You are already paying for your engineers to be inteviewing/etc. Pay the applicants. Keeps incentives aligned (you only advance ppl you really want to see how they work, you don't expect 40 hours + of work from me because I should feel blessed to get the opportunity to work for you...)
#2) More conversation. You can get way more ideas about someone's technical acumen by asking them how they know when to refactor, what they think about tradeoffs around technical debt, how they would think about data modelling something, etc than writing code. A brand new programmer maybe do some pairing, a person that has been writing production code for 3,5,10 years? Ask them the interesting questions and just talk!
#3) Hire quicker/Fire quicker - I think Riot for example will pay you money if you decide it isn't a good fit and you leave. Everyone is already employed at-will. I'd rather have a 3 month probationary period than try to find time for 40 hours of interviews while working my day job.
It's quickly become common for a company to assign a homework assignment that will take "2 hours". However the nature of development is often a process of debugging (even if the end fix is stupidly simple, just difficult to nail down).
This is a cancer because many hiring managers will assign out these homework assignments to all the applicants, before doing almost any due diligence or getting to know an applicant.
If you want someone to jump through 8 hours of interviews and calls, then 8 hours of coding, you should be paying them at least for the coding.
This is a cancer because many hiring managers will assign out these homework assignments to all the applicants, before doing almost any due diligence or getting to know an applicant.
If you want someone to jump through 8 hours of interviews and calls, then 8 hours of coding, you should be paying them at least for the coding.
[deleted]
We regularly hear reports like this, that interviews are getting randomly harder every year. It just goes to show that there is in fact no shortage of senior developers... rather a glut, in fact.
I am not a Senior. Not junior, not senior. I have been interviewing lately after my company staffed me as the only remote member of a team based in Argentina. (Live in the midwest USA, don't speak a lick of spanish).
I typically won't do programming challenges. I don't believe it's fair for the applicant, because if it becomes the industry norm then applying for 10 jobs means 10 separate programming challenges just for the opportunity to get an onsite. But, recently, during a phone interview with a shipping logistics company with a common first name in their name, I vibed with the lead I spoke to and decided I would give their hackerrank a go.
There was an interpolate json feed into an object question. There was a semi-complex array sorting / manipulation question. There was a javascript quirks question. There was a sql question that I probably would have solved using both code and sql rather than just sql. The solution I came up with was using a temp table, that hackerrank permissions did not allow. The array question, my (working) solution timed out because one of the tests used an array with several million units in it. There was no indication of a certain time this should run under. It took about five minutes after submitting to realize a way that probably wouldn't have timed out, but at the time I was happy with my solution given the whole test was timed and I had written six lines of code to solve this problem.
The final question of the test, after all of these and a few I won't go into, was to write an html form field that updated a list via javascript and had alternating CSS colors. I was so frustrated that they would throw in something so very menial and time consuming after the rest of the (timed!) test that I didn't even attempt it. (to be clear, basic javascript knowledge had already been demonstrated on the prior fizzbuzz).
I had really thought my answers would grant me an onsite, but it didn't. So yeah, back to not doing stupid timed tests.
This was a month ago. The position is still open and I expect it to be for the near future.
If anyone read this far, I have given some thought about my various interviews after some interesting ones recently (another recent time at a .net shop I was asked to demonstrate sorting a list so i did a toarray() then sort and they were like no, do it manually).
I'm probably going to put together a blog about my interviews over the years since I've had all sorts. I feel like as deep as retrospective as I can remember over my decade of interviewing might give me some insight as how I should be better.
I typically won't do programming challenges. I don't believe it's fair for the applicant, because if it becomes the industry norm then applying for 10 jobs means 10 separate programming challenges just for the opportunity to get an onsite. But, recently, during a phone interview with a shipping logistics company with a common first name in their name, I vibed with the lead I spoke to and decided I would give their hackerrank a go.
There was an interpolate json feed into an object question. There was a semi-complex array sorting / manipulation question. There was a javascript quirks question. There was a sql question that I probably would have solved using both code and sql rather than just sql. The solution I came up with was using a temp table, that hackerrank permissions did not allow. The array question, my (working) solution timed out because one of the tests used an array with several million units in it. There was no indication of a certain time this should run under. It took about five minutes after submitting to realize a way that probably wouldn't have timed out, but at the time I was happy with my solution given the whole test was timed and I had written six lines of code to solve this problem.
The final question of the test, after all of these and a few I won't go into, was to write an html form field that updated a list via javascript and had alternating CSS colors. I was so frustrated that they would throw in something so very menial and time consuming after the rest of the (timed!) test that I didn't even attempt it. (to be clear, basic javascript knowledge had already been demonstrated on the prior fizzbuzz).
I had really thought my answers would grant me an onsite, but it didn't. So yeah, back to not doing stupid timed tests.
This was a month ago. The position is still open and I expect it to be for the near future.
If anyone read this far, I have given some thought about my various interviews after some interesting ones recently (another recent time at a .net shop I was asked to demonstrate sorting a list so i did a toarray() then sort and they were like no, do it manually).
I'm probably going to put together a blog about my interviews over the years since I've had all sorts. I feel like as deep as retrospective as I can remember over my decade of interviewing might give me some insight as how I should be better.
I think a big part of the discussion that's being missed here is that a lot of senior-level engineering jobs aren't about coding. They work at higher levels, and are often communication-intensive.
I work in DevOps. If I'm interviewing someone, I'm going to ask "Explain the difference between continuous integration, continuous delivery, and continuous deployment". A junior person who can answer that well gets a big thumbs-up from me. A senior who can't answer it will probably be rejected out of hand.
In neither case is implementing Towers of Hanoi on a whiteboard useful for the job.
I work in DevOps. If I'm interviewing someone, I'm going to ask "Explain the difference between continuous integration, continuous delivery, and continuous deployment". A junior person who can answer that well gets a big thumbs-up from me. A senior who can't answer it will probably be rejected out of hand.
In neither case is implementing Towers of Hanoi on a whiteboard useful for the job.
We do live coding exercises as part of our hiring process, but we generally shy away from Algorithm problems and instead ask them to solve problems like:
* Count the number of vowels in a string
* Transform a dictionary that's key'd on file name, with the value as the file owner into a new dictionary with owners as the keys and their value as a list of files.
* Deduplicate an array while preserving order in linear O(N) time
* Solve a simple problem using a closure (You can even google what a closure is)
We go out of our way to make sure the interview is conversational; we talk to candidates like they're our colleagues. Too often, technical interviews seem like interrogations and I absolutely hate that.
Candidates can code on their own laptops, ask us questions, and even google stuff. The only rule is no googling for the problem directly, but if you need to look up if some datatype has method X or forgot its signature it's not counted against you.
The point of this is to just to do a basic smoke-test of the candidates programming skills. They don't need to get them all correct, but they should be able to solve at least 1 or 2. If they can't, then we politely end the interview.
The rest of the interview is talking about coding, projects they've worked on, challenging and interesting problems, wish lists, and for more senior people architecture/planning, and a mock code review: we give them some bad code and ask them to give feedback. The entire process takes about 3 hours.
* Count the number of vowels in a string
* Transform a dictionary that's key'd on file name, with the value as the file owner into a new dictionary with owners as the keys and their value as a list of files.
* Deduplicate an array while preserving order in linear O(N) time
* Solve a simple problem using a closure (You can even google what a closure is)
We go out of our way to make sure the interview is conversational; we talk to candidates like they're our colleagues. Too often, technical interviews seem like interrogations and I absolutely hate that.
Candidates can code on their own laptops, ask us questions, and even google stuff. The only rule is no googling for the problem directly, but if you need to look up if some datatype has method X or forgot its signature it's not counted against you.
The point of this is to just to do a basic smoke-test of the candidates programming skills. They don't need to get them all correct, but they should be able to solve at least 1 or 2. If they can't, then we politely end the interview.
The rest of the interview is talking about coding, projects they've worked on, challenging and interesting problems, wish lists, and for more senior people architecture/planning, and a mock code review: we give them some bad code and ask them to give feedback. The entire process takes about 3 hours.
This is one of the better articles I have read on the subject of hiring technical talent with approaches to some of the inherent challenges.
https://firstround.com/review/my-lessons-from-interviewing-4...
https://firstround.com/review/my-lessons-from-interviewing-4...
Hey, looks like some kind person thought to archive this a day ago: http://archive.is/5gJqc
Now I actually get to read it :)
Now I actually get to read it :)
On one hand you have companies bleating about how they can't find enough developers, while pushing for more foreign work visas etc. in all of the developed countries. On the other hand you have talented engineers being turned down. I would argue that if there is indeed a shortage, you would not being seeing this volume of talented engineers being turned down and they would be in the drivers seat in the process.
The fact is that business is trying to turn us into commodities and it sounds like right now they are winning...all that we can do it either adapt or change careers sadly.
The fact is that business is trying to turn us into commodities and it sounds like right now they are winning...all that we can do it either adapt or change careers sadly.
Another day, another "coding interviews are broken" post on HN, the same old replies. So here's mine.
- A vast number of people masquerade as "programmers", "engineers" or "developers" who couldn't code their way out of a paper bag. If you don't believe me, you haven't conducted interviews.
- This was the key motivation behind FizzBuzz. Passing it doesn't mean you're a great programmer. Failing it means you're almost certainly not. So the ability to turn a super simple "algorithm" into code in [language of your choice] is an incredibly useful negative filter.
- Interviewers and companies fall into the trap of thinking "this problem is too simple; let's make it harder". In doing so you devalue the negative filter and gain NOTHING as a positive filter. Worse it can turn into a gamble as to whether you happen to know the particular trick for that problem. Tortoise and hare or O(log n) bit reversing fall into this category;
- Taking a problem and being able to reframe it in terms of standard data structures and algorithms like recognizing it's a particular graph problem is an incredibly useful skill. These don't always need to be turned into code.
I'll say it again: the biggest problem is people try to make whiteboard problems "hard" making them a useless signal.
I'll add:
- I'm dead against "take home" tests. I don't have time for that. This seems like a great way of getting mediocre candidates. Like, what makes you think if someone can't do it they won't "cheat"?
- Talking about robust systems design isn't done often enough;
Here's another thing I've pondered: how much of coding interviews and the notion of "cultural fit" is really thinly-veiled discrimination? I expect quite a lot and I expect this to blow up at some point.
- A vast number of people masquerade as "programmers", "engineers" or "developers" who couldn't code their way out of a paper bag. If you don't believe me, you haven't conducted interviews.
- This was the key motivation behind FizzBuzz. Passing it doesn't mean you're a great programmer. Failing it means you're almost certainly not. So the ability to turn a super simple "algorithm" into code in [language of your choice] is an incredibly useful negative filter.
- Interviewers and companies fall into the trap of thinking "this problem is too simple; let's make it harder". In doing so you devalue the negative filter and gain NOTHING as a positive filter. Worse it can turn into a gamble as to whether you happen to know the particular trick for that problem. Tortoise and hare or O(log n) bit reversing fall into this category;
- Taking a problem and being able to reframe it in terms of standard data structures and algorithms like recognizing it's a particular graph problem is an incredibly useful skill. These don't always need to be turned into code.
I'll say it again: the biggest problem is people try to make whiteboard problems "hard" making them a useless signal.
I'll add:
- I'm dead against "take home" tests. I don't have time for that. This seems like a great way of getting mediocre candidates. Like, what makes you think if someone can't do it they won't "cheat"?
- Talking about robust systems design isn't done often enough;
Here's another thing I've pondered: how much of coding interviews and the notion of "cultural fit" is really thinly-veiled discrimination? I expect quite a lot and I expect this to blow up at some point.
I accept the fact that there will be a coding gate with the interview process, but I dislike the lack of transparency regarding the process and grading criteria
[deleted]
has anyone else here gotten the situation where you get a couple of job offers, but get rejected by the company/position for whom you felt you were the best fit for?
one of the bad reasons for bad hiring practices I've seen is that hiring managers throw engineers into interviewing situations a bit too unprepared, often times with very little interview training/experience.
There needs to be a interview training/mentoring period where you have engineers sit in on interviews to learn how and what questions to ask but without actually having veto/accept power. this allows them to get experience without screwing up the whole interview process.
Most inexperience engineer interviewers think you get the best candidates by having the highest reject rate, and that's simply not true. Only interviewing experience and training can improve this.
There needs to be a interview training/mentoring period where you have engineers sit in on interviews to learn how and what questions to ask but without actually having veto/accept power. this allows them to get experience without screwing up the whole interview process.
Most inexperience engineer interviewers think you get the best candidates by having the highest reject rate, and that's simply not true. Only interviewing experience and training can improve this.
I find it ironic that the upper echelons of startups reject:
racism
sexism
any other discriminations
But something else was brought in to replace them all. And it's called culture-fitism and ageism.
But something else was brought in to replace them all. And it's called culture-fitism and ageism.
I finally have gotten the courage to leave interviews when they throw code test as me, end the call or just leave. Sometimes I believe that the person doing the interview (Senior Dev) just likes to quiz people on technical knowledge and then when the interviewee doesn't know, they like to tell them and explain it to them. I get the feeling at times it gives the interviewer an ego boost. I think I have been trained to explore every job opportunity, just like I have been trained to eat all the food on my plate.
Best example, I have ever had I was interviewing for job about 6 years ago with a start up. The guy that was interviewing me has a CS masters degree strong tech stack background, probably lacked personality. He asked me what polymorphous was and at the time I didn't know. I just told him that I didn't know. Then he went on to explain it to me. Which I really didn't care about learning about. It was clear I wasn't going to get the job and that was fine, it didn't hurt my feelings. However, I learned to code because I have a background in finance, stocks, and options, before I became a coder. I have built stock algorithms that are profitable, regardless if they don't use all the right classes or OOP. So when this gentleman told me that I wasn't good enough for the job, he followed up with, I really like what you are doing with stocks and your stock algorithm, maybe we could meet for coffee sometime and you could tell me how your algorithm works, etc.
So I'm not good enough for your job, but but you want to learn about my algorithm. (the company went out of business 1 year later.) Pound sand.
The problem that I face is I don't want to be a Senior Dev. I have enough side projects and work life balance that I'm not trying to hit the CTO career mark, unless maybe with a start up. Some one mentioned that that they where like a studio musician. They aren't going be the rock star, but they do well with the band, etc. That's probably me, I'm more interested in my side projects. But professional enough to work at a day job.
Whiteboards, interviews, take homes I'm not seeing this get much better anytime soon.
Best example, I have ever had I was interviewing for job about 6 years ago with a start up. The guy that was interviewing me has a CS masters degree strong tech stack background, probably lacked personality. He asked me what polymorphous was and at the time I didn't know. I just told him that I didn't know. Then he went on to explain it to me. Which I really didn't care about learning about. It was clear I wasn't going to get the job and that was fine, it didn't hurt my feelings. However, I learned to code because I have a background in finance, stocks, and options, before I became a coder. I have built stock algorithms that are profitable, regardless if they don't use all the right classes or OOP. So when this gentleman told me that I wasn't good enough for the job, he followed up with, I really like what you are doing with stocks and your stock algorithm, maybe we could meet for coffee sometime and you could tell me how your algorithm works, etc.
So I'm not good enough for your job, but but you want to learn about my algorithm. (the company went out of business 1 year later.) Pound sand.
The problem that I face is I don't want to be a Senior Dev. I have enough side projects and work life balance that I'm not trying to hit the CTO career mark, unless maybe with a start up. Some one mentioned that that they where like a studio musician. They aren't going be the rock star, but they do well with the band, etc. That's probably me, I'm more interested in my side projects. But professional enough to work at a day job.
Whiteboards, interviews, take homes I'm not seeing this get much better anytime soon.
Yesterday I got a rejection explicitly because I was "too senior"—for a senior position.
Guess I was too expensive, heh. The tone of the declination was actually super kind.
Guess I was too expensive, heh. The tone of the declination was actually super kind.
I've worked in different contexts at a lot of different jobs (full-time, contract, etc) over the past few years and my overall assessment is that whiteboard coding interviews do work. By "work" what I mean is that places that do screen this way have more productive developers on average than others.
My feeling now is that the fact that it is arbitrary and doesn't have that much to do with real-life work may be a feature. You can dissect job performance in a number of ways but I think most people would agree that these four factors are important: general cognitive ability, conscientiousness, domain knowledge and motivation. And of those, domain knowledge is already relatively easy to discern from the resume and otherwise easy to screen for and if your company is doing anything unique, not as important in the long run. Almost any process would do a sufficiently good enough job of taking into account relevant domain knowledge. Thus what makes one process better than others has more to do with extracting other signals.
Whiteboard coding interviews, by being timed, somewhat arbitrary, yet something that is widely practiced and easy to study for, implicitly selects for cognitive ability, motivation and conscientiousness. It's hard enough that you can't be dumb, it requires enough preparation that you have to be somewhat motivated. And the process of preparing for interviews is sufficiently repulsive and it's easy enough to fool yourself that you're prepared enough when you really aren't, that studying to the point where you're prepared is a test of conscientiousness. This creates a paradoxical situation where the test itself isn't necessarily that relevant for the job, yet those who get through the test are almost always very good.
In short, given that what you need to do to pass these interviews is fairly widely publicized, the ability and willingness to do what it takes to pass positively signal that you'd make a good employee. Even if you're great at software development, if you're neither sufficiently motivated nor conscientious enough to prepare yourself to pass these interviews, it's unclear to me why you'd also go out of your way to excel at any given job - every job requires you to do things you don't want to do, learn what you don't care to learn and deal with a variety of suboptimal situations constructively. So while I'm sympathetic to the point of view that this shouldn't be how things are done, I think the willingness to say, "you know, this is how things are, so let's deal with reality as it is instead of wishing it away and ignoring some of the best job opportunities because I don't want to study" is a positive characteristic. Every job has challenges like that - something that in an ideal world is kind of stupid, is not at all fun to do and takes a lot of effort, but doing it is strictly better than not doing it. You want to hire people who are willing to do these things, not just complain about how stupid it is.
My feeling now is that the fact that it is arbitrary and doesn't have that much to do with real-life work may be a feature. You can dissect job performance in a number of ways but I think most people would agree that these four factors are important: general cognitive ability, conscientiousness, domain knowledge and motivation. And of those, domain knowledge is already relatively easy to discern from the resume and otherwise easy to screen for and if your company is doing anything unique, not as important in the long run. Almost any process would do a sufficiently good enough job of taking into account relevant domain knowledge. Thus what makes one process better than others has more to do with extracting other signals.
Whiteboard coding interviews, by being timed, somewhat arbitrary, yet something that is widely practiced and easy to study for, implicitly selects for cognitive ability, motivation and conscientiousness. It's hard enough that you can't be dumb, it requires enough preparation that you have to be somewhat motivated. And the process of preparing for interviews is sufficiently repulsive and it's easy enough to fool yourself that you're prepared enough when you really aren't, that studying to the point where you're prepared is a test of conscientiousness. This creates a paradoxical situation where the test itself isn't necessarily that relevant for the job, yet those who get through the test are almost always very good.
In short, given that what you need to do to pass these interviews is fairly widely publicized, the ability and willingness to do what it takes to pass positively signal that you'd make a good employee. Even if you're great at software development, if you're neither sufficiently motivated nor conscientious enough to prepare yourself to pass these interviews, it's unclear to me why you'd also go out of your way to excel at any given job - every job requires you to do things you don't want to do, learn what you don't care to learn and deal with a variety of suboptimal situations constructively. So while I'm sympathetic to the point of view that this shouldn't be how things are done, I think the willingness to say, "you know, this is how things are, so let's deal with reality as it is instead of wishing it away and ignoring some of the best job opportunities because I don't want to study" is a positive characteristic. Every job has challenges like that - something that in an ideal world is kind of stupid, is not at all fun to do and takes a lot of effort, but doing it is strictly better than not doing it. You want to hire people who are willing to do these things, not just complain about how stupid it is.
I failed my amazon whiteboard interview, I couldn't write a flawless binary search and as a result the guy said my entire CV must be a lie. There was a bug in the code somewhere, couldn't figure it out without a compile and a debug run. I've been coding for 38 years and I've built a world class product but hey, whiteboards don't lie right? Personally I think it was the fact that I was dealing with a lot at the time, personal stuff, plus I was banging my head against the wall trying to figure out why my socket server wasn't scaling properly to serve a large network, and I was nervous as heck.
If you want a developer who can rattle of a computer science algorithm, then whiteboard interviews are the way to go. I would rather ask the developer how she would create a password authentication scheme, and in doing so potential avoid a data breach down the line when they fail to apply proper security principles. Or I would challenge them on how they normally approach a problem, so that I could see how teachable they are. People who are not teachable are bad for business. I would also ask them to share a technique with me to see how willing to share information they are because IT people who don't like to share information are equally bad for business.
Lastly 'culture fit' is about finding more drinking buddies, if that's what you're hiring manager is doing you should fire him asap.
If you want a developer who can rattle of a computer science algorithm, then whiteboard interviews are the way to go. I would rather ask the developer how she would create a password authentication scheme, and in doing so potential avoid a data breach down the line when they fail to apply proper security principles. Or I would challenge them on how they normally approach a problem, so that I could see how teachable they are. People who are not teachable are bad for business. I would also ask them to share a technique with me to see how willing to share information they are because IT people who don't like to share information are equally bad for business.
Lastly 'culture fit' is about finding more drinking buddies, if that's what you're hiring manager is doing you should fire him asap.
Then the other side is giving you a "small project" that takes the better part of a day to implement. I just pass on those as well, and i'll do the short challenges but I don't really take the company seriously after that.
I found the most effective is whiteboard sessions that actually somewhat resemble reality as if I was the Product Owner and/or Architect with a problem. Then go through the design process, what database system would you use, would it have a a web service or be microservices or whatever, dig into the database design etc. May ask more specific technical questions along the way that are relevant to the design.
but the main thing is there is almost no actual coding done in the interview process at all.
I found the most effective is whiteboard sessions that actually somewhat resemble reality as if I was the Product Owner and/or Architect with a problem. Then go through the design process, what database system would you use, would it have a a web service or be microservices or whatever, dig into the database design etc. May ask more specific technical questions along the way that are relevant to the design.
but the main thing is there is almost no actual coding done in the interview process at all.
My boss had a very simple test he does.
1) create a very small web API 2) CLI the frontend spa of your choice Just toy examples with some in memory data and filtering Time boxed to an hour.
No crazy puzzles. Just demonstrate you can do the basics. See how far you can get, discuss as you go...
High failure rate. Even when I'd basically prep the candidates in the phone screen.
I'd basically tell them what they had to do. Still didn't prepare.
I've been burned on the take home projects and super crazy timed algo puzzle tests with the terrible instructions. I try to take the stress out of it as much as I can.
1) create a very small web API 2) CLI the frontend spa of your choice Just toy examples with some in memory data and filtering Time boxed to an hour.
No crazy puzzles. Just demonstrate you can do the basics. See how far you can get, discuss as you go...
High failure rate. Even when I'd basically prep the candidates in the phone screen.
I'd basically tell them what they had to do. Still didn't prepare.
I've been burned on the take home projects and super crazy timed algo puzzle tests with the terrible instructions. I try to take the stress out of it as much as I can.
The reason why most coders (who came to an interview) cannot code is simple: a decent coder gets a job after a few tries. A pretender (in my experience, a degree from IITs or some other degree mills from the same part of the world strongly correlates with that) would go to hundreds of interviews only to be rejected util he hits an equally incompetent interviewers. The pretenders are way over-represented in the pool, and simple programming tasks do an admirable job of filtering them out without much loss of time.
It was inevitable, that eventually we would end up with an oversupply of Software engineers. I think we're now getting to that point. No one likes getting rejected, but, when you have too many applicants and not enough jobs, rejections are going to happen more frequently regardless of what interview process you use.
Try this experiment. When you get to ask questions in the interview, instead of being nice and asking tings like "what's your data science stack" or "how important is testing here" give them a whiteboard. Give your future boss a whiteboard. But do it only if you don't care about getting an offer.
The issue is that there are a lot of programmers who have a lot of years and who consider themselves senior who have very little programming ability. If you have been with a “senior” developer who had no idea how to program but was always telling other people what to do, because he was senior, you know the danger of hiring one of these.
The other thing about this is preparation. It is no secret how these companies are screening and interviewing. A truly senior developer who really wants the job, with a few weeks of practice for an hour every night can considerably improve their chances.