Things I Learned from a Job Hunt for a Senior Engineering Role
fuzzyblog.io
fuzzyblog.io
A valuable practice, which surprisingly few tech companies do, is to ask candidates about diverse and orthogonal problem domains, or alternatively, allow the candidate to pick from a diverse set of problem domains. In the former case, you often find that candidates have difficulty writing even simple solutions for some problems but on others they instantly and fluidly can code up a good solution. Because they've had to do it in recent memory and still have the "muscle memory" from doing it previously. You often see bipolar results across the problem set this way.
For senior engineers with deep domain expertise in an area, there is an additional trap in that they use more sophisticated and often very different algorithms in their day to day lives than are applicable to the toy problem domains. Graph algorithms are a good example of this, and they are popular in interviews. The representations most engineers know (e.g. adjacency list or matrix) don't scale but the extremely high scale algorithms operate on a different set of principles that aren't trivial to code and aren't relevant to non-parallel cases; coding up an adjacency list graph traversal algorithm is going to be very unnatural to a software engineer used to doing the same on trillions of edges in real-time. It would be crazy not to hire an engineer on this basis but I've seen it happen, ironically because their expertise caused them to show poorly on the coding exercise.
Interviewing for technical skills is intrinsically difficult but I think that as an industry we are much worse at it than we could be. For all the claims of companies that they only hire the "top 10%" or whatever of engineers, the interview process is often optimized to the benefit of the median engineer.
I was declined for a position at a trading shop for a C# backend role because I used linq to do something. I didn't have unlimited time for the tests, so I went with expedient over performant, for which they did not care. Fuck that, set clear expectations for interview "tests".
If your priorities aren't aligned with the environment you set up, you are the one that must say so. On a real world project that means once in a while I'll take a project back for small fixes, instead of wasting unending hours thinking about every possible problem up-front... if you expect something different, well, that's not optimal.
One company I interviewed with gave me a program that had to be written in Scala, with the full knowledge that I would have to learn Scala to do it. Please.
"The IT industry is committed to increasing the number of women engineers. But if they're too busy caring for their children to spend six hours doing our silly test, that's their fault for being women. We are forced to hire 20-something white males who have nothing better to do with their time."
For her at least, this worked out better for her. She does design, which is even more difficult to evaluate in 30 minute time slots.
Not that I’m arguing this is the way to go, I was just wondering if interviewers could give some hints on what they would cover I the interview, so we could prep like studying for a test.
I hope your not impugning the motives of those who issue take-home assignments. Existing practices for hiring are objectively bad at selecting qualified candidates, and most people are just trying to do better. There is some evidence that take-home assignments are an improvement above the norm.
Also, consider that such assignments can serve as a "blind-audition" and can help eliminate bias from the interviewing process. And there are lots of ways in which loading everything into the interview unfairly penalizes certain types of otherwise qualified candidates. What's left, referrals? That's definitely biased, even if it also tends to have a lower false positive rate.
An easy switch would be to convert take homes to onsite work. One of the more recent interviews I had consisted of putting me in a room with some data and a stub of code and asked me to fill in the stub over a few hours. Every so often, they’d come by and ask if there were any problems. (More frequently at first, and then later less frequently.)
It’s basically the same, but it’s timeboxed and well defined with enough back and forth, to not feel like they’re just throwing a problem over the wall to you.
They are relevant enough that the prior poster felt the need to smear them.
> if the effect is the same
The claimed effect is, at this point, purely hypothetical and indeed runs contrary to my experience.
> An easy switch would be to convert take homes to onsite work.
Generally speaking, an onsite task like you describe seems like a reasonable choice for a company to make. However, this strikes me as worse for the affected groups that reaperducer was concerned about:
- It requires scheduling an even larger fixed block of time outside one's normal job/life responsibilities. A take-home assignment at least allows for flexibility for when you work on it. It strikes me that time-poor candidates would appreciate the flexibility.
- It would no longer be a "blind audition". When I've reviewed take-home assignments, I don't know anything about the candidate except that the code. It strikes me as a good way to resist unconscious bias from seeping in.
The the on-site solution remains a blind audition if the people doing the evaluation are not the people administering the test. This is exactly the case for a take home assignment, only now it is timeboxed and with access relatively timely help if needed.
The purpose of the blind audition is not to hide the identity of person being interviewed, as much as it is to enforce an objective standard and remove bias. If the rubric is, “Accept all that got automatic evaluation score of at least X”, then that achieves a similar goal.
As far as time-poor people, never underestimate the desire of having a clearly defined block of time. Of course, onsite or not can always be optional as well.
Pointing out (potential) unintended consequences is fine, even welcome.
Putting sexist remarks in the mouths of others is a smear, even if it is done merely flippantly.
> While it is true that the effect is merely claimed, as I know of no relevant study, your anecdote equally meaningless.
Anecdote is more meaningful than mere speculation. Even without statistically valid data, examples that are contrary to our expectations can bring to light factors that we had not previously considered.
> The the on-site solution remains a blind audition if the people doing the evaluation are not the people administering the test...The purpose of the blind audition is not to hide the identity of person being interviewed, as much as it is to enforce an objective standard and remove bias. If the rubric is, “Accept all that got automatic evaluation score of at least X”, then that achieves a similar goal.
A fair point.
> This is exactly the case for a take home assignment, only now it is timeboxed and with access relatively timely help if needed.
The point about timely help is definitely a point in favor of on-site work tests. But working in a timebox can also be stressful. A take-home assignment without artificial deadlines (i.e. don't schedule any interviews until after the assignment was received and approved) can eliminate that stress.
> As far as time-poor people, never underestimate the desire of having a clearly defined block of time. Of course, onsite or not can always be optional as well.
I think this hits on an important point, and one that I think would benefit from research and expertise I don't have. I'd hazard a guess that it depends upon why one is time poor.
If the candidate is intelligent and capable, but somewhat disorderly, then they would probably benefit from a structured, on-site task.
If the candidate is more organized but simply has a difficult and rigid schedule (which is actually something I would expect true, for example, of a working mother) then a take-home assignment might be better.
I don't know that either one is superior in all cases. Honestly, I think the best option would be to give the candidate a choice.
You will never be unbiased in a hiring process, because the bar you set is not universal, and always be biased in some way. Being "as blind as possible" isn't the right metric, and we shouldn't hire based on it.
Yes, that's exactly what I'm doing.
After that he said "Okay, I know you know enough to handle the job, now I'm curious how much you really know. " (This is key, I feel. He specified I wasn't going to get dinged for not knowing the answers, so I didn't feel the pressure in the questions he asked afterwards, when I usually feel intense pressure, as I know I've been passed over for getting a single question wrong in multiple interviews in the past.) He then asked me some pretty deep questions about low level memory and other things, and if I said I didn't know he turned into teacher mode and taught me the concept.
I actually walked out of that interview having learned something new and useful. I then got to chat with the President very casually, and I received a job offer a few days later.
The interviewer new his stuff, too. He'd been programming arcade games in assembly for decades. His games have sold millions of dollars, and two of the series still get made today.
Ever since, I figured if a freaking legend could be satisfied after reviewing some code and a code sample, the crap I've had to endure everywhere else is completely and totally unnecessary, and it's just frustrated me to no end.
After several questions that he was sure I knew the regular stuffs and was qualified for the job, he said he was going to ask some really hard questions to see how much I really knew and what was my thought process. The questions had no simple answers. Each of them required knowledge and experiences from a few technical fields. I didn't know much then. He guided me how to solve the problems, discussed the pros and cons of each approach. Then he told me how they did it, how other products in the same category did it, etc.
The half-hour interview was prolonged to one and a half. At the end, he said, "You have a very intuition on what are the right directions to go when facing unknown complex issues", and gave me an offer. It is my best interview experience. (I didn't join the start-up due to other reasons.)
The technologies have been advanced in a blazing fast speed i the last 10 plus years. Technical interviews, on the contrary, regress in a similar speed.
I actually really like homework assignment approach when done correctly, both as an interviewer and as an interviewee (though seanmcdirmid's suggestion of prep material, rather than a homework assignment, is quite sound), but this is a separate issue, independent of how skills are assessed.
It's really about the company/team having a preconceived notion of what skills they are looking for vs. looking to see if a candidate has a distinctive skillset that could help round-out the team. How do you, as the candidate, market yourself and the things you are good at?
Obviously, the resume is a good place to do such marketing (and I'm sure you already are) so if teams are turning down applications based on the homework without looking at the other skills the candidate has to offer, then that might be an issue.
I wrote a thing about it and I got someone who responded to me with a rather scathing rebuttal. I don't know, it's very conflicting.
Post in case you're interested: https://dev.to/spirodonfl/should-i-accept-coding-challenges-...
Edit: better wording
However, don't see how well take home can work for senior engineers. In fact, its unfair and delays interview process to expect take home assignments from working folks.
This really seems out of necessity. There are going to be a lot more qualified median engineers rather than superstar coders, so it makes sense to optimize your hiring pipeline to assess these folks.
In my experience, most of the "top 10%" hires are either through interpersonal contacts or a fast-tracked interview process for a specific candidate.
At least when middle managers do it they're only interested in who gets credit for the work so they leave the average tech guys alone long enough to get the work done.
In that case, the key was that clumps of them had already worked together in earlier jobs, so the incompatibilities had been pruned.
If you got an interview, and did well you got another challenging programming problem to solve on-site. You were given a computer with the programming environment of your choice and as much time as you wanted, as well as someone to ask questions from.
I think it was also important that the company solved hard graph problems in Lisp, with a lot of macro-driven code. If you were a Lisp programmer, you generally wanted to work there.
You can pretty easily hire the top 1% of applicants, and still get only mediocre results. E.g. at one job, when looking for a senior-level eng position, clearly stated in the description, we easily weeded out a couple hundred applicants who had effectively zero experience whatsoever. No prior programming-related jobs, internships, side projects, open source, nothing.
Which is a waste of time for everyone involved. Hence the heavy reliance on connections :(
In reality, the applicant pool is heavily biased towards very bad engineers.
I was shocked doing an interview in my last round and got so many test questions. I bombed so hard because it wasn't what I was doing.
The real key to me is, we treat all of these jobs as more or less the same, when in reality they are all vastly different. There is no singular senior engineer skill set, but a variety.
I wrote a whole blog post on that: http://www.mooreds.com/wordpress/archives/2812
I just wish companies would be more upfront about what they really needed, as opposed to the wishlist.
Exp: You must code in an unfamiliar language (Fortran 1988, for example) and do something simple in it. At least then you'll know that people are all starting from scratch. Time it, make sure it doesn't last more than 2 hours, see how laughably slow we all are, pick those that get the furthest.
* Predictive of job performance
* Either (1) difficult to optimize against or (2) easy to optimize against but in a way that doesn't reduce predictive value
* Low cost to give
* Low cost to take
How about "Google is giving tests in these 25 languages"? They could even choose languages that are purposefully dissimilar from any language that you've claimed familiarity with.
Even being upfront about our low expectations and providing very friendly and helpful people to pair and guide, it lead to record numbers flipping the table and stomping off premises before the completion of the interview.
I don't use this approach now, as I don't think its a good use of time (and I think an interview should be a positive experience even for those that fail), but it did provide, I believe, a fairly strong signal of the attitude with which a candidate approached learning new things (but not really anything else).
Really, please, tell us more!
It's not that you're wrong, it absolutely is a really good way of finding out how someone reacts to being asked to learn something new in a stressful situation. And that is a valuable thing to know - I love working with people who get excited about an opportunity to learn something.
It's just that you have to be prepared to give so much help and the question has to be so easy because it's all completely new that you can't test competence in any meaningful way. Which means that at the end of the 90 minutes or whatever, you know exactly one thing more - their attitude to learning under pressure, but you have relatively little time with them, and you probably need to learn multiple things per session.
You also have to be careful when in the interview you throw this. A bad hit like this can throw a candidate off for the rest of the interview even if they are quite acceptable.
1) Some people may find Fortran easier to understand than others even if they haven't touched it before. This was the case when my University decided to use Haskell* as the first language to teach students in order to level the playing field. It did help somewhat, it leveled the field for those with little and those without any prior programming knowledge. But to those who had already come to terms with recursion etc it was a very tiny stumbling block.
2) Some people need to dive deeper and gain a greater understanding of things before they feel at ease using them, but once they have reached that level, they will often outperform most other people.
* This was 20+ yrs ago and Haskell was not so well known back then.
nice to see it's more common
Oh wow, that would definitely get me sweating. All the FORTRAN i learned was 77!
The Kobayashi Maru test.
So much focus has been put on 10x this and high performing that. Companies waste lots of engineering talent and company money looking for 10x when 10x is mostly situational in nature. Set the scene. In one scene the engineers are not producing. Change the scene and now they are 10x.
Instead of looking for 10x, that time would be better spent making incoming and current engineers better at their jobs and creating 10x situations.
I can relate to this. I have pretty good resume - good schools, advanced degree, impressive sounding projects, a long list of publications. My track-record suggests I am at least a 3x engineer.
So when I get into a coding interview, I'm expected to perform as such... but I usually come off as a 0.3x engineer. Like really bad. Forget syntax bad. Forget algorithms bad. I've bombed so bad in a technical interview, the interviewer questioned if I even knew basic trigonometry. They had spent 10 hours interviewing me prior and felt good, but got me in person and suddenly thought I was an idiot.
In each of my jobs, I've had a considerable ramp-up period. I'm talking 6 months or more of feeling completely lost and unproductive. I get in my head and it makes me perform worse.
If I'm not fired in that first period, I'm lucky. Only after about a year on the job I can perform at the level my resume would suggest.
I regularly look things like that up. I am a builder and a problem solver, not a reference manual.
"I'm your Google, anything you'd need to look up just ask me and I'll give you the answer".
Great way to take the pressure off plus it gives you a good idea on how well they ask questions/are comfortable leaning on others. It's a huge plus if I can get a reasonable candidate to admit that there might be parts of the problem at hand they don't understand.
I've written code tests where I'm expected to read the code, find the issues and fix them on paper. But when they take it too far beyond the spirit of what I believe to be a reasonable test of understanding and fixing code, then I write that I'd just for example compile the program and look at the output.
The companies that are most into questions like these seem to be the classic (failing agile) body shops with ridiculous turnover of their talent, which causes them to have to interview even more, which causes in turn for their tests to become even more abstract and worthless.
Most engineers can be productive in a month. The 3x engineers take half that.
Do you see how that putting-words-in-others-mouths looks? It's rude and does not contribute too any kind of productive discussion.
6 months to get into things is kinda long though. Unless it's super complex things, it should be less. Are you sure you are not exaggerating?
I respect your opinion but I find this strategy very strange. (Or maybe I don't exactly understand what you're saying.)
In my view, it would be a dream scenario if the next 10 programmers I hire were all superior to me. If I was the worst programmer on the team, that would be an ideal outcome. Yes, I've been programming for 30+ years but I'm also self-aware of my limitations. This gives me the ability to recognize better programmers and learn from them. If I'm not hiring interns, I do expect (or at least hope) that they are better than me.
Am I competent enough to write a "do/while" loop and knock out FizzBuzz in 5 minutes?!? Sure, but that doesn't mean there aren't better programmers than me. I would consider it a great business skill if I'm able to consistently attract superior programmers -- either to work with me or for me.
Larry Page attracted programmers better than him (e.g. Jeff Dean). Yes, Larry earned a masters degree in computer science but his java programming (the rudimentary 1996 crawler) wasn't considered very good. His employees rewrote the whole thing in C++ and made it scale for billions of pages. Bill Gates hired superior programmers. Mark Zuckerberg hired superior programmers. Etc. etc.
It doesn't seem like it. The next 3 sentences from the thegayngler:
> I have but one qualification. Can they do the job? Are they strong enough that I can guide them into the position I need them at if it is required.
In my mind, programmers superior to me have abilities that would be beyond my knowledge to "guide" them. They can come up with programming solutions I could never think of. It's very realistic that "the qualification to do the job" essentially means they are a better programmer than me.
Presumably, in your mind, "programming" skill is along one spectrum and one focus, as well? I think that's part of what's being talked about here. There are many, many aspects to software engineering/programming (depending on whether you want to classify them differently), and many roads that could have been taken to get to the point someone is at. I see no reason to think that someone that is better or worse than me in one aspect will also be so in every one of the other aspects of the job.
Let me try to restate that in more general terms and you can tell me if I interpreted it correctly: Since programming skill is multi-dimensional / multi-faceted, and it is unlikely for a programmer to be superior in _all_ dimensions compared to another, it is therefore not possible to conclude if one programmer is superior to another.
Is that a fair rewording?
My response is... sure, programming skill can be looked at as multi-dimensional. But so can other real-world comparisons. We prioritize the dimensions that are more important and collapse all aspects into a composite score.
Multidimensions such as choosing a new job: Company X is a 5-minute commute with 4 weeks vacation but Company Y has the newest technology and has lucrative stock options. Yes, it already goes without saying that there's more than 1 aspect of "desirable working conditions" at each company and no single company can claim a superior score on _all_ aspects. We can still weigh all aspects and eventually pick one (and only one) which is superior.
If I hired a "Jeff Dean" type of programmer, it would be an upgrade to my team and my company. Could I search for an "aspect" that I'm better at than him? Well, looking over his expertise[1], it looks like he doesn't have much frontend GUI programming experience. So yes, I guess I could claim superior skill on writing event handlers in C# language for buttons. That's not important though for my assessment. My point is I don't need for programmers to be superior to me in every aspect for me to determine that they are superior overall. (Same as determining which company is "superior" to work for.)
If I was founding a startup and I was the "ceiling" of programming skill instead of the minimum "baseline", my company would fail. I think I'm pretty decent at programming but I have no Dunning-Kruger delusions that I can "train" anybody that can pass FizzBuzz into a "Jeff Dean". I know of no 6-week bootcamp or even a 6-month corporate training program that can claim that feat. What I can do is recognize the programming skills in others that are (overall) superior to mine and hopefully convince the candidates to come work with me.
[1] https://scholar.google.com/citations?user=NMS69lQAAAAJ&hl=en
Well... no. But I think that's my fault, for the most part. I read the part of your original comment that said 'In my mind, programmers superior to me have abilities that would be beyond my knowledge to "guide" them.' as implying all their abilities as being beyond you, but it doesn't specifically say that.
I wasn't trying to imply that it's foolish to try to ascertain if one programmer is generally better than another (as long as some common domains along which to measure are involved), just to note that it's possible to hire someone that's far beyond you in some areas, and behind you in others, with the intention of specifically helping them build in the areas they are lacking (which have application to the job). The result should be a programmer that is, generally, as good or better than you in most areas, making them a more obviously superior programmer, even if that wasn't entirely obvious at the time of hiring.
In short, you can hire for the things that are important that you can't easily improve while allowing deficiencies in the areas that are less important which you feel you can help them improve in.
As a strategy, it has it's pros and cons. As a pro, it's probably easier to find candidates since your criteria is less stringent. As a con, you might find the candidate you hired has problems coming up to speed in those areas they are deficient in (which may be why they were deficient in the first place, instead of lack of experience).
I didn't really express the point very well originally, and just stopped at the opening, probing question.
In my experience the manager cares about fit and attracting you to the team, whereas the peers are all looking for reasons NOT to hire you.
Ive seen companies literally turn good engineers into underperforming engineers...stifling them with process, tech debt, politics, etc... Then they get angry some people can perform and others can’t under the circumstances and conditions the management created.
I’ve watched perfectly good engineers get fired or forced out for not being miracle workers only for people to later realize there was nothing wrong with the engineer in the first place.
You don’t know who is going to be the best until you work with them. I would advise people to pick people they will like even under the worst of conditions and train them to the way you want them to be.
I also find it remarkable how quick people are to blame the engineer, rather than considering the whole picture (process, tech debt, politics, etc). It's a complicated equation with a large number of variables.
Jokes aside; I agree with the advice of hiring people smarter than you in the domains where you won't be paying attention should the company actually take off.
If you're looking to be a founder/CEO level type, doesn't seem to matter what your skill in Java and OOP are, yes? No need to be a water walker.
That's the "genius" of management; they sell an idea and get someone else to do the work.
I wonder how much of that comes from being exposed to all of the consequences any poor decisions they made shortly after they were first hired.
This is so correct.
Productivity follows when people are working for a worthy cause. In fact the core of productivity isn't lists, management techniques or whatever, it is a thing called 'constancy of purpose'
There exist no such a thing called 10x burger flipper.
Imagine a programming ecosystem with e.g. 5 approximately equally popular frameworks. Suppose that someone with this attitude is familiar with frameworks F1 and F2, but never used F3, F4, F5. Put such person in charge of an interview, where equally skilled candidates (i.e. knowing 2 of the 5 frameworks) apply. They will only classify 10% of them as "senior-level" (those knowing F1+F2), and additional 60% as "somewhere between junior and senior level" (those knowing one of F1,F2; and one of F3,F4,F5). So they would hire literally themselves, but probably not someone on the same level.
IIRC a Google recruiter once sent a set of packets to a hiring committee and all of them got a "no hire". Then the recruiter revealed the packets were lightly-anonymized versions of the actual packets of the hiring committee members, from when they'd all originally interviewed.
If you don't encourage a culture where everyone is asked to hire people better than themselves, it can easily degrade where each progressive hire is slightly worse.
How does a fear of firing impact hiring procedures? If you are afraid of firing, you're afraid that you won't be able to get rid of a toxic individual; that a single individual will act as a poison to the morale of your entire workforce. Thus, you want to make damned sure you don't make a bad hire in the first place - even when it means you leave a position open for a really long time.
This fear of firing has gotten so bad that FAANG-alike companies directly espouse how bad the impact of a bad hire is, how they would rather give up on 99 good candidates than hire one bad candidate.
But that's bullshit.
That's letting the fear of interpersonal interactions drive business decisions. The impact a bad hire can have on a work force is pretty minimal when caught and addressed quickly; it can even provide an overall boost to morale to know that the company is willing to address real problems in an adult way. Even a perfect initial hire can turn toxic after a few years: what will you do then, if not fire them?
Do you have 10 positions and 10 potential candidates? Hire all 10 folks, and fire the one bad person; your company will be better off for the decision. Much better off than it would be if you instead overwork your existing team because you haven't found your unicorn hires yet.
I've also explicitly called out the FAANG hiring practices, which are frequently held up as the best practices in the industry by those doing the hiring. After all, who wants to be even partially responsible for hiring "that guy" when you can not or will not fire them later?
But, here's my point: I've been part of the process that hired "that guy". I was also consulted on the decision to fire "that guy" a month later. I was wholly on board with the action in both cases; and in the process we got two other great employees that we never would have hired if we were afraid of taking chances.
Is there not also a fear that an overworked person will become toxic?
Apparently not at my employer. My team was 10 people 4 years ago, and we're down to 6 now, without much dip in workload. We had someone leave about a month ago, and we're still fighting to get a job rec to replace that person.
To me it paints a terrible picture. My suspicion is that the dangerous bad hires are not the utterly incompetent people who will flail in place until removed. The dangerous ones are going to energetically do all sorts of peripheral, irrelevant work, try to insinuate themselves into a lot of 'process' type setups, and move around the company in a way that stops anyone from ever noticing that they can't actually do anything. I suspect a lot of BigCos have very weak immune systems against such mobile 'attacks'.
[1] https://changemyview.net/2018/03/28/thats-bullshit-rude-enou...
Interviews are imperfect, and damaging candidates will slip through the cracks. Are you seriously suggesting that a business should decide not to fire someone based on their immigration status, rather than their performance and integration with the team?
Plus now there is a 60 day grace period for H-1Bs to try and find a new job.
The simple explanation is that it's really expensive to fire someone without cause. It takes months because the company has to produce a paper trail proving they fired the person for a valid reason to protect themselves from litigation. That's months of paying an individual who may be incompetent or toxic, months of paying people who put together the paper trail, all the morale damage the individual causes, the damage that might arise from firing someone, even if it's someone no one really liked.
All of those things are costly, probably much more costly than not hiring the right candidate. At least so the reasoning goes.
The cost is also not that high in non-at-will states, since there's typically a 3-6 month "evaluation" period where no paper trail is required.
There’s a lot of political bodies focused on playing up the idea that women and minorities are this big bad wolf suing legitimate businesses left and right over nothing, and winning. But it’s a largely fabricated narrative created by people trying to turn the leftist identitity politics arguments into a quagmire by “both sides!”ing the situation.
In reality there’s a substantial burden of proof for someone to win a wrongful termination suit.
1. As another commenter pointed out, most jobs are in "at-will" states.
2. Many companies require arbitration instead of litigation to settle any disputes as a requirement of employment.
3. It's just as expensive for the fired employee, probably more so, since if you litigate, you're unlikely to ever work again.
Even if you hire two do-nothings and a negative-performing person (consumes half an FTE's day in questions), you still end up with 6.5 productive people. And frankly, a 65% productive workforce is pretty damn good. I've seen lots of companies where <65% of people are productive.
Plus, some of the do-nothing people can be alright with some direction. Sometimes people don't get anything done because they just don't know what to do. I've been on so many teams where the manager said, "we need a person to do X" and they end up with some random person that doesn't really know how to do X. The solution that I've found is to find something they can do and have them work on that. Most projects have no shortage of work that's more time-consuming than difficult.
For negative performing people, I usually give them something kind of busy-work that doesn't involve the rest of the team. They might not be getting anything done, but they also (mostly) aren't weighing down the team by asking them questions all the time.
Why waste time? Why not just fire them?
a) Protect a vulnerable class of people from being fired (say over 40 people)
and not
b) Require 30 forms when firring someone in that class for perfectly valid reasons
Seems really really hard to hit both. You need to err on one side or another.. which way do you go?
There are plenty of people in non-vulnerable classes who regularly do indefensible things because they know their companies won't act on it.
Looking back, often no talent has been better than poor talent (or those that actually decrease group productivity). Huge opportunity cost with bad hires, and even more challenging to move them out to somewhere that they would be happier/more effective/less disruptive.
That in itself isn't unreasonable. While much of the US has at-will employment, most of the rest of the world does not, and hiring the wrong person can be extremely expensive.
However, I suspect with current hiring trends we should not attribute to malice that which can be sufficiently explained by incompetence.
In those circumstances, it's easy to imagine the mental math: Firing someone could cost many times their salary, but a screening service costs 50 bucks per candidate. So the chance of weeding out one bad candidate pays for the service, right? Where's the fallacy?
I think the fallacy is that the service doesn't actually improve the hiring process, and the ROI is zero.
They miss basics of OO programming etc. And then what? you take him in, which has costs time, money, hardware to let him go within a month? On the other side I think you can weed these out quite fast with 1 personal interview.
It's surprising to see the number of people who interview for lead technical roles that cannot code, or whose work is exceptionally sloppy. Incompetence is more commonplace than the author believes, even at the highest level.
Unless you meant “lead software engineering role” in which case yes, you are right.
I'm not saying that All Coding Tests Are Good, but they do provide a modicum of certainty in a very uncertain environment.
I can try and come up with reasons why that might be the case, why a simple OO modeling problem + a couple of trivial algorithmic problems (like, take an ascii string, return me a dict mapping characters to character counts) would trip someone up...but that isn't sufficient justification for me to want to continue to an onsite.
And that's the people who get past the verbal screen. Plenty drop out at that point. "I see you spent two years as a Senior DBA. Can you tell me what the acryonym ACID stands for?" "No, I'm not familiar with that" "Okay. Well, the 'C' stands for consistency. Can you tell me what one means when we talk about data being consistent in the database?" "It means when you write something it stays written (or some other made up twaddle)" "I see."
That said, I agree that coding tests that are completely unrelated to the job, and are geared toward college grads rather than long term developers (i.e., "Implement a (data structure)" or "Remember/discover an algorithm that was a PhD thesis 30 years ago to solve a contrived problem in a theoretically optimal way" rather than "Solve a real problem of a kind similar to what we'd expect you to do here") are dumb.
There were people who were bad at (possibly some because they were under pressure), it but nobody who couldn't do it at all.
I wasn't giving out a trivial question either.
I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam. Easier said than done, but what we have today, where the candidate pool is overflowing with impostors with great resumes is not working.
(I've had that happen several places)
"i passed the bar exam!" and nothing else doesn't get you a legal job you want.
and your medical boards, if i recall correctly, just mean you're qualified to go be a slave, er, uh, resident, some place for a few years.
Find me good certifications that are actually meaningful and relevant to my career, and I’ll do the study work and get them.
I have yet to find any.
Go long enough interviewing hundreds, you'll see a few no matter what. Have a crappy enough filter in front and you'll see them right away.
Asking the right questions at interviews are crucial for finding the right people. If a candidate for a programming job knows binary trees but doesn't listen to other peoples views I would say he's less worth to us than a listener that easily learns new concepts but is currently not familiar with binary trees.
BTW, leaving a candidate in tears is not professional recruiting. Please let someone with more people skills accompany you to your interviews, you might leave people with scars that takes years to heal.
I'm sure it's used under the hood in a lot of code I write and have written but so is XOR, manual memory management and a bunch of other lower level implementations that I don't need to spend time on when developing on a higher abstraction level.
Not sure why you would expect all programmers to know about binary trees specifically.
I'll bet, even with this feedback, you'll continue to ask that question, just because.
For some reason that company insisted on only doing interviews at 7:00 AM, and my brain doesn't come fully online until after 9:00 anyway. I felt annoyed later when the answer came to me that afternoon, too late: put the list in a hashtable, add all pairs of numbers for O(N^2) complexity, and check if each answer occurs in the hashtable.
Much later after that, I realized that all the other red flags I'd picked up on while interviewing there added up to an impression that their corporate culture was seriously f'ed up, and that I probably dodged a bullet by getting passed over quickly in the process.
The skill takes a long time to practice, and quickly evaporates once you stop doing it. Yet none of our work is anything like that. a more real world situation is reading documentation or SO for the function concat_ws that will turn an array column to a concatenated string.
however, the system that is, and one that you seem to think is ok, is one that discriminates people on many levels. Its a skill you do not get good at by working, so you must practice this in your free time. Now you just discriminated against men and women with families, people from less fortunate backgrounds, and others who otherwise do not have the time in the day to dedicate to a skill that is only useful to coding interviews.
as far as a comment above, I was a DBA for 10 years and can do pretty complicated queries off the top of my head, know how to optimize my indexes, worked with both structured and unstructured data in the multi tb size, ect ect, but I have no recollection on what ACID stands for. I dont really care. Sure, you may hire someone who memorizes useless crap, but then they have no idea why the IO has gone through the roof when inserting IDs out of order on a clustered index.
I just look up joins when I need them, and it's straight forward, but ask me in an interview and I sound like an idiot.
I wasn't rejected but I've been asked to retake a phone interview. Apparently, the interviewer had very good feelings about me, but found that I was "out of practice" as far as coding goes.
I wonder if my age is an issue (40+) or if they have a really high level of expectation. Are most other candidates super fast at solving these kinds of problems. I'm a bit disappointed because I'm not sure that I've got much room for improvement at that stage.
They want 23 year olds who just did their finals. You know, real stallions.
You know, real pegacorns.
It sounds to me like you did pretty well so don't give up.
From my perspective that is only about 3% of what I expect from a software engineer. Writing readable, easy to maintain code that is well tested, collaborating with product and other developers for how a feature should work, influencing technical designs, giving good feedback are things I value much higher than how quickly someone can write a snippet of code that works.
How did you arrive at that conclusion? Is it based on data or does it "feel" right based on an easily-measured metric?
This is _a_ metric but I wouldn't bet too much on it. I know lots of people that come to optimal solutions to "algorithm type" _much_ faster than I do. I'm pretty slow at that type of stuff. But... its just such a small part of what makes someone a good programmer. Building out a medium to large application requires balancing a lot of trade offs and figuring out how to keep things simple. I know seasoned, quality algorithm solvers who honestly just repeatedly churn out garbage applications. And they can tank the productivity of an entire team of developers in their wake. I don't know how you test for that, but I can promise phone screening for problem solution time isn't it.
Translated: "the one that did it much faster is a more recent graduate and exploitable for 100-hour weeks at below-par pay, hire that one".
Congratulations, now you know how to hire at a tech company!
The answer to that is almost always yes.
Maybe the interviewer was biased and led to think I was "out of practice" because he knew I was on the older side. But I'll give them the benefice of the doubt. I believe it's a competitive position and I simply wasn't in the right percentile to qualify.
Now, would my former self 20 years ago be more competitive for this kind of interviews? slightly faster perhaps, but I don't feel I'm at a disadvantage compared to younger candidates.
For many tech companies where they get a lot more candidate applications than they have positions for, the goal of the interview process isn't to avoid losing good candidates, it's to not hire bad candidates.
So much more goes into software engineering than "Can solve tiny example problems in an examination system"
True that software engineering is more than that, but those other things largely depend on in-house company processes, tools and policies so you would learn them afterwards.
It annoys me that the good answer if you actually encounter the problem during the job is never accepted during an interview.
They aren't looking for people who don't know to start by doing some research, they're looking for people who won't be completely stuck when that research doesn't turn up the answer.
So then I try and give them a O(n^3) solution (or something).
Of course this isn't accepted as there's a better O(n^2) solution, which can always be found by googling, and I fail the interview.
The "turtle and the hare" problem of finding a loop in a single linked list in O(n) time and O(1) memory is the perfect example. It's easy if you know the answer (or can google) but basically impossible if you don't.
What did the interviewer do when I said I couldn't do better than a hashmap? He laughed and said "not many can".
The gist of it is: walk the list and after each step, multiply the previous node’s pointer by negative one.
If the current node’s pointer is negative you’ve found a loop (because you colored it by inverting the pointer in a previous step).
Clean up by starting at the beginning and multiplying all pointers by negative one until you reach the last one you inverted. Then return your answer (true).
If you reach a null pointer there is no loop because you’ve gotten to the end of the list. Clean up by going through again and multiplying all the nodes by negative one. Then return your answer (false).
Your worst case running time is 2n (if there is no loop) which reduces to O(n) and you use O(1) memory because you’re coloring the list by using the already existing pointers in the list.
Which means what they're really saying is not "we want problem solvers". What they're really saying is "the bare minimum for entry level work here is being able to, in 30 minutes and on the spot, out-perform top-tier theoretical CS researchers".
Which in turn really boils down to "be a recent CS graduate who memorized this algorithm in advance so as to 'derive' it later on command".
They were probably looking for the answer of, "Lets talk through it and figure out a better answer". Coders are often under a mistaken impression that interviewers care about your answer. They don't. They care about how you approach it, how you think through it, what you do when challenged, etc.
So from their perspective, they asked you to try harder on a problem, and you just said, "No." And they dropped you for it.
FWIW, I had similar questions in some interviews where we hashed through similar problems, and together collaborated down to a "No" answer... but we spent 15 minutes exploring the problem and seeing how well a couple coders can work through it before saying no. And I got the offer despite an otherwise rusty performance.
I was asked to sketch the proof for the irrationality of sqrt(2) in a quant programming interview. I kind of froze, and explained that though I had learned it, I could not recall.
He prompted me with "Well, what does it mean to be irrational?", and with that little hint I did the rest. Though ultimately I did not end up working there, it was very satisfying to have answered it.
Well, in one case (me), all the information the interviewer had was "this guy happens to know how to implement a quick sort by heart. K.".
In the other case (my friend), he got "this guy is able to understand and implement an algo he never saw before in a reasonable time", which is much more impressive
Assume sqrt(2) is rational and has the reduced form (x/y). Thus we are assuming that x and y are integers and that gcd(x,y) is 1. You square it and get x^2/y^2 which are somehow simultaneously coprime integers and also reducible to 2/1...
> We now show that the equation (1) p^2=2 is not satisfied by any rational p. If there were such a p, we could write p=m/n where m and n are integers that are not both even. Let us assume this is done. Then (1) implies (2) m^2=2n^2. This shows m^2 is even. Hence m is even (if m were odd, m^2 would be odd), and so m^2 is divisible by 4. It follows that the right side of (2) is divisible by 4, so that n^2 is even, which implies that n is even. > The assumption that (1) holds leads to the conclusion that both m and n are even, contrary to our choice of m and n. Hence (1) is impossible for rational p.
This isn't always true. Some interviews are really about solving the problems as fast as possible. And lots of interviewers are looking for exactly the answer they have on hand, and will think you're doing it wrong if you come up with a different, but equally valid (or better!) solution.
Huge asterisk that as long as you arrive to the correct solution with minimal help. I've had plenty of algo/ds interviews and it seems like needing help to see the trick in the question pretty much means you're out.
At my last company, we would sit a candidate down at a pairing station. We'd offer them about 5 problems to choose from, and together we'd pair program on the problem for 2 hours. Using the internet, the IDE, anything they want was totally fair game. No system is perfect, but this was by far the best one I've ever experienced.
In many of the places that do claim this, even if you solve the problem "correctly" you still get more brownie points than someone who got a less efficient answer or didn't get an answer. Meaning that they /do/ actually care. I do get that some places are smarter with regards to this than others but it's depressingly common in my experience. "You didn't get the O(n) solution that has weird edge cases and was published as a paper in the 70s? Too bad, because some other person did, because they remember the solution from some programming interview book!"
The problem that I have with those problems is, they always assume it's easy to answer after seeing the solution. But if you're working on them for the first time, it's a terrible environment. The minute that they stop asking you, as the canidate, are on a timeline to finish. (Also, to finish as well)
The answer to that item would be: (with scala)
> datasource.window(3,1).filter((a,b,c)=> a+b == c)
I mean if you knock it out of the park and know the internals of window.. then asking the bar raiser question is appropriate as a curiousity.
There are other problems as well: Those are the ones where they have an expected answer, response, and reiterate. I've seen that with tree problems. That's where they would low-key ask for the recursive version and then get you to say stackoverflow exception.
My immediate solution: Sort the two strings and then compare them:
(defn anagrams? [x y] (= (sort x) (sort y)))
"Ok, what's the efficiency of that solution?"
"Well, assuming the library sort functions I'm using are sane, I'll take a guess and say O(n log n)"
"Can you come up with a more efficient solution."
Off the top of my head, on the spot, I couldn't. Later, during the plane ride home, the obvious occurred to me: Don't sort the strings, just scan through each string once and build a hash table, keeping track of the number of occurrences of each letter in each string. Then compare the occurrences for each string. Not as elegant to express in code, but faster.
As it turns out, they later declined to hire me, giving me an excuse that made it clear they weren't really serious about hiring anyone for the position (as is the case at least half the time, it seems).
And thus ended my latest round of failed interviews. I cancelled the last one I had scheduled (probably another fake) and decided to take a break for a while (I mean, I do have a job right now, so it isn't urgent).
You’re right.
ac = 1 + 3 = 4 bb = 2 + 2 = 4
So I think something silly like: character_code = len(string)*len(alphabet)^character_index should work.
Still, consider the word ‘abe’ with a = 2, b = 3, c = 5, d = 7 and e = 11.
abe would then be 2^1 * 3^1 * 5^0 * 7^0 * 11^1. ‘abba’ would be 2^2 * 3^2. Each anagram would have a distinct value.
See also Gödel numbering and FRACTRAN.
Reminds me of my final round at Amazon, which they always do in Seattle. I woke before 4 AM west coast time having flown out the night before from the East, and 12 hours later was still coding on a white board. After writing (to my surprise) a correct merge sort, they asked my to write a program to do basic math with, IIRC, binary numbers. I was like, um. I'm out.
And if you throw in distributed databases, there is yet another understanding of "consistency" (vis-a-vis the CAP theorem), which really means "linearizability".
Sorry, didn't mean to be super-pedantic but consistency as a concept may seem simple to the uninitiated but is easy to get tripped up on, especially for folks who are aware there is a deeper layer of understanding associated with the concept, but can't articulate it right off the bat.
All this is to say filtering people truly is a hard thing. The extremes are easy to tell apart, but people who hover around the average are much less differentiated.
[1] https://en.wikipedia.org/wiki/Consistency_(database_systems)...
And I have similar anecdotes related to candidates who claimed years of distributed systems architecture experience, and were yet unfamiliar with CAP (and when explained, could not tell me even at a high level whether, in the event of a partition, their system was CP or AP, let alone the specifics of how that actually exhibited itself).
Once you start working on a particular database, and are working on all of the specific details of that db, how often does ACID come into things, really? It just doesn't.
I don’t think it’s essential to know this, but I’d be surprised if a web dev interviewed with us and didn’t know at least the basic version I’ve given above.
Just my experience, perhaps I live in another world.
I think this is partially what I'm referring to. I use these terms in conversation with others when designing systems because they are useful in describing very specific properties of databases.
If you legitimately did the work without picking up -any- of the terminology, -and- respond confidently to questions you should know you don't know the answer to (rather than admitting ignorance and asking for follow-up questions, or declaring assumptions, i.e., "Well, I would assume it has to do with the behavior that if a constraint is violated or something similar in a transaction, the transaction will be rolled back instead of committing"), I don't want you. Because it means you both did not have formal training in, AND didn't seek out information or knowledge in the domain you were expected to be -senior level- in.
And while atomicity and durability are just characteristics of a relational DB (and so adminning one doesn't really require you to understand them), isolation and consistency both have definite relevance, because the isolation level is configurable, and that affects the consistency guarantees of the system. I expect someone saying they were a -senior level DBA- to be able to talk intelligently about those behaviors, and yes, to understand the words, because just reading the docs would have introduced the words.
Otherwise, I think we simply disagree in some respect, although I think it's over emphasized due to the topic. I think both perspectives have a level of truth to them, and have their flaws. It really depends on the candidate, and what they really know. Perhaps my particular circumstances are sufficiently odd enough that they aren't useful in a broader context. Who knows.
One of my mentors said that about an interview he conducted a while back. I found a lot of truth in that line. I run my tech interviews by starting very green and let the candidate dictate how fast I ramp it up. I've gotten pushback from managers before that you can't start with basic questions, but I've equally gotten positive feedback from candidates (even one's who've been failed the interview). In the end, programmers want to see an algorithm that allows them to judge an interviewee. I don't believe one exists.
I mean, look at this thread; would it be better to start with "Here are some example tables, please write the SQL that will return me (etc)" and turn it into a coding exercise? Because I honestly don't care that much about that from anyone espousing a senior level of knowledge.
None of the techniques discussed in this article are even attempting to judge productivity, they are attempts to judge coding ability. It's good that you bring up productivity though; that's what we are really after, isn't it?
>from a short conversation
I'd argue 30 minutes to an hour is not a short conversation. Do you think an imposter could fool you about tech (assuming you are an active programmer) for 30 minutes to an hour?
>it's probably better to see the proof
You're not proving anything except the fact that the candidate has memorized a merge sort algorithm (or whatever trivia you are testing for). What you really want to know is, can they ship?
I think you should at least consider the idea that not only are these tests and homework assignments (past fizz buzz) a poor indicator of ability, they active repel any candidate good enough to be in even reasonable demand. I mean you have a lot of people on not only this thread, but many other threads saying the same thing.
Time for a little reflection, what does your company offer that even a mediocre developer can't get in 20 other places in your city? I mean if I could get "market rates," and a "fine cubicle," and "standard PTO" in 20 places, tell me again why I would bother with this rigamarole?
I have no idea where the idea that having someone come on site for 6+ hours wasting a dozen peoples time became the norm as opposed to talking to someone for 1 or 2 hours and truly speaking with them to understand what they know.
You're completely right, if you can't talk shop and not know when someone is bullshitting you shouldn't be the one interviewing.
How would this even fly in other industries? Are you telling me that someone can bluff their way discussing the intricacies of surgery to other surgeons without looking like a moron? Or discussing particle physics with a researcher and stand on equal footing? I honestly want to hear a conversation where a liar with no programming skills is able to convince a Senior level Software Engineer that they are on equal skill sets.
The best interview experience I had, where I eventually worked for the company, was having an hour conversation with the Engineering Manager who I would be working under then being ask basic programming Qs based on our conversation we had. Everyone in the company was interviewed the same way. IMO the resulting team was very professional and skilled on various levels from various backgrounds. I actually felt like a human at that job and not a person hired because of x thing.
I'll never forget I had an interview where they asked me a question about finding anagrams. At that moment in my life, I've never heard of an anagram or knew what it was. The Interviewer then explaining what it was to me made me feel very humiliated. I completely bombed every question because I had the audacity to not know about this thing where the interviewers knew about thing therefore I should know thing as well. I immediately understood how cultural biases can effect candidates getting jobs. I can only imagine how worst it is for people not from traditional backgrounds in this industry.
I had a candidate for a 3d graphics job, who showed me incredibly impressive things he'd programmed like very realistic water simulations, etc. He talked us through them, was incredibly articulate and clearly knew his stuff.
He completely bombed the coding exercise. It was something like: given 2 hours alone at a computer, with a threejs scene already setup, make it display a few cubes at different heights, colors, etc. Full access to internet, google, etc.
He couldn't get one cube to show up. That's maybe a two line piece of code when given the entire environment already set up, and you can find it by googling Threejs tutorial and copying like the first example.
Ya.
As far as graphics, the only time I was ever fooled was by a front end guy in 2005. He brought really nice looking color printouts of his front ends; beautiful stuff. I was really wowed by it; so much I didn't ask him basic programming problems or follow up questions about his prior work, and that was my fault. I allowed myself to be fooled.
His biggest issue was he was lazy. He had grown accustomed to government contracts where you do a lot of prototyping, but nothing ever went live (at least the contracts he had). We had a very aggressive 3 year schedule to build a sophisticated product and he just couldn't or wouldn't keep up. I had to double my workload and he ended up only doing about 5% when he should have done a third and he required a lot of prodding and hand holding. We still managed to ship on time though, but it was really hard on the other 2 people on the team for 3 years.
I'll never make that mistake again.
Perhaps he really was a very talented developer but your coding exercise was too stressful for him. Shame you missed out on hiring him.
This is not a story to show why we should do coding exercises. It is a story to show why they sometimes don't test the right thing.
1. He knows how to do extremely specialized things in an existing environment, but can't do things outside of that environment.
2. He was presenting work that he had only a partial hand in creating.
3. He is amazing at e.g. C++, but cannot learn even rudimentary new things in Javascript.
...
Some of these stories make him a terrible programmer. Some of them make him an OK programmer for other positions, but weren't relevant for us. None of the stories make him a particularly great programmer.
"Perhaps he really was a very talented developer but your coding exercise was too stressful for him"
Yes, it's possible. A lot of things are possible. But I'm sorry - if someone can't copy-paste a 3 line program from the internet and get it to work, in their own field, for 2 hours, then... I don't know how I could ever design a test on which they won't fail. Including the actual job.
Honestly, that's way too trivial to call "can code". I usually ask something less trivial, yet still extremely easy like "a function to check if a string is a palindrome" (I explain what a palindrome is) or "check if a substring exists in a given string".
You wouldn't believe how many people "with 10 years experience" just lose all motor function in their hands and mouth, even without any time pressure.
Coding in the large is project management and could be tested by a take home, but I'd rather tease it out by asking in person questions about organization, prioritization, and technology choice.
Throughout my career, I've been in professional situations where I was under a lot of pressure: Having to explain failures to executives, near-impossibly tight deadlines, production outages. At least I haven't had to testify in front of Congress yet. Absolutely NOTHING I've encountered in my professional day-to-day has the extreme level of pressure of a typical silicon valley job interview.
Because if I hire that person, they'll be in charge of critical production systems and will face much harder problems in much more stressful situations and if they can't handle the palindrome question, I have very little confidence they can handle the actual job.
Not claiming to be that hero, but I have personally had those moments where I came out of the interview, and as the disorienting fog of pressure lifted during my drive home I said to myself, "WTF happened to my brain in there? I know that stuff cold!"
EDIT: I think I read this one from a commenter here, but it's so true: We're interviewing people to be music composers, but judging them by their ability to be performance artists.
(i.e. bring out groovy, using bash, etc)
Is it reasonable to ask things like that? Maybe, maybe not.
But as stressful as an interview is, it's still a basic problem (I can English describe it to you in 30 seconds...coding (in C/C++) would take me another 5-8 minutes (and, probably, be pretty damn inefficient ... but it's still a simple problem)
Checking substring in a string is a 1 liner in languages like python.
I was at a final interview with FAANG. One question asked was to load a csv. I used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a
with open() as f: do_some_shit
and kept pushing me to write this on the board. I looked at him and said "Why? Why write your own method in a vanilla language? Give me a good reason."
That's like answering "how often do you need math?" to the question "what is 2+3?". It is an utterly, completely, stunningly trivial question that even a CS101 student on their first semester should be able to answer.
> used pandas, it's a 1 liner. You could see the wretched face of the interviewer since he was expecting a with open() as f: do_some_shit
I would be perfectly fine with the pandas answer, but my point is "csv parsing" wouldn't be my first question, I'd start with something much easier and if you managed that, I'd gladly accept pandas as a valid and then asked you to elaborate further (what does this pandas function do, how would you implement it yourself etc).
What are the downsides to using pandas? Is that worth brining in that large of a library for a matter like that.
They can't ask you a complicated problem, because they don't have the time (nor do you) to solve a real problem that requires coding.
You are totally missing the point of what they are trying to ask you if you insist on using pandas for parsing CSV. Understanding the point of what you are being asked to do is critical to being a professional software developer.
I’ll take someone who gives an idiomatic answer over someone who reinvents the wheel anyday. Who is likely to be more productive on the job?
They can definitely ask a complicated problem. On-sites are 4 hours long these days.
The ability to understand the underlying need behind a request is important to being a good employee. If a candidate fails completely to understand the purpose of a question during an interview, and in fact continues to argue against you as you explain it, they aren't a good candidate at all.
I agree with everything you've said, but that still makes it a bad and equally obtuse question. If they don't actually need a CSV parser, they don't need to know that you can parse CSVs, either (if you can - which is the other point - you might be a pretty good programmer if you can quickly parse a CSV, but there are tons of excellent programmers who can't).
And that was when I found out parsing something that should be as stupid simple as CSV file can actually be pretty complicated.
I understood the "purpose" of the question and I self-selected myself out of a role I would've been bored, micromanaged at, and probably not challenged at.
Overgeneralized at best, LOLworthy at worst. Does this include palindrome questions for Ruby that require the use of linked lists? Because I had that from a CTO of a couple-hundred person company not two months ago.
I think to some degree, a suspension of disbelief is reasonable for an interview, and it's not worthwhile to get tunnel vision on a particular problem asked. It's ok to point out that something is trivial with a particular widely used library or whatever, but if it is asked to implement something via first principles or whatever, it is a perfectly reasonable expectation to just do it for interview purposes as a simple mental exercise.
There's a few things going on here. First, there's a frustration from the interviewer who is obviously looking for the cookie-cutter answer to move things along. Second, there's a culture misalignment because they are looking for cookie cutters to do the job while I am not that. Third, they, along with OP, are obviously not a palindrome company nor a load-everything-to-lists company yet this is what they're testing. So again, culture misalignment.
At the end of the day, you are right, I self-selected myself out because I would not be happy at a place like such who are looking for cookie-cutter employees.
That you couldn't yield on such a trivial, manufactured matter would make me wonder how you respond in a team environment on real matters in the face of adversity.
One of my go-to questions is "sort this array", and if the candidate types `Arrays.sort(input)` they get bonus points, because it shows they have useful knowledge of the language they'll be writing in.
> I took my sunglasses off, looked him dead in the eye,
> and said "Why? Why write your own method in
> a vanilla language? Give me a good reason."
It's a synthetic interview question. Why does it suddenly need to be a production-ready CSV parser?
We don't have enough information to say whether these are bad interview questions, and it's really not the point.
Maybe the interviewer just wanted to see if you'd use good fd hygiene (`with open('file.txt') as f:`) and that you can stub out some toy parser code and speak of it intelligently. And that you wouldn't throw a fit when asked to write some code that a library like `npm install fizzbuzz` can already solve.
Creating a dependency to a library is not benign. Even if the library is easily available and mature doesn't mean that everyone has it, or that it will never change. Remember how "leftpad" broke npm?
Having that smug attitude towards the recruiter, assuming he is an experienced developers himself, should rise a red flag. Yes, sometimes projects have constraints (like "no pandas") that may seem stupid, and sometimes they are. But it is first important to understand the context.
So instead of asking "give me a good reason?" to the recruiter, give the reasons yourself. Invent a scenario where you actually need to rewrite that csv parser, bonus points if it is related to the company's business, and finally, write the damn code the recruiter wants you to write.
In my case about a decade ago, I became obstinate when given one of those silly math-trivia-puzzle problems like how many ping pong balls will fill an elevator or how long is a string. This was for a relatively senior track FAANG interview, where my background at the time was in HPC, distributed systems, and provisioning systems that were precursors to today's IaaS bread and butter. In my case, the interviewer was adamant that I derive some figures that depended on basic geometry and knowing the diameter of the earth and ratios of landmass to ocean surface. But, he wanted me to first SWAG these figures, after I told him I wasn't a geospatial geek and didn't memorize such facts.
I decided to be difficult. If I were somehow faced with such a task, I would first consult reference materials and even see if I could find the actual answer he wanted, since it sounded only one step removed from what you could find in the CIA World Fact Book or similar. Only if that failed, would I dig up source facts and try to derive an answer. I would focus on getting the answer, not on entertaining myself with a Martin Gardner puzzle at my employer's expense and risk. I would never have to make seat of the pants estimates and act on them rather than doing due diligence. I'd either have done homework, or if there was really no time (like some system availability crisis, if we pretend I was an ops person), I'd choose a pre-planned contingency action to make time.
They didn't go forward with an offer, and I felt a bit of relief at that.
I asked "Do you want me to do the simple thing, and use a library, or write code to do this?"
They preferred the latter. So I did.
As happy as it might make you to be snarky for the often silly questions you are asked, people are, if they are smart about it, looking to see your thought processes.
I recently got a question that I didn't know how to answer, so I started thinking through it aloud. I think they liked it, because they engaged with me during the process. Redirected my thought processes.
Again, good companies will do that. Look for every question, no matter how silly, as a way to show how you deal with situations, even ones you may not like. These are the moments for you to shine.
And after you get home, tell your SO/friends/etc. how wacky they are.
Can your pandas library handle that?
Your response is to flip the table and leave? If so, then good riddance.
const isPalindrome(str) { return str === str.split('').reverse().join(''); }
And the post interview notes said bad performance on the isPalindrome() question since I didn't write out my own functions (interviewer did not mention to).
The interviewer probably should have probed you about performance though if their intention was to judge you on that (they're both O(n) time complexity, but split, reverse, and join are generally more intensive).
Id say that close to 0 out off 10 engineers at work including me would get a working program without debugger or print statements.
Just tried in c and got me 2 compiles to get it right. Without the output I would just present a nonworking program.
"Write a function that counts the number of vowels in a string"
Candidates are allowed to run it multiple times and just have to produce a correct result within 10 minutes. It's not a trick question -- the test case in place makes sure you pay attention to case.
Success rate for mid to senior devs? Only 60%.
Took me less than 10 seconds to come up with an approach that would work oh just though of a more efficient one but that would use a regex :-)
"Write a function that reverses the words in a (string) sentence"
i.e. (x) => x.split(' ').reverse().join(' ');
The fastest way to reverse a string is in JS is:
function reverse(s) {
var o = [];
for (var i = 0, len = s.length; i <= len; i++)
o.push(s.charAt(len - i));
return o.join('');
} return inputString.Count( "eaoiuAIEOU".Contains );
static Regex VowelMatcher = new Regex( "[aeiou]",
RegexOptions.Compiled | RegexOptions.IgnoreCase );
...
return VowelMatcher.Matches( inputString ).Count;
return 2; // number of vowels in "a string" def vc(s):
return len([c for c in s if c in ['a','e','i','o','u']])I've run into this issue in different specific ways earlier in my career and no matter what I'd say about skill level / lack of knowing required technologies / being willing to take lower pay in order to justify aiming for another role it didn't matter in the face of the possibility that the recruiter could obtain a larger % for themselves off of that senior / higher-than-in-my-range job's salary.
Maybe this isn't as applicable for senior dev role applicants as it is for some lower level dev roles but at the point an applicant is actually physically there in front of the interviewers I'm sure one of the last things they are going to want to admit is that they wished they were interviewing for a lower paying / easier job even if it's 110% in the favor of both parties.
I've tried working with them before, have gone on job interviews through them, and then generally found that the jobs that hire through recruiters pay peanuts, and I end up finding a permanent job paying much more and taking that instead. I think if a company only works through 3rd-party recruiters, that means the company has no idea how to hire people, and doesn't want to pay much either (because they're paying the recruiter a huge commission).
Not to mention most of the one's I worked with early in their career not only had no idea about any of the technologies they were checking to see if I was fluent in but they also acted like they DID know everything about programming and beyond that they tried to flaunt this fact and treat me like I was trying to overstate my skills to sneak my way into a job out of my pay range.
Such a frustrating ecosystem in order to find a career job.
In ten years I can count on 1 hand how many times I've gotten a reply from a non-recruiter job I applied for (applied on my own without a staffing agency submitting / representing me).
It's really crazy how that works.
Another thing I dealt with was people who hired me saying (TO MY FACE):
In this situation I'm making $35.00/hr as a Regular Developer (non-junior / non-senior dev, just a middle of the road contract developer):
CEO of company in front of everyone: "scoggs we are paying way more for you than we are for our senior developers so we are expecting top notch work from you."
Me (used to it by now, unfazed but I hate this situation): "Sir with all respect I'm only getting less than 1/2 of what you pay my staffing agency for my contract/"
CEO: "well they don't really do anything / didn't really do anything but introduce us and get you a phone and in person interview with us."
Me: "But you guys didn't have to pull programmers, HR, and design / copy writing people off of their normal work to create interview materal, submit interview material, review resumes, vet candidates, plan phone interviews and schedule them, set aside time for phone interviews, review phone interview candidates among 'hiring team', review candidates references, plan in person interviews and schedule them, execute in person interviews and have meetings with 'hiring team' to pick who to hire', make offers to people you want to hire, or hire them. All you had to do was tell the staffing agency what skills your were looking for and what kind of company you were. I'm not an employee of your company. I don't have insurance, I don't get paid for sick days, I don't get paid for holidays, and I have no job security."
Of course I didn't say all of this, I said something along the lines of "They take care of the majority of the process" but in my head I feel like I'm always having to live up to the expectations of the people paying the total bill. The same way they think the staffing agency doesn't do any real work and isn't worth the cost / price of doing business -- most of these people feel the same way about developers. They don't understand what we do, they just expect us to solve anything and everything to do with computers / programming / technology and this is ALWAYS the way it is regardless if the final product / project outcome is directly tied to the company suddenly turning a profit based on the success of this project / programming endeavor.
These companies want to underpay contract developers, pile stress on their shoulders, guilt them for the situation they have little to no control over, and then stick them with the majority of the blame if things don't go 200% well (because they are expecting work that's 2x as good as the amount of money I'm being paid).
I've found it impossible to truly and personally (mentally) live up to the majority of expectations laid upon my shoulders by non-technical CEO's / Presidents / Bosses of companies I've worked for.
This is the majority of what I deal with right outside of NYC in Northern New Jersey. There is the rare company that truly respects the programmers they hire (usually companies where programmers have become CEOs / Presidents / people in powerful positions within the company who wield influence).
I love the money I make in this market but I truly hate the way everything makes me feel even when the situation is like this yet I am able to deliver above and beyond expectations. I hate working for people and in situations where it feels like I'm being told I'm robbing the company when meanwhile the recruiter is robbing us both yet they have us pitted against one another -- and beyond that the staffing agency has a 2 year lock on me being able to accept a job from that company without them "buying out" my contract.
The cost of buying out a contract? A university wanted to do that once early in my career (I wish I was still working there frankly, 10 years later), but the staffing agency wanted 2x the amount the university was paying the staffing agency! I was making $60,000/yr at that point so on top of the University paying me somewhere in the realm of $60,000/yr they would have also had to pay the staffing agency ~$240,000 just for the right to hire me. That means they would have had to shell out $300,000 total including my salary and the buyout.
Nothing about that seems right and / or legal. Under no circumstances would I ever be worth that much to the staffing agency and honestly with the amount of work they actually do I feel like it's damn near criminal.
No State University that pays employees with citizen's tax money is ever going to be able to justify spending that type of money on 1 employee. It's just a fantasy of epic proportions.
Anyway, you make it sound like you can't get a job there without a recruiter. There's still plenty of companies hiring directly, I even interviewed at a few when I was there such as Alcatel at Bell Labs and some wifi company in Manhattan. My current gig is with a large company (in the DC area) that hired me directly. Stop wasting time with recruiters and just look for companies that do their own recruiting; there's no shortage out there that I've seen. I've had 8 jobs now that were not contracts and not through recruiters: 3 large corporations, 3 small companies, 1 mid-size, and one a state university research division. Am I apparently special that I'm able to find these jobs?
Personally, my first-line screen is a short answer (3-5 sentences) to a programming-related question. [1] For me, about 90% of applicants who pass that can also code. I like that better than a resume screen, as plenty of people who haven't officially been programmers are decent coders.
[1] Examples here under the "Join Us" section. https://web.archive.org/web/20151005181908/http://www.codefo...
Our standard fizzbuzz question was something like: print the multiplication table. This is a loop inside a loop. I think every programmer should be able to do this given 10-20 minutes. Around 30%-40% couldn't. Like literally, didn't know how to do this in languages they supposedly work in. I'm sorry, I make lots of allowances for stress, I calm candidates, I tell them syntax doesn't matter, do it in pseoudo-code for all I care. But if after 10 minutes you can't print a multiplication table on the screen, I'm going to pass.
The worst part is that usually these toy problems are justified with "but you can post this to your Github for others to see!"
Likewise, if someone wants me to walk them through a project I have with explanations of what choices I made and why, I'm happy to do that. But please don't waste my time asking me to implement DFS, or write another twitter API client.
Now: If you care about being able to collaborate on a tough problem with somebody, work on a problem neither of you has seen before together :)
Perhaps because, like many developers on modern teams which eschew the older role distinction, the incumbent in the position being hired for will need to act in the role of a classic system analyst in defining specific requirements give a fuzzy business problem as well as the role of a grunt coder.
Also, the presence, functionality, and quality of code on GH does not establish it's provenance.
Sure but that's a different skill from solving DS/algos, so don't conflate the two. Some people know their DS/algos super well but need to solve them solo, some people need to google around a bit for inspiration or take a walk if they get stuck.
Instead, separate it out. Give a specific "system analyst"-style question that's distinct from coding. A question you don't already know the answer to or that could be taken in a thousand different directions that you've definitely never thought of before.
If you need proof they can "actually code" and use DS/algos etc, use their GH if it exists. And if you want to see that they can work on a team to define and deliver a messy problem with other people, do that with them on a messy problem you've never solved before. (It could eventually be a DS/algo problem; my point is it's a group effort and neither of you knows the solution; you're looking explicitly for how the interaction goes, not if "the candidate" got the "right" answer.)
If you don't take a candidate's prior art into consideration, you're wasting everyone's time. You're also eliminating candidates who may excel in ways that aren't solving riddle-problems out-loud in front of new people when their livelihood is on the line.
Start with the GH and if you have doubts fall back to portions of old model.
> So I'm supposed to spend my time researching your GH instead of just letting you spend 5 minutes proving it?
I've never seen a worthwhile programming q take only 5 mins to answer. And the candidate is supposed to waste an hour of her time proving to you what you could see in 5 minutes on GH?
> There isn't enough time in a day to research every candidate's code they wrote on their own time
Yet there is enough time to spend with whiteboarding problems that prove the same things the candidate has already proved on their GH?
> (and personally I'd rather not be judged by mine).
Sure - only use the candidate's GH if they prominently put it on their profile and/or own an "intended to be used/seen" public repo.
> And, if people lie on their resumes already, what makes me trust their GH?
Not a replacement for conversation! It's a way of indicating they can code without solving an arbitrary riddle in a high-pressure situation. If you're not convinced they wrote or understand the code you're looking at, ask them about it or ask them how they might change it slightly.
As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after. I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.
Sure - but you're not likely to really see the "real" thought process you're hiring for by asking a stranger a riddle you already know the ansewr to in a high-pressure situation.
Real problem-solving and thinking is done in a huge number of ways that sometimes isn't conducive to strangers, pressure, or whiteboarding.
> I'm interested in when candidates pick not-optimal choices for good reasons
Right - which is why starting with something they've written on GH (which is something they've thought about and are probably passionate about) is a great jumping-off point for such a convo.
> As an aside, the reason not to work on novel-to-you problems with job-seekers is that it's very hard to fairly compare candidates after.
I see your good-intention here, but it's nearly impossible to compare two candidates without all kinds of biases (implicit and explicit) coming into play.
> I strongly prefer pairing on the same problem with all the candidates in a batch. Otherwise it's hard to tell if a bad result is due to a bad problem or an unacceptable candidate.
I think this may be another way of trying to compare candidates to eachother (which is perilous).
Good candidates can do well with bad questions, and bad candidates can rarely do better than okay with good questions. There are lots of good/proven questions you haven't solved - ask your colleagues.
Unfortunately, the current common argument from the hiring side is that GitHub profiles are not sufficient proof of skill since code can be copied (not fair) and GitHub projects bias toward people with extra free time (reasonable, but not enough to discount GitHubs completely IMO)
Yes, some of the code may not be original, but unless the repo is a fork you can pretty easily see if the code is organized in a coherent way that shows the committer knew how to decompose a problem well. If they solved /every/ piece of the problem themselves, it may be a sign of a different problem (and also copy/pasting without citing source is also telling!)
On the other hand, fakers have caught on to the "GitHub is my resume" thing. I have had applicants who have basically fraudulent Github projects, or who have taken group projects on which they did basically nothing and claimed them as their own. So a Github page now requires an expert to evaluate it.
If its is their own code it shouldn't be a problem.
If it isn't their code and they can still talk you through it, even better - they have managed to understand code that someone else wrote which is probably an even more valuable skill.
And no, having somebody who's an energetic fraud on the team is poisonous. Having somebody who's so good at it that they're hard to catch is worse, not better.
I didn't write the monstrosity that I am working on just now, but I could explain how it works and I know where to look to fix bugs. I don't know why some crappy design decisions were made. Does that make me a worse programmer than if I had written it myself? Is harder to understand someone else's code than stuff you have written yourself. There are far more jobs working on existing code bases than on new new projects.
(My guess is that you have never worked with anyone who has claimed ownership of someone else's code, have you?)
Then misconstruing poor performance as coding ability.
if (~false == true) std::cout << "true"; else std::cout << "false";
In C++, what does this print? And if they answered correctly, I'd ask them to explain how/why. This question wasn't a deal breaker, but did immediately given an insight into their depth of knowledge of the language.
What does it all mean? It means exactly what it meant in a high school/college group assignments - one or two people carried the group project but everyone took credit.
I have seen hundreds of resumes where people claimed that they have done XYZ where through some side channels I know they just happened to be on that team but their contribution was limited to tweaking spelling.
I see coding tests as one of the two ways to evaluate that someone can code[1]. I trust it.
[1] The other way is that I know this person and I'm already aware what they can do.
I don't think the coding test isn't there because people think you're lying, it's there because we have no industry wide, respected entrance exam. Actuarial interviews don't (to my knowledge) contain a whiteboard vector calculus exam, but this isn't because people just sort of believe actuaries, it's because you have to pass a rigorous exam on these topics to become an actuary. I sometimes wish we had something like this in our field (not necessarily a legal requirement, just something that is widely recognized as legit). I'd be happy to put the time in and really study for a proper exam, but I'm not as interested in doing this over and over for companies that may administer and conduct these exams frivolously and in secret.
Also - I actually do agree that it's bad if someone can't write fizz buzz, but every interview exam I've taken has been vastly more difficult than fizz buzz. It's "find all subsets of a set of integers that is divisible by the sum of a different subset of integers". At a whiteboard, in 45 minutes. These aren't impossible problems, but they're much tougher than fizzbuzz.
I am saddened, angry, and relieved to hear of your problems with homework. The response you got back makes me realize that the two times I've done a homework assignment were probably pretty typical. I won't do this anymore, and I do accept that this will limit my career options. It does anger me, though, when the companies who do this complain about a shortage of engineers.
True story: I did an on line exam and take home homework assignment, waited over a month (crickets chirping) to hear back, pinged the recruiter politely now and then, and finally got a one liner "we've decided not to continue at this time.' A few weeks later, an article with came out with a picture of the CEO of this company standing next to President Obama, who nodded gravely as the CEO talked about the desperate shortage of software developers.
This comment is exactly why reading about "interview gymnastics" like this really pisses me off.
Its also why I wonder how many big tech companies are somehow able to hire so many people... With processes like these, you'd think that they either have a "secret backdoor" or never managed to actually hire more than a dozen or so.
Google has a completely broken interview process, to the point where they pretty much brag about how ridiculous their false negative rate is, but they make up for it on volume. When people will throw themselves at you two or three times in hope of getting that lucky set of algorithm wankery questions that they can answer, then you will keep interviewing like that.
If true, hiring based on luck seems broken to me. Like the joke of the hiring manager throwing away half the resumes and not hiring "unlucky" people.
With small companies, it often comes down to "were you charming enough?" They won't admit it, but it's a clear subconscious bias.
So you think the person with 30 years experience might be, whats the word... oh right. Lying. You think they are lying.
Quit trying to dress it up. Coding tests are exactly you saying you don't believe the experience written on the resume.
The problem is that it's kind of awful, and I personally really do believe that it's driving people away from the field.
Here's my take (I've posted this on HN a few times). Many people find in person, at the whiteboard exams quite stressful. This is fairly common, many people describe exams to be among the more stressful events in their lives.
Over time, I believe that institutions that conduct exams evolved a bill or rights between institution and applicant. Exams are used, but they are administered consistently and fairly, the topic and subject matter will not be a huge surprise (questions are kept secret of course, but their nature should be predictable). People who pass or fail will receive an answer, and often get a score and feedback to know how they did. The people who grade the exams are provided training to ensure they evaluate people fairly, consistently, and without bias, and are expert in their field.
Now, I know that universities, medical boards, bar exam reviewers, don't always live up to this, but it is the intended goal. I believe that our field, software, subjects people to exams repeatedly, but without any of the bill or rights I descried above.
For example, how do you grade? Are you qualified to assess general intelligence? Can you understand that someone might not be eager to submit to your general assessment of their intelligence?
Now, if you want to say nobody is entitled to a job, I certainly agree. But the industry seems to think it's entitled to workers, and they just seem utterly blind to how off putting their practices are. And in an industry with concerns about gender, racial, and age discrimination, double secret assessments of people's general intelligence by interviewers of unknown qualifications is about the worst thing you can do.
Interviews are always exams, whether it's writing code on a whiteboard or trying to figure out what the interviewer wants to hear about where you see yourself in 5 years.
Because people outside our field experience interviews in the second way more often, I think they don't fully understand what goes on in google style interviews. This is why I would call what we go through "Exam-style interviews", drawing a distinction between the two - even though I agree with you that they have elements in common.
In the same sense that verifying previous employment is saying you don't believe the resume.
I was involved in hundreds of tech interviews in the past several years. So many times in discussing a candidate's performance, I found some of the interviewers' questions and comments were unrealistic, even preposterous. In one case, an interviewer gave a hard dynamic programming question. We were a tech company and had very good engineers. Our products and our technologies, however, rarely need dynamic programming skills of this difficult level. I couldn't bear it. So I asked, "who think he can solve this problem on the whiteboard in 40 minutes right now?" Dead silence.
This. In fact there needs to be one exam, with subsections and subscores per subsection, along with an overall score.
Being able to solve an algorithmic challenge on a whiteboard does not mean that you can:
a) write readable and maintainable code
b) effectively communicate requirements to whoever is actually running your code in production
c) know about application-level security vulnerabilities like SQL injections and know not to mindlessly insert them into your code
d) instrument your code for metrics and logging in ways that are more or less standard and expected for production monitoring
e) engage in effective review of others' code
f) use typical API handling techniques which are production-ready, e.g. exponential backoff and circuit breakers.
All of which are testable in a certifiable way.
Simple truth of the matter is, the vast majority of companies that hire 10 developers who studied efficient algorithms for their interviews, are better served by hiring 9 engineers who are aware of how production and organizational realities affect their work, plus one "performance hacker" who may or may not have a master's degree in CS, whose job is to find the worst real-world production bottlenecks and replace the implementations with algorithmically more efficient implementations (plus stricter performance tests so that the more efficient code doesn't get ripped out later).
The idea is to assign low points to people who write a long function, and high points to people who write many small, self-documenting functions. Such an exam could also ask questions like "what is the cyclometric complexity of the following code?", which while not an indicator that the test taker will always write low-complexity code in a professional environment, at least indicates that the test taker is aware of maintainability metrics like cyclometric complexity - much more than can be said of programmers who mindlessly turn in 400 line functions with deeply nested conditionals.
I think that the google style data structures and algorithms exams are a good case in point. Think of these like the actuarial exam for linear algebra, vector calc, and numerical analysis. These exams don't of course test everything important about being an actuary. But they do establish competence in something that can be tested. As a result, actuaries don't (to my knowledge) have to do 5 hours of whiteboard exams doing LU matrix decomposition or finding a steepest descent vector. Whereas software developers have to find all matching subtrees in a binary tree over and over (and over).
What I like about the actuarial exams is that while they are rigorous, and it helps immensely to have majored in math or something closely related, you are free to decide how to prepare for these tests. Although I like the idea of a widely recognized entrance exam, I really don't like the idea of something like the law schools putting themselves (and 200k in debt) in between an individual and the right to take the exam.
I've attempted to gather data from colleagues around me but the data is limited. Posting online doesn't get much attention either. But I am trying to gather enough data to see if it would even be possible to create such an exam.
If a bunch of developers took a few minutes of their time to answer questions regarding what kinds of things should go into an exam and why (or heck, even a better teaching curriculum than what we have now) I think we could easily come up with something pretty awesome.
But, again, gathering that kind of attention and asking developers to provide you with insight is hard.
I'd love to tackle it if others were willing to help.
1) Ruby is hard to get a job in, so you are off to a rough start.
2) A lot of people with lots of experience actually can't code for crap. Do you know how many python developers I see that don't know the difference between a tuple and list? Like, how could you be a real dev if you never even wondered why sometimes you use [] and sometimes you use ()?
3) These tests and interviews aren't intended for you to get some certain score. Usually we make them way hard to find out what you do to handle that.
4) That said, you should know how to write code that isn't super slow and with a data model that isn't insane. You should also know how to articulate that, since as a Senior dev, you WILL be mentoring junior devs, and communication is not optional.
5) Every company's process is different because every company is different. Heck, my process is often different per applicant.
otherwise, just as you are faced with picking a rose from a faceless mass of candidates so are we faced with picking a decent place to work from a faceless mass of mission statements and "100%code coverage" blog posts (if we can find any)
And 2) yes I can believe it - that's what fizzbuzz and its ilk are for. The number of companies offering hackerrank/codility tests and justifying it as we only hire the very best has left the lake woebegone test way behind.
There has to be some middle ground - where someone can pass a basic capability test to weed out the crap without demanding several hours of coding. I mean I spent two evenings recently polishing up a "Oyster card system for TFL" as a hurdle for a government department I have been angling to get in for a year. A no-name corporations wanting CRUD development can take a running jump if it thinks my evenings come cheap.
(amazingly at the turn of the century I used to use "has listed Python on CV" as a marker of "worth an interview" - it was rare enough and indicated an interest outside of corporate mainstream. Maybe Erlang today??)
Edit:
So my compromise suggestion is for companies to say "We have an OSS project (or even recommend one of the bigger ones). Take any of these 5 bugs and supply a pull-request"
At least then the evenings work is not totally wasted and you get to see an important skill - how fast can they come up to speed on an unfamiliar codebase?
The only times we use coding tests, we use Hackerrank to administer them. That way you have a distinct time limit (we give an hour, which is honestly way too long) so you don't spend all weekend one something that doesn't matter.
I definitely agree about the difficulty of picking a place to work. We reserve half of our final interview (and part of our initial interview) to be a Q&A for the candidate to interview us.
At a certain point "can code" stops being "can write perfromant algorithms" and starts being "can work without direction, can be placed in front of users without fear, can defend their decisions, is not an asshat."
Ten minutes on a shared screen and we can find out if you pass fizzbuzz, can make a rational stab at an algorithm question. After that it's mostly cultural fit.
You cannot automate a test for "is not an asshat" so we get more and more people proving they can get 99% on programming tests when programming tests are 5% of the job.
In particular, if you don't know the codebase, you're going to be guessing on places to look. If you're lucky and guess right, you may spot it right away. If you guess wrong, you could spend a lot of time diving around irrelevant details. There is some skill in guessing well and not spending too much time on things that don't give any progress, but there's still a lot of luck too. Because of all that, it doesn't seem like a good idea to assign a bug that you haven't already essentially fixed.
I agree, but this should be a clear point. You shouldn't be overengineering something unless you really have to.
Huh? Enterprise level companies are desperate for Ruby engineers to maintain large Rails apps and there still is a good amount of startups doing new work with it.
What substantive evidence do you have of this shift?
No thanks.
Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical records and the app that I came into had tons of dead code paths that leaked HIPAA-regulated data all over the place.
None of the API routes were 100% functional, so I spent my first few weeks cleaning that up and making it bulletproof. Then I fixed their broken homebrewed SAML IdP. None of that work that I did was appreciated as they only wanted (but wouldn't say that they wanted) new frontend features to show off to the client to inflate the quality of their work.
More importantly, they were using Rails4, but implemented everything by watching a Rails2-era Railscast and would get frustrated with me for not doing the same, a.k.a "the rails way" (I was, just modern Rails and not their broken bullshit). And that was the CTO...
Very well said and it happens in lots of areas where companies seem to wish for "big outcomes but all for free".
You will see this in security all the time.
"We have to make sure this thing is bullet proof."
"Ok it's going to take a month to harden and audit our the network and infrastructure and add monitoring and we'll be in good shape."
"Uhh ... no we didn't quite mean it like that ... can't you like install a plugin in half an hour that does the same thing?"
(made up conversation but you get the point)
Well yeah, churn and burn is my company's motto. At least we pay well.
Our organizational structure isn't immutable, it just moves slowly. After about a year, my team's effort resulted in measurable improvements for both revenue and end-user experience.
If you're senior dev level and want more of a challenge that's not just throwing more code at the wall, these sorts of scenarios are something to seek out.
When I say "not willing to make organizational commitments..." I specifically mean they don't give you access to people -- stakeholders don't want to be bothered by the devs. It's far too common.
What you're describing though is a great situation -- I love those engagements.
It's weird how prevalent the idea that communication _is_ optional in this industry. Headphones-on, heads-down engineering teams are to be avoided (by me).
Why do you say this?
i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and doesn't know the difference between an ArrayList or a LinkedList.
i understand not knowing nuances of the language (in python, understanding how __slots__ work and how to make usage of it), but not knowing a core feature?
I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.
I say this after having done an M.Sc. in Distributed Systems focused on performance analysis. In a lot of cases that I've encountered, mastery of data structures and choosing languages and runtimes appropriately can completely eliminate the need for a distributed system, or significantly reduce the complexity (an efficient 3-node system is much less complex to manage than a 100-node inefficient system).
A recent example that comes to mind is a pair of similar systems, one written in Java and one written in Go. There was an approximately 80x larger memory footprint for the Java system while having similar functionality. Plus the Java system took about 2 minutes to start up (yay Spring), vs. sub-second startup for the Go binary.
I fully appreciate the high level design of systems, and these days that's what I spend a lot of my time doing, but when shit hits the fan and the implementation of the system doesn't perform the way I'd expect it to, it's time to roll up my sleeves and get down in the weeds to help solve whatever is keeping the system from reaching its full potential. Maybe that means there was a flaw in the design, but often it's just a shoddy implementation (with Pareto 80/20 fixes to make it better)
If your company hires based on a technical interview that everyone says is not representative of the work that is done, you are not hiring right.
I get there is demand to maintain Ruby/Rails apps today... but how many are hiring for new RoR projects?
Seems there was a bout of "RoR and ActiveRecord Don't Scale" articles a few years ago... then suddenly the new cool frameworks became Angular and React.
If anything I feel that things have gotten better, although this may be a difference between my former enterprise Windows-stack life vs. open source tech life. The main differences I see are:
- Take homes are more prevalent... but I recall only one which has taken more than a half day, and that was fair as I was relatively new to Rails at the time. I actually like doing these for jobs I'm interested in as they give me an opportunity to flex my skills.
- There's about a 50% chance that you get a CTCI type interview vs. a more pragmatic, what-you-experience-on-the-job type domain modeling, write out in code in Rails (or whatever framework being used) type of pairing. When I'm on the hiring side I focus on the latter and feel it's quite effective. When I was starting out you almost always got the CTCI type.
I typically red-flag potential employers who don't sufficiently validate the skillset of potential hires. I've worked with plenty of people who were terrible, it's one of the reasons I transitioned to Rails.
I'm beginning to take this to heart.
I sometimes ask if the rest of the team have taken this test (I was once told I was the first, and I'm the replacement)
If so, what are your thoughts on why that may be?
Basically they just care more about doing good work. I must underscore though that my impressions are tempered by the fact that I primarily worked in enterprisey Windows-stack jobs, but that's also more typical - you're not going to find many modern startups going w/ .NET or Java. The tools themselves aren't really the problem, it's the implied culture.
Why is this? Probably because of the goals of each. .NET and Java were an outpouring of efforts from the 90s to harness issues of scale on enterprise systems. It's a pre vs. post information age phenomena, open source folks are going to be more of a hobbyist mindset.
During the last few years doing Windows-stack work I was a top performer at the company I was working with, had gotten two relatively recent promotions, turned down an op going into management, and was so unhappy that I considered leaving software altogether. Transitioning to open source stack work 'lifted the cloud' - so to speak - and reinvigorated my love of programming.
Is it just our industry where you have to prove you aren't a complete impostor every time? Basically we treat every applicant like they are Frank Abagnale [0].
A senior role should be focused on more overall system and performance aspects of the software, using good practices.
What does writing out a solution for fizzbuzz (or equivalent) prove during an interview? If they do it easily do you suspect they memorized it (our base assumption seems to be they are an impostor right)? If they fail, do they fail the interview?
In the real world if you had a database call in some recursive loop that would be bad for performance. The number of times I jump to using recursion in a solution is near zero.
The problem is that a large majority of candidates lie on their resumes. This means that hiring managers have to work harder to qualify a good candidate -- which often ends up turning into a process that hurts and annoys those that are actually qualified.
a large majority of candidates lie on their resumes
The key is to only stretch it to the extent that you can explain your background in detail to the hiring manager and be able to openly admit where you don't know much if those areas come up. Generally speaking a hiring manager you actually want to work for understands that experience is heavily dependent on what your last role needed, and skills can be picked up as long as you have enough of the bare minimum covered.
Anyone with basic coding chops should be able to solve it; it would be equivalent to a CS101 quiz.
It is still shocking how many people fail it. Yes, we have to test for it. My wife is in digital marketing, her -boss-, who insists on being involved in every decision, and will override her knowledgeable subordinates based on her own feelings, knows nothing about digital marketing (and is the reason my wife is looking to change jobs), but nevertheless managed to impress people above her (who also know nothing about digital marketing, but to be fair, don't have marketing related titles or roles) with her resume. Imposters in jobs are super common; it's just that in development we have easy ways to check for basic understanding. Unfortunately we try to scale those up to look for expert level understanding, and that fails (because we're really bad at testing for expert level understanding in areas we actually care about. That 'implement a red black tree' is probably appropriate if your company builds a data structure library as part of their core product, and probably inappropriate for almost anything else).
Have you considered that:
1. People have imposter syndrome, all the time. They're stressed out about being able to code, when running up against code interviews having nothing to do with the actual job they're doing. 2. People have anxiety, and they know how tough code interviews can be. They crammed and crammed and crammed, and 10 years of coding is now all this big amorphous blob in their heads. They're ready for some big systems questions. 3. People have bad days. The environment might suck. Their dog just died. You're a very adversarial interviewer, and they only work well and creatively when someone isn't going to come in and bully them about the response (or maybe they just imagine this)
Of course, you have no way of knowing this as an interviewer. But FFS, we need a way to inject some fucking empathy into this process. I'd say 99% of the time people aren't in interviews demonstrating what they know or can do, they're being asked to demonstrate what somebody else thinks INDICATES they have things that they know or can do.
I know the response to this is going to be, well yeah, but its Fizzbuzz! And I'd like to ask those people if there's ever been a point in your life that you wouldn't be able to write Fizzbuzz. To dramatize for effect, if someone came up to you and said they have access to your bank account, and for them to not take every bit of money you've made over the past year, including the money for your daughter's braces or something important, and in order to get it back you needed to make as concise and clean as possible an implementation of his variation on Fizzbuzz, you will not be thinking just of Fizzbuzz. Your brain is going to be churning at 1000 miles a minute, and you'll be trying to pull out every trick you know (out of hundreds) to get it as concise as possible, while thinking to yourself this is my future on the line.
Thats how I feel in interviews at least. I've always passed Fizzbuzz tests, but I've crashed and burned in interviews due to any of the above popping up on interview day. If we all could have a bit more humanity and understanding hiring would go a lot better.
You just negated your entire point there.
Yeah, you can have a bad day. I get it. We all fail interviews; I certainly have. Some I feel we really weren't a match (they were looking for a kind of developer that I wasn't, and don't want, to be), others I felt were unfair (for instance, interviewing with Microsoft years back, I had a C/C++ interviewer asking me questions that I had been told I was allowed to write in Java, and then disbelieving me when I told him (String).length is constant time so it didn't affect the Big O complexity that I had 'for (int i=0;i<(String).length;i++)', and clearly mentally checking out at that point). Obviously I don't feel any were because I wasn't, legitimately, good enough, but I also recognize I am very biased. But the thing is I also am in a place where I don't need an interview to justify my confidence at this point. I know I can deliver value. But I also know I will never convince the Googles of the world that I can, because I am neither a researcher of note, nor am I going to jump through the hoops of prepping for weeks on end for an interview; I have a wife, hobbies, and other, better ways to spend my time (even typing comments on HN! :P)
We first give people a take home. It's at their own convenience, we tell them it will be an hour and a half, coding, simple questions, to do it at a time they're comfortable. We don't stay on the phone, we tell them to use whatever resources they want (except, obviously, please don't try and google for the answers directly, or get help from others; it's simple enough that those who have tried to cheat have ended up with it being hilariously obvious, like leaving source comments that said it was by someone else, or variables for 'cat' when we never asked for anything related to cats, or being caught out during the whiteboard).
The interview is mostly a conversation. It starts with conversation. We talk about the position, the company. We ask about what the candidate is looking for, their resume, that sort of thing. Only after thirty minutes or so do we get to anything technical. We ask a few questions, and they're intended to be placeholders for conversation; plenty of right answers, we mostly want to see that the person is knowledgeable enough to discuss things. Even when we get to questions that have a right answer, it's mostly to gauge knowledge, and for the more complicated, even if a person gets it wrong, we'll tell them what the right answer is, and then ask them for a rational as to why. If they can figure out the rational, that's just as good as having known in the first place. Then we have a whiteboard question. It, too, is not hard. We tell the candidate "If you think there's a library function that will help, but you just don't remember it, you'd need to Google it, that sort of thing, talk it out with us, we'll give it to you". We try to help suggest things to get candidates unstuck. Etc.
Really, it's -not- a particularly antagonistic process. We really, really do want people to succeed (because, frankly, we want the position filled so we can stop interviewing and go back to work). So, yeah, if the interviewer doesn't manage the trivial coding tasks...we're going to pass. We -aren't- saying "this person is a bad developer", we -are- saying "this person could not demonstrate that they passed the bar of our interview process".
But there have also been some who have flat out said, even on the take home "I can't do this". Or those who have admitted when faced with the whiteboard question that they don't know how; that the take home had been done by someone else. Etc. Given those situations, yeah, our candidates are being given a take home, and a whiteboard.
For a senior role:
1. Someone who can't write and debug a for-loop and an if-statement isn't going to be able to provide training and support to junior level hires. At all.
2. Making high-level changes and performance improvement both require good process discipline, and the ability to write a lot of code to actually accomplish it.
I think there are high value software management tactics that can be implemented without knowing how to code, for example, change control, or enforcing limits on work in progress via. kanban, but for a role that has either "software" or "developer" I think fizzbuzz is a very low bar.
I personally like binary search as in interview question. The basic principle is simple, but there are enough edge cases and variations to make it interesting.
"Find all the subsets in a set that add up to sum" -- "Okay for this we will use the sliding window technique and here is how it is done" -- WTF is this. I get that they want to see problem-solving skills, but this is on a different level requiring the interviewee to have studied and knowledge of the technique, otherwise we are basically trying to develop efficient algorithms from scratch and in little time. --This makes sense for college interviewees who have only studied the past 4 years, but for a professional with experience why is this adequate??
I kinda agree with you that it doesn't make sense much of the time if you have to specifically prepare for the coding interview; stuff you may never use in your job. But its not a lot of stuff: I bit the bullet and spent some time solving those questions and now can make past mostly any screen.
Its really not that hard, especially if you have a CS degree. Probably would take 1 week of dedicated effort to get better at it.
It sounds to me like a way to weed out pesky applicants who have families or who are simply older.
People usually trust their own assessment of a candidate much more than that of others. While your projects might help generate interest in you and get you an interview, the actual interview process is meant to be an assessment by the Company conducting the interview. So you shouldn't automatically assume you have the jobs simply based on your past projects alone. I'm not saying I necessarily agree with how this works; I am simply pointing out why it works that way.
> It sounds to me like a way to weed out pesky applicants who have families or who are simply older.
Perhaps. It seems unlikely since many of the senior developers/hiring managers at most mature companies are older and have families.
That's insane. If you brought me in because you liked what's on my resume, your number one priority should be determining if I really did what I said I did. Your priority shouldn't be arbitrary, unrelated questions or coding challenges pulled off some website.
I'm not aware of any other industry that behaves like this.
There generally is a component where you're asked about your past projects in detail. Its just not the only component.
The last time I had a proper algorithmic problem, I was in an academic institute and we had a guy researching algorithms so I asked him (though he didn't come up with mush). It was basically a variation the stable roommates problem. I came up with a solution - brute force plus a load of optimization and it worked well enough for the purpose.
When I get that crap in interviews some of the time I get the answer, some of the time I don't. Its pot luck. Its says very little about my skill for the jobs I am applying for. Ironically I was way better at answering those things 15 years ago when I was fairly crap at building reliable robust systems.
The success resulted from deep research and much trial & error. It was no magical "algorithmic skillset" that they expect in those type of interviews (I wonder if those are even a good filter for actual production algos).
Here is my simple write-up of SRP: https://medium.com/@rambossa/stable-matching-algorithm-and-h...
Think about it: how can companies be this picky if there really is a STEM shortage?
On a sidenote: I recently understood why meetups, events and networking is important: to interact as little as possible with HR.
I've recently a particularly bad experience where the HR person called me very early in the morning (without asking if it's a good time to talk) and then proceed with a third-degree interrogatory with all kind of questions, even reaching the point to interrupt me while I was articulating/motivating my answer in order to make another question.
That was so rude I got very angry after that call. That is not the way to handle a phone interview, that is not the way to handle a conversation of any kind.
Honestly I think it's because mediocre engineers are more trouble than they're worth. We're collectively not good enough at building software to adopt a "warm body" approach.
It's just weird to me that people go job hunting by "cold-calling" some random job advertisement where they don't know the company or anyone that works there. If I were hiring people, I'd go for people I personally have worked with, or been recommended by someone that I work with, waaaaay before hiring some random person that showed up at an interview.
In my situation I moved to a new city for family reasons with zero connections. I had a stable job working remote but put some feelers out and found a better job in my city by randomly applying.
It's actually weird you find it weird.
Question 1: What's the interview process look like?
Anything other than 1 hour phone / in person interview would get rejected.
I'd like to propose an alternative job hunt:
(1) Start thinking about your next move before you need a job.
(2) Send an email or DM to someone at a company you like, ask to buy them coffee/beer, and make it clear you don't want anything from them. Ask them questions -- or even better try to do them a favor... promote a side project, make a connection, etc.
(3) When you're ready to make a move, reach out again to all the people you've met and ask if they're hiring. Most people are happy to forward a resume -- especially because so many companies now offer referral bonuses. It's a win-win.
(4) KEEP MAINTAINING THESE CONNECTIONS EVEN AFTER YOU GET THE JOB!
I haven't heard of that happening too much, at least in the Bay Area.
Even the tech celebrities have to go through the process half the time too. You will get a referral bonus although if your friends pass the process although.
This is mostly done to prevent cliques who let in bad performers.
B: How do you know?
A: They can't pass our test.
B: How do you know it works?
A: Because if they could code, they'd pass. Sometimes they pass, and even some of those can't code.
B: So nobody can pass your test.
A: That's right.
B: And even if they do, it doesn't mean they're good.
A: Yep.
B: It sounds like you've got neither recall nor precision. Don't you think the test could be wrong?
A: Nope! Everyone just sucks.
I do think this attitude genuinely limits many startups. Software engineers will always be the first to take up hobbies like fixing old motorcycles or building a house from scratch, yet they view mediocre engineers as things that can't be fixed up in the same way.
A mediocre engineer is actually a really good bargain. Obviously a great engineer who doesn't know it is ideal but I'd toss them in with the mediocre engineers for that reason.
If you are looking for rare positives, you’d use F1 score ;-)
Anybody should be able to do that. It's not a bad test, especially because of how well documented it is.
I agree there are terrible tests (why on earth would you have someone implement a search or sort? that's like rolling your own crypto, don't do it, don't bother learning how to do it unless it's your passion), but at the very least a simple programming test can indicate that the person can sit down at a fresh debian/windows/OSX install, and knows enough about their given language to be editing, compiling, and running code. This isn't even deploying, just able to have a functional dev environment and be able to create software.
A lot of compsci kids come out of school having worked in specialize VMs or only doing matlab stuff or, well, I don't know what they're getting up to over there but they aren't quite sure what the magic invocations are to get their Java thing running (do I need eclipse? err....) or C (how do I compile...?) or even sometimes Javascript stuff (how come it doesn't work when I double-click the html file?).
A simple fizzbuzz is a great filter for this sort of thing.
I've failed a FizzBuzz.
While failing interviews is basically my superpower, I think my git repositories, college graders, previous and subsequent employers, coworkers and clients might be somewhat shocked to learn that all that code was written by a guy who "couldn't code" at all.
(The autograders and CI accepting all that non-code must have been exceptionally buggy.)
But still, I failed the test. I told a friend who'd had the slot a couple hours after mine; she thought I was joking. It's FizzBuzz!
I'd seen it before. I knew what it was. The guy had changed the strings and added a factor, but who cares. I could write it in my sleep.
Just not in the form of a puddle of goo, which is pretty much the form I took in this interview. My functional IQ was roughly on par with that of my socks.
I could tell you why it happened, but it doesn't really matter. Now that interviewer had a story of the time a guy with FAANG on his resume (whose name alone had gotten me the interview) was totally incompetent.
These comments are full of those stories, mostly being used to show the test is fine and everybody sucks.
The claim is often made that anybody who can code should easily pass some particular test: P -> Q. I'm offering a story of P & ~Q, which means FizzBuzz isn't really doing what it's claimed to. There's a ton of subtlety I've sidestepped and a lot more I could say, but I don't really have the time.
(I didn't downvote you.)
You test their skill of solving trivial problems in 10 minutes under pressure. I can accept if people defend that as the best proxy measure they have for the amount of effort they want to invest into each candidate. But do you seriously believe that this proxy filters the good senior devs from the bad ones?
I mean, some do, and those are indeed better passing the GP. But most don't.
Do people typically come in to work at 11? Why do you schedule interviews at 9 AM?
Do people typically have time to think about problems on their own for a bit and start writing up a solution after they understand it? Why don't interviewees?
One theory I have is that HR depts are pushing back against the upward trend of developer salaries; if they create an onerous process that tries to make candidates feel inadequate, it might make it more likely that they can land a low ball offer with whoever is desperate enough to stick it out. Also, if the HR department itself is incompetent and not capable of attracting talent, they can always point to their tests etc to "prove" that there are just no qualified candidates in the workforce.
Also, what is with all the coding tests etc? That stuff is obviously useless. Why don't hiring managers just ask candidates to read some code that is similar to what they will be working on, and observe how they approach stepping through it and how quick they can understand it? That is far more similar to what real work looks like most of the time.
I relate though, although I'm in Seattle area, which is a great place - I interview really badly. I strongly agree that hoops are getting added.
However, I have found that great companies do compete on hiring process. Microsoft remains the Gold Standard for me in how fast they turnaround their hiring when it gets going.
> The job search takes much, much longer than it used to.
No. I'm picky and I don't practice stupid questions. It's always taken a long time for me. If you hit the right company and have the right skills, it'll be under two weeks for a hire though.
> No one believes that anyone can actually code.
Yes.
> Coding Tests Can Trip Up Even Good Engineers
Yep. Probably 10% of the time I have a "frick, I blanked" moment.
> Extensive homework is now normal.
Nope. Find better companies?
> Every company’s “process” is different
Every company believes they are snowflakes.
> Outsourced hiring “services” are very much in vogue
Yes, but I think this relates to competitive hiring spaces with lots of poor candidates.
> Companies Really Want to Know Your Salary; Don’t tell Them
Sigh.
> Interviews Matter Much, Much More to You Than to the Company
Yep.
> Age discrimination really exists.
I'm definitely not looking as young as I used to and it worries me.
> You’ll never really know why you weren’t hired.
That's because they don't want to be sued.
>That's because they don't want to be sued.
Because it takes far too much time to tell everyone who isn't hired than the few who are.
And yet...on average, companies are "average"
I recently took the first one ever in my career (in my late fifties). People tell me they think I'm an excellent programmer, but I did awfully bad. Why?
- it was my first time
- in daily life I switch between many languages, devops, meetings, and research. It always takes me some time to ramp up, especially on syntax: coming from Elixir, switching to Javascript: how does JS access object members again? I usually need an hour or two to get up to speed again.
- the tasks are very much outside the normal realm. If in real life I need to map some multi-dimension array, I first look for libraries and such, and if not, approach this as writing a library function: take my time to do it well.
Even though I could rationally understand the reasoning, it still felt demeaning, given my resume. Also, because I underperformed, it's easy for them to jump to the wrong conclusions.
Ask me about your current problems, problems the person filling the position would need to have opinions about. If nothing else, maybe I could crack a tough issue for you that would have material value.
I've given FizzBuzz, and I've done FizzBuzz. It's hard to do it/get it and not feel like there's some degree of insult involved.
Exactly! And people still get it wrong.
It's a low-pass filter to weed out programmers who can't even do FizzBuzz, because despite their lack of coding prowess their résumé will still look similar to yours.
> and not feel like there's some degree of insult involved.
That's just reading far too much in to it.
Try to remember, this is the country where a range check function resulted in a lawsuit:
private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");
if (fromIndex < 0)
throw new ArrayIndexOutOfBoundsException(fromIndex);
if (toIndex > arrayLen)
throw new ArrayIndexOutOfBoundsException(toIndex);
}Anyway, it is just the first question and we are usually past it in five minutes. Then we discuss, in general terms, the types of problems we are solving and the related computer science topics.
It certainly isn't meant to insult. I hope I haven't insulted anyone and, if I have, they've never made it known to me. I will say that it'd be a huge red flag to me if a candidate acted like this was beneath them. The reality is that, while we will be solving some cool and hard problems, there will be lots of problems that are beneath us, too.
You literally have a data point with way more than the typical 4~8 hours a throwaway homework would take, and don't use it as an a) talking point, b) nice way to sidestep wasting more time?
Argh.
Unlike declaring race or veteran status, admitting past or present disability can only hurt your chances at getting an offer. Some employers may appreciate the honesty, most of them will automatically and quietly hold it against you at every step of the hiring process.
And they'll get away with it. Easily. The laws "protecting" disabled candidates are essentially toothless, since "illegal" reasons for rejection are often not written down or, at least, hidden from you and the goverment's.
[1] https://www.monster.com/career-advice/article/disclose-disab... [2] https://medium.com/@mshannabrooks/this-is-the-lie-i-tell-on-...
Then again, maybe it's different in the UK here compared to the US as well.
"Just" a few hours has always, always been an underestimation when I've tried these. I've been burned a handful of times now; both from my time and from my belief that it would amount to something. I'm reminded of one instance where follow up emails kept coming after submission: "Add in this now." "Okay, now this." "Handle this." I consider myself an average engineer. I'm not interested in increasing my sample size to try and average out variance any longer.
I'm looking outside to one of the first sunny, warm days we've had here in months. I can't think of anything more I'd rather not do than some arbitrary company hiring project. I simply pass on these now and politely pull out from consideration.
Yep. If you're gonna throw crap at me like that NOW ...it's only going to get worse LATER
When I was hiring Senior engineers for Computer Vision and 3D rendering jobs my process was thus:
1. Post job and simultaneously search for engineers we thought were a good fit technically
2. Reach out to people I thought were qualified based on their specific previous work that was related to the job I was hiring for
3. Review submitted applications for relevant experience
4. If we thought it was a technical fit, we would do a <30 minute team phone call with some basic work history questions, description of role/salary and work logistics (remote, dev environment etc...)
5. If we were satisfied with that, send them a <10 hour total, paid, production project at an agreed upon hourly rate. If the candidate didn't have the required IDE etc...it would basically be pair programming
6. Review code, speed and communication
7. Send a hire/no hire decision immediately
From first contact through Steps 4-7 it would ideally take less than a week, depending on the candidate's schedule.
We were only burned on this process twice.
Once the guy kept trying to negotiate salary up over two weeks so that he could get a higher price somewhere else.
The second time, the guy did well with initial production, but over time he ended up using local college interns to write his code, who got other jobs and his commit speed fell off of a cliff.
Since we are a remote team, trust was paramount, and we trusted quickly by default. Nobody ever had complaints about the hiring process and we had a higher than average success rate for hiring fantastic developers and getting quality code into production quickly.
We never asked current salary because it wasn't relevant. I knew what I could pay and that's what was offered. If they asked for more and were worth it, then I would try and find money to make it happen, but generally it wasn't an option.
I would do it the same in the future.
Sounds like you should have moved him to management.
Thank you!
Some honesty and forthrightness for a change.
(It's something I put in a blog post (https://antipaucity.com/2013/03/25/what-to-offer-to-be-the-b...) 5+ years ago ...yet have only seen done once in my career)
I suspect it is the difference between "coding ability" and "coding fluency." In the former a candidate can apply known patterns of a give language to a problem and with just a few searches on StackOverflow get it working. A person who has code fluency can create the algorithm in the language of your choice, pretty much on the spot.
In the music world you meet people who can play a song on the keyboard that is note perfect, but they can't transpose it into a different key. Its the difference between playing the keyboard and using the keyboard to express a musical concept.
Can you speak a language if all you have done is memorize an extensive phrase book? Yes, are you fluent? No.
The number of candidates who really understand the nature of coding and so they can quickly adapt to any idiomatic language is still quite small in my experience.
I've professionally used each for a year or more C#, Python, Javascript, Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But if you asked me to write a function in anything but the first three languages, I will almost undoubtedly stumble a bit in producing them (hell, I still have to look up syntax for Python periodically).
That doesn't mean I couldn't pick them back up in a future job very quickly again (each job I worked for I was usually contributing to their code base in a few days, never longer than a week), it just means I don't have them fresh in my head and I can't store absolutely everything in my head forever.
But you'd still probably think I was incompetent. I've certainly given that impression before when I had an onsite scheduled by a recruiter and given less than 24 hours notice for an Objective-C job, a language I hadn't touched or thought about in over a year, and was handed a laptop by a Junior Programmer and was told "Code up an app for me." while another interviewer sat quietly across the table from me and stared at me the whole time while I refreshed on a years worth of XCode changes and forgotten syntax in real time.
After that wonderful performance they didn't give much weight to the two employees in their department that worked under me at a previous startup I was Lead Programmer for and vouched for my skills.
It is for exactly this reason that if I'm interviewing you and want to know if you can code or not I will ask you to write up an algorithm rather than a program. I might say, "Show me the algorithm for locating a node in a binary tree, now do the same for a hash table. Now how would you insert into each of those?" And then, as many programming languages do, I try to tie one of your hands behind your back, "Ok so the language you're going to use doesn't have pointers" or "memory allocation" etc.
But I only interview that way because I see computer programming languages as an impediment to expressing what you really want the computer to do. And people who can code, first and foremost understand exactly what needs to be true for the code to work, then when they run into limitations of the language figure out ways to express those same concepts given the limitations.
If you were being mean you could add limitation after limitation until you were down to a minimally touring complete system. And if they can still make it do what you're asking, then they really deeply understand how to get computers to do what ever they want them to do.
I agree with every criticism that "coding tests" should not be about whether or not your syntax is accurate or you have the standard library memorized. I explained to a colleague at Google once that having total mastery of English grammar doesn't make you a writer.
I wouldn't think you incompetent if you didn't have the syntax at your fingertips.
But here is the rub, if the interviewer doesn't know how to code they can't reliably test for that ability in others. When I hear or read stories like yours I wonder about who the company has put in charge of interviewing these candidates and what biases are they bringing to the situation.
I've been hiring recently for a senior developer and I have had a dozen or more candidates not be able to explain composition and inheritance or the differences between an Object Oriented or Functional language. One person started describing how to define functions and another couldn't really explain inheritance.
For my company, candidates lying on their resume is our experience. A number of people ARE lying on their resume. we've front-loaded a lot of the "we don't trust your resume" in to the screening process and the first 30-minute screen because so many people list the dogs breakfast on their resume, but really can't do those things. I think a lot of times, someone else on the project team may have hacked on that type of thing and so they list it on their resume. There aren't a lot of good answers -- besides validating those skillsets -- since people can list anything that they want on their resume. I would love for someone to have an accreditation or certification program that was widely used so that we could know someone could do the work and most importantly do the work well since the implementation and the patterns they will be choosing will be with our company for years to come.
I'm trying to get opinions from developers (myself being one) on what kinds of things that kind of program would have to include. I'd love to hear some ideas if you have any.
Maybe I'll make a 'fair coding interview'. The candidate and interviewer get a random coding problem they must solve together. We'll see how the candidate and interviewer feel about each other after the shared trauma.
Last twice I've looked for a developer job, I got offered a position and was hired within 2 weeks.
> No one believes that anyone can actually code.
Quite rightly, most devs can't code.
> Extensive homework is now normal. Not been my experience, I've done some homework assignments but none were ever more than 1 hours work (and then even the standard of the tests were so low they were really 15 mins work..)
> You’ll never really know why you weren’t hired.
This bothers me too.
> Outsourced hiring “services” are very much in vogue
I hate this. Almost all recruiting I see is done via recruiters who are at best case flakey and worst case self serving liars who will try to pressure you into going to interviews you don't want to go and to take job offers you don't want to take. Sometimes flat out lying to you about the role only for you to find out at the interview. I had one interview that I went to expecting it to be C#, the interview was all Javascript (which I don't do at all). Or the recruiter will tell you that you have to decide right now this minute, when you don't.
I had one job offer where the recruiter said you've been offered the job but you have to tell them now if you are accepting it. It was funny how after telling the recruiter that I want to think about it over the weekend and if that's not an option than I would like to decline the offer, well now all of a sudden the company were completely willing to let me think over it for a couple of days...
I hate recruiters.
He even gave me interview tips/advice on a per-company basis and helped me rewrite my resumé for each company he wanted me to interview with. Honestly, it was fantastic.
His resume is the problem. Two immediate things: (1) His most recent job lists junior level work and (2) He is claiming 3 concurrent jobs over the last two years.
This shouldn't matter, chiefly because he has other work listed, so stopping at the first job post and forming an opinion makes the reader the problem. But also because people can sometimes take an easier job if they have life issues.
Secondly, these are consultancy gigs + 1 full time gig (or maybe it's part time) that could have a low hours/week commitment. He wouldn't be the first dev ever to moonlight.
Even if it were junior level work (trusting auth to be done correctly with junior engineers? LOL), he probably completed it faster than a junior engineer would.
His resume doesn't say he did auth. He used an open source library and made unspecified modifications to it. That's definitely something a junior level Dev could do.
"Or maybe it's part time". Exactly. A resume should give answers, not raise questions.
Expecting people to be charitable while reading resumes is unrealistic. A resume has to quickly demonstrate the applicants qualifications other wise it's trashed.
What bothers me most is that employers don't seem to be showing equal commitment to the interviewing process. They will ask you to do hours worth of homework for them, but then can't be arsed to discuss it with you for five minutes. They will ask for your salary history, but clam up if you ask them what they pay other developers in the same position. They will take your application as a senior developer, then ask if you'd consider being an entry-level tester. They spend hours grilling you to prove your worth, then spend zero minutes trying to sell you on their company.
To simply give feedback is not a big deal to HR, and since they're making you do hours of homework it should be legally required to answer if you ask for feedback.
This has been my experience with homework assignment interviews (Though I still prefer them to whiteboards).
In no cases, has any interviewer reviewed my homework before the interview. So the homework critique/qa sessions end up being more like a presentation or walkthrough of your solution, like a presentation for a meet-up, even though they are often described as more of a code review/interrogation about your choices.
Which I don't mind honestly. If you know that going in, and are prepared - its an opportunity to impress, if you can be polished.
Talk at them about your solution for the allotted time or until they make you stop :P
They don't care. Never have, never will.
It's a one-way street, any "give" that there is, is out of self interest and necessity.
Region matters too. I don't doubt in Silicon Valley it's trivial to pull this off, but in Chicago I've seen most companies have a 2 month+ hiring process, if they ever hire anyone at all. I've even heard from recruiters that this is common for those companies. And then there's a lot, lot less companies out here to choose from, especially if your tech stack experience doesn't match. I've literally had company HR chastise me for not learning their specific language, even though I don't list it on my LinkedIn and the message was unsolicited.
I am like the flower of lotus - waiting. When there is anything interesting I can jump ships using requiter network to help with the interview. After my first job, I never had the need to search personally.
For my last job search, I emailed applications to like a dozen companies in my area from the last HN Hiring thread, and heard back from like 2 I think, none of which went anywhere. Maybe they're too slow, didn't like me for some reason, found someone better, etc, I don't know. When I started talking to recruiters, the interviews started coming pretty fast, and I had multiple on-sites and offers in a couple of weeks. It's like, sleazy though they can be, there's a distinct lack of movement in the process without the energy of recruiters.
So I come down more on work with them, but don't trust them too much, know their tricks and watch your back.
And speaking of the author's points - a week-long coding test? A month to complete the "homework project"? Who's doing that? Nope, I'm passing on those companies. A couple of hours is no problem, but pay me if you expect multiple weeks worth of work.
This post is a great report and a must read of all engineers.
One interview was for a Java Spring position, advice says study! But study what? I studied spring but interview was dozens of database questions instead. Could be CS, lang, framework, db, metrics, platform, OS level. No one knows all of these subjects completely.
Companies are so skittish that I recently could only get a two-week trial at low pay after crushing a call/homework. Hopefully they won’t be offended when I show up without sockhat and beard. :p
One of the problems IMO is that HR doesn’t know shit about tech, and dev managers don’t know shit about HR. A dev manager who needs a person tells HR “I want to interview 10 people for this open job req” — which is likely just some bullets vaguely describing job responsibilities.
HR, having very little idea what any of the bullets on the list mean, do their best to filter resumes. Because they’ve had to do this a lot in the past, they engaged an outside firm to issue coding tests to make sure they don’t pass on shitty candidates to the dev manager (they got dinged last year on their review for that!)
So hence all the bullshit before you even get to the guy who posted the job. Part of the problem is that the dev manager just expects to be able to throw this over the fence to HR.
One way I’ve solved this in my teams? I don’t expect HR to do resume screens. Sure, I have them do a basic screen for candidates who don’t even mention development anywhere on their resume, but I really don’t expect HR to be able to detect bullshit.
The key is to treat hiring a new team member like any other task you have to deal with. But the days when engineers can sit heads-down and code are all but over; because the situation described in the article above is what you get when you try to do that.
This is the cause of a significant amount of waste, friction and general anger for both sides in my experience. Technologists are well-known for their TLA's, and HR teams have their own obfuscating discipline-specific terminology, assumptions and values.
The incentives for external recruiters are obviously a problem and even for internal recruiters they are mostly measured on seats filled rather than long-term retention or the candidates performance.
Hiring managers themselves are often extremely poor at describing or even understanding what it is they are trying to hire. They often struggle to provide clear and actionable feedback that can change the search.
Figuring out that collaboration is definitely worth while!
Part of the problem is that no matter how careful you are, it seems whenever you bring in 10 candidates to interview, 1 is obviously overqualified and has higher salary expectations than you can offer, 2 are about right (but likely also have other offers), and the other 7 are varying shades of “sorry, not right now...” to “why did we even let you in the building?”
It’s entirely normal to interview 10 candidates, make 2 offers, and get no accepts. That’s a huge waste of time on everyone’s behalf. But I have yet to see anyone find a way to significantly improve on this process, because as the OP states, everyone figures out to just start googling the answers to the questions.
That's the kind of thing that happens when people lie. Everybody who's ever hired engineers knows from experience that a simple Fizzbuzz test is still, unfortunately, a very usable candidate filter.
A lot of candidates with years of real work experience simply cannot write code. How else can we find this out?
So true, sadly.
It's thinking, puzzling, chewing over problems, solving political infighting between customers, management, and the frameworks in use
At the end of the day, the buck should stop somewhere... and it does. With management.
In the meantime, I think it's time for sysadmins/engineers/devs to start getting MBA's and going for CIO/CTO positions and start to push a shift.
I would say that's still management incompetence. They're paying all this money for experts in the field, and they still want to disregard their opinions.
To put it simply, they don't feel comfortable saying: "Well... you're the Doctor".
Nope - they've gotten burned by being talked down to like the cliche mechanic telling a girl her SUV's hammenframas needs to be replaced, and it's $1600.
If you as a software developer cannot speak coherent English sentences (with a small handful of management jargon) to management without devolving into technical shorthand, you are a failure.
Not management.
You.
You have to explain what is going on in a manner your audience can understand.
You should not expect managers to be technical (they might be (and good for you if they are)) - they're accomplishing a different task from you and need solid, understandable, actionable data to take to their management and customers.
"does it work? no."
>googling...
>copy code block
"does it work? kinda..."
>googling...
What’s the order of arguments on this one? Does it modify the data passed in or create a new one? How does it handle nulls?
It’s cheaper to look it up than to debug. So that’s what I do.
It was in a language that I had been using for 5+ years at that point, using a framework that I had just finished architecting a whole application for, had multiple open-source projects in, and the challenge itself was something that I genuinely felt should have been extremely easy, but I miserably bombed it.
I'm almost positive to them I looked like a giant fraud, and to be honest I felt like one too, but after some thinking I really feel that it was just a bad day combined with being uncomfortable without my editor/tools that I use in my day-to-day job that ended with me getting stuck and failing horribly.
I don't know a perfect solution, but when I was later in a position to hire new devs, I avoided coding challenges because of that experience. I feel that you can get MUCH more insight into a developer by just having them talk about what they have done, go into details about problems that they solved, or how they would approach problem X without any writing of code anywhere except maybe some drawings on a whiteboard if necessary.
Coding Challenges to me test 50% "knowing the syntax and not making mistakes" and 50% "knowing how to solve the problem". We have tools and compilers and linters and syntax highlighting and good editors to solve the former in most cases, it's the latter that I'm looking for in a good developer, so why would I use a test that evaluates both of them equally?
I’ve been in that situation myself.
And I wasn't even particularly nervous about getting or not getting the offer either! They approached me, and I wasn't fully sure if I would even like the job yet!
FizzBuzz-style filters not only don't prove that someone can code, they don't disprove it either. I'm not sure what the answer is.
I have social anxiety. It doesn’t interfere with my work in any way but I’m wondering if you could accommodate me in the interview by doing x y z.
It’s worth a try, right? I’ve thought about doing that.
Partly because it's not exactly easy to get enough context and understanding about a codebase in an interview to be able to accurately debug something, but also because again it comes back to what you are familiar with. 6 years ago I would be damn good at debugging and optimizing MySQL queries, today I'd probably struggle to get a moderately complicated one to work without a lot of looking things up and trial/error (I mostly work in postgresql now!).
That's why I like to ask about their past experience. Tell me your war stories, tell me what you did to figure out that bug that was causing the elusive crash, tell me about your struggles getting webpack setup, talk about how you initially planned to do X but then after issue Y decided to pivot to Z because it was simpler/easier/faster/whatever, explain how you accidentally put a quadratic-complex function into the hot-path of your application that one time and when you found out it was a problem.
Just talking about stuff like that can often show where a developer is in their career, what they are good at, how they go about solving problems, etc... And it's almost impossible to cheat/fake it.
If anything, the interviews I've been on have been four or five 45-minute whiteboard sessions, usually about data structures and algorithms or object oriented design.
Nowadays that also seems preceded by a homework assignment and a 3rd party coding quiz.
FizzBuzz would be refreshing.
The industry expect people to lie... "Do you have 5 years experience in <3-years-old-tech> ?"... "Yes, sure".
The problems we see in interviews (assuming people are lying, awkward technical tests, etc) all come from this mismatch, and people either not understanding what they're capable of or confusing things deliberately. A senior engineer at a small company might be classed as a junior at a large one, and when question time comes, that causes issues.
And I'm not sure what the solution is there. I mean, the needs for each company are different, and there's always certainly a place where a developer of any standard could find a job. If they can do what their employer wants, does it matter if they don't know fizzbuzz or can't write a multiplication table? Probably not.
The real question is likely about how you distinguish between what a junior/midweight/senior developer/engineer is, in a market where those roles could apply to virtually anyone in the industry.
I highly prefer to engage the person about their previous projects. Through building good rapport it's easy to determine what they've done and where their passion is focused. If they can't tell me the details of building an X app with Y interfaces and Z databases, then I can figure out they are a bullshitter with only 15-30 minutes of total time wasted. If we can get past that step then we can start talking about more interesting things, like optimizations, scaling out, and our favorite unrelated technology stack and its merits. It's shocking to me that companies feel they need to do more than this these days.
To be fair I work in an At-will state, so if by chance someone does sneak through the process we have a 3-6 month probation period where we make sure they can really do what they say they can. To date this has never been a problem.
I hate that I have to question whether candidates can code, but as near as I can tell, a lot of them truly can't. It leads to an interview process that I'm embarrassed to need to use, but it seems reckless to skip it. I've worked with people who really can't code, and don't want to be back in that situation again. I'd love to have a better interview process, and I'd love to spend more time talking about higher level concepts, but most of the process seems to be stuck just verifying that the things on your resume are really things you did, and not just things you were on the team for but didn't actually do, or outright fabrications.
.
..
...
....
At the time I thought this was an attack to my honor. I literally felt terrible, and thought the interviewer was mocking me, for some reason. I also thought maybe I couldn't make my resume clear. Anyway, this was only a few moments, since questions gradually became harder. Needless to say, after this interview I was really curious why would they ask me such a simple question, which is nothing more than 2 lines of python code.
But then I started learning about this mythical men, who have good resumes but can't even write for loops. I guess I was naive and assumed everyone with a degree in CS would be competent.
"The general thing that I saw from everyone that I talked to is that no one actually believes that anyone can code. At every stage in the interview process, you’re going to need to prove that your resume isn’t a lie and that you can actually do what you say you can. I find this ludicrous because it is like interviewing an attorney and then saying to him “Please prove that you can cite a Supreme Court precedent”. When did an entire industry of people get pre-judged as lying? Don’t we exist in a country where the default assumption is innocence not guilt?"
This is, IMHO, due to the fact that for years new grads would apply to jobs, and the new job required: 7 years programming in X? YES, 4 years writing scripts in Y? ABSOLUTELY, etc, etc. These new grads all had the attitude of "I will learn that on the job, no one has 7 years in X". And now we have a world of companies that don't think anyone can code. Don't know where they got that idea.
They don't need to do that for lawyers because the bar exam handles that (and, for those with traditional legal education, the highly-standardized law school curriculum.) The programming “profession” has neither of those features.
To be fair, there are a lot of job listings where X hasn't even been around for 7 years.
Also, I interviewed with a company called Jumpcloud in Boulder. The interview process itself left some things to be desired but I'm writing to give them a huge shout out that they actually gave me real, concrete feedback on how my homework assignment wasn't up to snuff. Thank you Jumpcloud!
Last time I was interviewing, the first place I interviewed was at a company where I knew the director of engineering from a previous role. I went there to have an informal talk with him and some devs. Later when I sent my resume I was rejected right away. Luckily for me he told me that I came across like a know-it-all crappy dev. He told me why I came across like that and I realized that he was right. It probably saved me a ton of grief in later interviews because I knew what things I needed to do and not do.
I took a stab at improving it, but found that tech has a very extensive workforce built around it being broken that doesn't want it to change.
Sure, they want tools that help perpetuate the junk show they've built up, but not to make the process quicker/more effective on both ends. Most that I talked to openly disliked that idea.
8 hours of homework for the person with the kids who won't have time for it, check
Tests optimized for people with young, facile minds who are recently used to cramming random data into their heads spitting it back out, check
Complete disregard for domain level knowledge, specialization, or the value of experience, check.
Because it is so easy to cut bad engineers the hiring process is much easier. As long as it pays well I don't mind the insecurity of working on this basis...
Another upside of working like this is I can leave toxic environments quite easy too :)
I ran into this a few years ago. I bombed hard when they asked me some specific terminology question about the stages of the ASP.NET request lifecycle. I believe I just said "I have no idea" and the call was over shortly after that.
It was frustrating--why are they hiring based on esoteric trivia instead of general programming skill? This assessment would've filtered out an enthusiastic, genius-level Java programmer!
And is that sort of question actually effective at measuring ASP.NET expertise? I work with ASP.NET every day, and memorizing that information would offer me zero benefit since A) I rarely need it, and B) I can look it up whenever I do need it. It's doubly frustrating to think there's someone out there who believes I'm a weak engineer based on this misguided quiz.
The interviewer interviewing the interviewee is hilariously true. No interviewer could answer questions about my domain expertise. Just like I could never answer questions about theirs.
But they are in control and I am not, so there's no fighting it, just indifferent resignation to the situation, and attempting to sort through it.
A number of years ago I was insta-rejected by e-mail within 24 hours of submitting my CV for a role. I was cocky enough to reply to that rejection email with a 'give me a shot'-type response, offhandedly tossed an online coding test, nailed it, then invited to interview, and later offered the job.
I never took it, but it was a huge boon for my confidence.
All this focus on coding in interviews is actually completely misplaced. Early in my career I had no problem writing anything you asked, but reading other people's code, and having a deep understanding was something completely different.
Now 25 years later, I can still code, and given greenfield development, or just larger pieces of work that by itself is somewhat isolated, I can make features appear in a shocking short time. Similarly debugging my own code, even once its reached into the hundreds of thousands of lines is usually better done by thinking about what in the code base would case the given behavior.
OTOH, the skill that really matters is the ability to debug problems in a code base written by a team I wasn't originally part of. That is still really hard, I'm fairly reasonable at it, but it probably takes me longer to understand someone else's code that it would have taken me to write it.
This also means my bug fixes tend to take a few days if the bug is in an unfamiliar piece of code. But, it also means that I can usually come up with a fairly trivial fix (frequently just a couple lines of code). Vs a lot of code reviews i've been on (which is similarly hard piece of software engineering) where there is a ton of noise and some 1/2 fix that fixes a particular case but fails to solve the general problem.
All that was a long winded way of saying that I suspect that software engineering is in levels, there is the first level where you learn to code, and there is the second level where you learn to understand all the different ways other people code, and then there is the third, where you can analyze the latter alongside a problem to determine not only does the solution solve the problem, but is it covering all the edge cases. A 10x programmer is frequently someone who avoids the second case, and fakes the third case by only reviewing code which touches subsystems they wrote. Interviewing solely for coding skills rather than coding skills + ones ability to read analyze other people's code is missing the most important and hardest part of quality software engineering.
That said, I have seen several people who were open about lacking the basic requirements for a position get hired anyway. So, I wouldn't assume that seeing someone incompetent in a position means they lied to get there.
You can drill down as much as you want on any dimension of whatever topic you choose. I think the choice of topic and how well the interviewee can discuss it would both be good, and distinguishable, signals.
Number 2: As someone that interviews people alot, this is cuz MANY people who apply CANNOT code, no matter what their resume says. We have had people leave and never come back during our console app on site test (read in a text file and print out its contents with some minor formatting). This is resumes with 10 years plus experience in the language supposedly. And the computer has whatever IDE they prefer and full internet access!
Number 3: I agree that CS type questions are pointless unless you are doing stuff like that on the job. We have stopped using those.
Number 4: We now require an onsite 2 hour code project (designed to fit in that time frame)
Number 5: True
Number 6: We use headhunters to weed people out but that is about it. For one position the head hunter roughly run 15 people applying for each 1 possible person to pass to us for the next step. Again, most fail a mind boggling simple phone interview process for people who claim 10 plus years experience in coding. Not knowing what the static keyword means in C# when they say they are skilled in C# for instance.
Number 7: Don't have an opinion on this
Number 8: Again this seems to be your physical location. At ours there is roughly 3 open positions for each matching person.
Number 9: Our company does not discriminate on age and are desperate for qualified people with experience. Many times a candidate regardless of age is stuck in one tech (winforms, MVC, Ruby on Rails (:P)) and we more discrimate on someone who is not showing growth in their tech skillset. For example, are you learning the basics of a cloud stack such as AWS/Google/Azure?
At the end of the interview, I would recommend asking "are there any concerns or issues you would have with hiring me for this position?" and LISTEN to their feedback. I am sure there are some bad companies but for the most part it feels like you are not interviewing well for whatever reason. Maybe you are coming off as defensive or hostile when questioned? I would also reach back to the company and ask why they did not choose you. Most companies are way to busy to tell each person why they were passed over, but if you show an interest they will usually respond.
Anyway good post and good luck to you!
At the end of each interviewer. Asking the HR person at the end of it all is a waste of time for 2 reasons:
1. they won’t know yet
2. they won’t tell you
but the tech interviewer almost certainly isn’t trained to keep his mouth shut and also generally isn’t expecting this question. caught off guard, you can usually get a close to honest response. you do have to interpret a little because people generally don’t want to hurt other people’s feelings right to their face. apply modern day party invite response rules:
yes: maybe
maybe: no
no: fuck noShe says the same thing as you however: if you want the good stuff, you have to attack the social vulnerabilities of tech people. They generally aren't trained to know what to say or not to say past the obvious. With carefully constructed questions, you can often get the information you're after.
Because companies themselves don't understand that the full stack developer, from kernel work to UI is a real thing, ie. you can easily transfer competence from one tech to the other.
Senior positions take longer than junior. There may be other factors in any individual case, but just as a general rule, the more experience you have, the longer it takes to get hired. This may relate to...
> 9. Age discrimination really exists.
In my experience, I haven't seen it. What I have seen is salary discrimination. I'm a pretty expensive guy. I've got 30 years of experience, I'm way more productive than younger people, and I want to be paid accordingly. A lot of companies don't want to pay that.
I recently read a thread on Reddit with people making the exact opposite complaint -- that senior developers just didn't understand how hard it is to find a junior position now.
Because of title inflation the people with average experience match up best with the title senior.
* You'll be discriminated the older you get. Make yourself ready:
* Career and big names is important. Companies wanna hire ex-googlers. Have Google on your resume. It's better to work in BigCorp for 10 years rather than being contractor for 10 years.
* Improve your interview skills. For engineer it's theoretical computer science knowledge and cracking code challenges on a whiteboard within limited time.
* Have a big thing on your resume. Source code, GitHub, whatever it is.
You will absolutely be discriminated against the older you get. Your observation on being a contractor for too long is likely on point (I was).
This is so true (also in Bay Area). I am still in the process of job hunting. The first onsite was in mid March. I thought my last onsite would be last Friday, but no, a few more are still being scheduled (I probably have to withdraw some applications).
Also the negotiation with HR easily takes weeks. Despite I have offers from some companies, I just couldn't get to the actual compensation numbers. (I call this "HR Tai Chi").
> 3. Coding Tests Can Trip Up Even Good Engineers
I have found that the interaction with the interviewers matters more here. If you can solve all tests, then fine. But often times you may get blanked or just stuck somewhere in your solution, and a good interviewer will be able to guide you through and work out the problems collaboratively. I wish companies would spend time educating and training interviewers. (I have had bad times in my interviews where the "obvious" solution just didn't come up during the interview, however much the interviewer hinted).
> 5. Every company’s “process” is different
Yes, the good part of this difference is that "some are pleasant", and obviously "some are annoying". But you get to experience the company culture and how much they value engineers by their difference.
My first job in the Bay Area in 2007 consisted of a single 3 hour in person interview. That's it. I got a phone call telling me the good news on my train ride back to SF. It was my 5th interview and they all consisted of pretty much the same protocol. And yet, some of the top comments on this post say that hiring hasn't changed all that much. o_O
I love software, but I hate the modern software industry.
Part of the problem is that companies keep getting more applicants than they can handle, no matter how hostile their interview process becomes.
Like... a union? A combination of aggressive union busting, anti-union ideology of many in tech, and aggressive offshoring/H1B hiring acts to keep that in check. The moment you try to raise the issue you’re either fired, or some “genius” who reads Ayn Rand like the Bible tells you to pull yourself up by your bootstraps.
Software development is already so heavily dependent on enthusiastic young people that I don't see how a union could get enough traction without completely reinventing the idea of a union in people's minds.
There's nothing specific about a union that does this. The union is an extension of the will of it's members.
I felt it was much easier to land a job in tech 2.5 years ago when I was last looking.
Maybe we are reaching a point of too many engineers and not enough jobs?
In particular, Skyscanner feedback was outstanding (I've been referred through one of Who's hiring thread) for both skype screening and onsite.
If you think it's hard finding a job, try hiring 10 programmers in a short time, and let me know how it goes for you. Try bringing on a candidate who spins his wheels for months (while you pay him) and who you then have to fire. It's expensive. Companies are entitled to protect themselves.
But they don’t do it effectively, only wasting everyone’s time instead. I.e. Protection has a significant cost as well.
As for the presently en Vogue hiring process for senior tech roles, I'd put a deserved blame on companies like Google, where this bookish and silly way of hiring was first codified by the founders and early employees who were fresh grads/drop outs from schools - and that's all they knew about how to judge who's better in class. And as more and more of people who went through that process leave and start their own companies, they follow the same process - thinking that's the best of breed way to hire.
As for age discrimination - it's very much alive and well - specifically in the SF Bay area. Which is a shame.
The last two corporate jobs I had, the companies found me. The few clients I've had as a consultant came to me. Being visible and having a little network is important, and of course having the current popular technologies is important.
But really, doing homework, doing dances, building PoCs, and all that other bullshit is... just bullshit. If a company is going to make you jump through tons of hoops or begin taking advantage of you before you've even gotten the job, they can just fuck off and hire the kind of person they deserve (who will probably fit better into their organization anyway!)
Keep in mind, even if the company has some really awesome people, you're still just useful while you fit. If their budget changes, or god forbid they're a public company and are beholden to the almighty quarterly earnings per share report, then you can be gone a week after you're hired with little more than a "oh we're really sorry". That last bit is one really awesome reason to work in countries that still have some sense of labor power. I think Germany is really good on this, but my experience in Netherlands was... profitable in that regard. Once you have a permanent contract, firing you typically means handing you enough cash to sustain you for many months. I'm not sure what the potential exit compensation is if you're fired due to poor performance, but if they're just downsizing you'll get a nice goodbye check.
The only way companies will ever change their behavior is if the workers stop bowing and begging. This is your life; and if you're truly investing your creativity and giving your all, it should only be for a company halfway worthy. Most companies are not, and you can tell from the interview process. Hell, if you look at enough job reqs you can start to tell just from the req.
Coding tests are an important part of the interview, you would be surprised how many senior software engineers have been in de facto management or very specialized positions for 7 years and no longer know how to code. We are not asking anyone to implement a red-black tree off the top of their heads, just very simple stuff. I think this is important but anything more than a 20 minute question will not help further gauge a candidate. We tend to not put too much weight on the coding test since some very good people have trouble thinking on their feet under pressure.
We also recently started also asking for a simple homework assignment that tests basic data structures and general C++ knowledge. It should take between 2-4 hours. Personally I hate homework and resisted introducing it but a well designed exercise is great for separating out the wheat from the chaff and allows a really great candidate to show some flair with a clever algorithm or even just nicely formatted code. I would now recommend it.
I was asked to do an assignments during my job search and typically spent 3-4 hours on them. I've heard of companies asking for days worth of work - that is completely unfair.
Finally, you would be surprised at how much outright fraud goes on, particularly with junior candidates lying on their resumes. We have had people on Skype interviews blatantly cheating to the extent that one candidate was just moving their mouth while someone else off-camera was speaking for them. "Mr Ed" did not get the job.
I ranted about the interview process last year[0] but now I am a little more mellow now.
[0] https://sheep.horse/2016/10/so_you_want_me_to_hire_you_as_a_...
* the team thinks you’re a great engineer, but you didn’t show enough excitement about the company
* we think you’re a solid engineer but not quite at the senior level yet, it’s ok though, we reject 98% of our candidates
* we do a lot of code story telling at our team (I kid you not) and you weren’t a great story teller about your code
* the team didn’t get the sense you enjoy pairing and we pair a lot here
I actually think the real reason was poor personality match but companies don’t like being honest about that so they make up nonsensical excuses.
Avoid age discrimination by screeners by limiting your resume to the last 10 years and taking the dates off when you graduated.
The last 5-7 years is more than enough in most cases... when I look at a resume with jobs going back to the 90s... it's just painful. Nobody cares what you were doing past your last job. Add 1-2 more jobs before that if you really want to give me background, but as someone who goes through a lot of resumes I wish they were capped at 1-page, and 3 past jobs.
It's about the level and structure of your code. They don't think you _can't_ code, they want to know how _well_ you code.
When I'm interviewing people I let them solve a simple problem as well - it doesn't need to work, it doesn't need to be perfect. I just want to know where the interviewee stands. Case in point - I've had a young-un just out of school in for an interview and his code was clean, commented and had structure.
On the other hand I've had an older bloke in with roughly ten years of experience as a programmer. His code was an absolute mess from start to finish with K&R-style initialization etc.pp.
That is why I want to see how they approach and what code they produce - someone may have been writing code since they were born, but if they never went through a review their code will likely be bad.
> Number 3: Coding Tests Can Trip Up Even Good Engineers
That is true, hence a coding test should not be measured on the completion but rather on the approach the interviewee took.
> Number 10: You’ll Never Really Know Why You Weren’t Hired
True and bad. I dislike companies who don't give the applicants feedback - or even worse false feedback. Much like in a review - if all you hear is 'no, wrong, bad, ...' you won't improve. You need explanations to single out the issues you can work on (primarily in the short term).
My friends in top law firms hire from top law schools and don’t ask technical questions to candidates. If they make it through top law schools they have an extremely high success rate as employees. Should be same for our field.
After a week, the recruiter called me and told me that I am not selected due to my lack of skills in object oriented.
This is the most ridiculous feedback I ever received.
Well... a ton of graduates can't code. Interviewers are constantly struggling with people that can't fizz buzz. Hence fizz buzz's existence.
You don't see it until you post and are responsible for a job ad, which is never for most engineers, and once every year or two for those that do have to get involved in the process.
Lord forbid it's an entry level, you'll get tons of great-on-paper compsci kids that never actually pinned down a programming language and aren't even sure how to hello world out of a c# application (pro-tip, just fucking use python or javascript lol). For frontend, bootcamp kids usually come out on top in this scene, because the camps are specifically prepared for exactly this problem (considering it's their niche - the very reason they exist).
(I've commented on another aspect of the article, but it was long enough that I felt I should break this thought into another comment)
If you are in the big tech companies doing infrastructure work (and to some degree, product work), then you need a very firm grasp of the basics because you will have to revisit them. The reason one has to revisit them in these companies is because scale will demand taking different evolutionary passes that are not needed in most other companies.
What this does is create a barrier between jobs that pay crazy and the rest of the market that just need to cobble together a product. I actually experienced this many years ago when I assembled a hacker news meetup in the midwest. I felt rather isolated because most people were assembling some ruby website or some product while I wanted to build next generation infrastructure and write my own database.
Now, the problem here is that ex-big-tech workers will bring the same processes from big companies to smaller scale. Small companies need to pick their battles, and they need to decide to educate and wield weaker engineers; most will not because that is expensive.
Put yourself in the place of the interviewer, who needs to decide on the person they will work with for the next two years. Software Engineering is already hard, and your interviewers are overworked. They are assessing whether you will be able to pull your weight. Their livelihoods are in this at least as much as yours, if not more. Interviewing is no different from cases where you have limited information to decide on a critical issue, like buying a house, choosing a surgeon, voting for town mayor. You have to separate the important flaws from the minor ones, assess the risk, and pick the candidate that is the best investment.
When you are in a technical interview, you are rarely assessed for some generic software engineer ideal, but for skills that the hiring team have in mind. The chances are very low that there will be a match with all positions you apply to, unless you are also very selective about where you apply to on your end.
> I built it because after I had applied for about 15 jobs, I had no idea where I was in the process and I couldn’t give my wife a decent answer about my progress because I simply had no idea.
The real reason why people do things is often like this! It was a very hard lesson for me to learn, but very enlightening when I learned it.
Having been on both sides of the table, I understand why these are true, but still don't like a lot of these interactions. The worst one is ghosting, there's no reason for an interviewer to leave you hanging, at least they should be following up to say "You're still in contention but..." and do the same regularly every few days until they can make a decision. The only thing missing from your writeup is the observation that the hiring process usually reflects the organization. If your interview and followups were chaos / overly-complicated / streamlined, the company is probably chaotic / bureaucratic / well-organized, too.
Also: @fuzzygroup built my job tracking idea! It's fantastic to see that my laziness has paid off, and I want to hear more about how JobHound works out for you. Please post a follow-up in a few days / weeks / months of what you've learned or what you wish you'd done differently.
This can easily result in wasting your time interviewing for companies that will never be willing to meet your salary expectations. Unfortunately, a lot of companies aren't up-front about how much they're willing to offer, so I'm not sure what the solution is.
"Each interviewer grades you as 1 to 5. We sum that up, then multiply by $10,000."
Even knowing the number of interviewers wouldn't help you very much. You'd need to know how well the interviewers would score you, which won't be determined until after the interview.
"I saw this repeatedly on jobs that I got all the way to the end point on."
"Total Jobs Where You Got an Onsite Interview: 2"
Interesting points, although I would probably want to see more data before drawing the same conclusions.
- someone else was a better fit (tech, culture, attitude, etc)
- you're actually truly incompetent
- the interviewers are morons
99% of the time, it's that someone else was a better fit.
Embarrassing code I wrote under stress at a job interview (at Adaptly)
http://www.smashcompany.com/technology/embarrassing-code-i-w...
The JustWorks job interview
http://www.smashcompany.com/technology/the-justworks-job-int...
I agree the job finding process has gotten slower and slower. Personal connections are becoming more and more important. The industry is not as open as it was 20 years ago.
I've done about 100 interviews at a large tech company. You did fine. Maybe not the best but far from the worst, and definitely in the upper half.
The guy who is interviewing me has mostly stopped watching, because he’s already decided there is no chance in hell that they will be hiring me. He is looking at his phone.
More likely he was bored because he's done this dozens of times and always ends up twiddling his thumbs while the candidate deals with silly syntax errors. (Incidentally this is a point in favor of whiteboards, so that you both can focus on the actual logic rather than fighting the compiler).
I think they want someone who can write something like this in 5 minutes
If an interview session is 30 minutes, the anticipated outcome is not that you solve the problem in 5 minutes and spend 25 minutes chatting about the weather. I guarantee that many if not most candidates don't get to the point you did of having a working solution.
Even if they say “Please feel free to ask questions” if you phrase the question the wrong way, or ask a question outside the bounds of what they were expecting, it becomes a mark against you.
I obviously can't prove the lack of a subconscious effect, but I've never criticized a candidate for any question that they asked. Confirming something that was in the problem description is neutral, asking about something that wasn't (e.g. "is the input case-sensitive?") is a positive.
This kind of crap needs to stop. I think that some level of legal liability needs to pass through outsourcing companies and land on the company that uses them.
I also suspect that if legal liability started passing through outsourced companies, you would see outsourcing collapse very quickly as companies begin to see outsourcing as riskier than an actual employee.
Unfortunately, I'm not sure that we have the legal precedents to pull this off without new laws.
Last time out (3 yrs ago) I took about a month to land several offers and I didn't really do the whole CTCI preparation or anything. I even received an offer from a company whose take home code challenge I completely ignored because I didn't feel like being bothered. This time around I think I will do the full CTCI and leetcode regimen a I do agree it gets harder the more senior you are as the compensation and expectation raise.
>When did an entire industry of people get pre-judged as lying? Don’t we exist in a country where the default assumption is innocence not guilt?
The coding tests and whiteboard sessions are necessary because there are no standards in the software development industry.
There is no license, no standardized test, no nothing for me to judge if you're a liar or the greatest thing to show up for an interview. There is no professional developer license like a professional engineer license and exam, which helps me distinguish between you being a beginner or a senior/lead developer.
Without professional standards, all developers will continue to need to show who they are and what they can do.
"Cracking the coding interview" and similar books are really about competitive programming, which is what you get to do at contests like ICPC and such.
If enough people start using it a database could be built on companies hiring practices, what percentage of applicants is accepted/rejected, coding test type, and all kinds of other potential big data about companies.
That data would be super valuable to us as a tech community applying to jobs.
Also, love the browser integration that populates the forms!
If you get enough help to work on it/funding a mobile app would be killer.
Could you show the job description on the page after clicking on the bookmarklet?
And also on the show job page?
At first I thought it wasn't populating and it's super useful info because if a job is removed it's nice to have visible!
Awesome job!
I tend to agree with a lot of your points.
Re: JobHound, can you clarify your thoughts on what sort of privacy users should expect? Obviously a lot the value to those fully in the hunt will be using it to efficiently navigate public sites, but there are also private opportunities and some that might be sensitive. Any thoughts? Obviously easy to work around by separating job sets, but thought it might be valuable to others, too.
Thanks again!
I do like programming / what i'm doing anyway and it is not that far fetched to expect someone to write code or know what ACID means exactly. It is more like 'sharpening your skills' and i like doing it.
I do hate homework. At least google and other companies do that together with you and investing equal amount of time for it. When i get a homework, there is often not much effort on the other side.
What i do is always ask for feedback because of that time i spend on the homework.
In the face of such frankness, many lazy asses may decide to exclude themselves. ;-)
We also, sadly, have found that a large portion of our interviewing time is devoted to "fraud detection" as many candidates simply cannot do the things that their resumes indicate they should be able to do.
Unless the author has never attempted to hire programmers, I don't understand this attitude at all. It's extremely common to find resumés vastly exaggerating the applicants skills in programming languages and technologies.
Maybe there is some blog post (from HR specialist) explaining it in detail?
E.g. https://www.jobvite.com/recruiting-process/7-benchmark-metri... https://www.glassdoor.com/employers/blog/4-tips-for-hiring-t...
That's a reasonable model, but it works best if all your filtering steps are effective tests for the things you care about. Getting that right is demonstrably hard, between some hiring managers who don't know or don't communicate what they're looking for, some recruiters who don't understand what they're looking for or how to recognize it, and some job-seekers who don't communicate or demonstrate their skills through the hiring process. And so everyone sees and resents flaws in the funnel.
How long did it take to find your last job and break it down by demographics.
By the time I get past the coding test and the phone interviews, I'm as good as hired, and the in-person interview is just a formality.
So true. Do not tell them!
Oh please dont show me that. Im afraid
> If an HR person says to me “Oh and we administer a coding test” then my first response is “I’ve taken a bunch of those, which one do you use?”.
If I was hiring and a candidate said that to me on the phone I probably wouldn't invite them for an in-person interview.
Fucking LOL. I demand tests not to see whether you can write a for loop, my wife has an art degree and can do that. I demand tests to see if you bothered to comment your code, use version control, use tests, and actually put in some custom logic instead of boilerplate CRUD. There are so many people who fail those basic tasks, its unreal. Plus, programmers SUCK at interviews, so why even bother giving it any weight? Show me talent in the homework and I'll hire you.
if he’s 50 yo, assuming same career since graduation, his first mistake is applying for senior roles. senior is 5-7 years experience. he should be applying for staff roles at minimum and up to principal.
i guess you’re not supposed to slam posts here but this article is more of the same old same ole.
i would like to see an article from the hiring manager POV.
Add to the hurdles:
* Salary negotiation
* Contract review/negotiation
* Reference check
* Background check
* Getting a work visa
There's still lots of work to do once you complete the onsite interview!
Not everyone makes principal, and you shouldn't go into management if you aren't suited for it.
Oh but if you don't do either of those things by 40 then you suck and don't deserve to get hired.
Speaking of sucking, I should probably figure out what I'm gonna do once I'm unemployable. hm.
From a recruitment standpoint, this guy's "sales funnel" is remarkably efficient. I'm more used to seeing a ration of 100 applications > 10-15 phone calls > 5 onsites/technicals > 1 offer. Needless to say he blew the initial phone call / interview numbers out of the water, though it did eventually narrow down to about the expected number of offers.
I don't like the current state of recruitment and job hunting. In fact, I have literally never met anybody that did. Recruiters whose living depends on it, our managers, the engineering managers we pitched to, our candidates, fucking nobody is happy with it.
Nobody has solved it though so now that we can all it agree that it sucks, it would be irrational to sit around and complain about how it sucks instead of adapting (and fixing it when you're not trying to figure out how to get health insurance before yours runs out and you gotta spend 400 on COBRA):
It's a number's game. You must send a fuckload of resumes because sometimes a resume for the perfect job will fall off the recruiter's desk or get lost in their email, or get lost in their spam folder, or the recruiter just won't understand what they're looking at, or there's a candidate slated for the position already, or somebody didn't like the formatting of your resume and got frustrated and threw it away. Or 50 other reasons.
That same randomness applies to each of the up to 10 steps (usually 3-5) before you get an offer. They couldn't get you scheduled for an interview in time. You came in and somebody thought your shirt was stupid or too casual. You came in and somebody thought you were dressed too well and a tryhard. They gave you a dumb algorithm that had nothing to do with a job and it created salty feelings on both sides. I mean, there's just so many variables.
So in this system, your best bet is to increase the resolution as high as you can. That gives you realistic access to the greatest number of opportunities you'll actually like, and the luxury (or burden, I suppose) of choice.
Until someone fixes this systems. Lord alive, somebody please fix this fucking system. The best progress I've seen on this front has been by coding test websites that hyper-tailor your profile to companies with specific needs, i.e. completely useless for every other job in the world. Beyond that your best bet is to just align yourself with a god-tier recruiter that actually cares about their relationship with you and their candidates (the established ones that don't have a manager breathing down their neck to randomly spam out resumes cause their numbers aren't high enough).
I'm neck deep in my job search, and I'm getting to the HR interview at rates around 30-40%, but that's because I'm getting to the HR interview at rates near 90% where I was able to get someone to refer me or send my resume straight to the hiring manager. For non-referrals, I'm seeing closer to 100->10-15.
I think that's just insane.
That you are seeing 30-40% HR interview rates shows you've got something on your resume (or your referrals) that's pushing your resume higher on the stack.
>It's a number's game. You must send a fuckload of resumes ...
So you recommend not bothering with personalized cover letters? At this point I'm really starting to see the sense in this.
You should always send a cover letter because it can't hurt, can only help, and therefore game theory or some shit.
Because we've yet to define what that "tank" is, and because assigning a graduates likelihood to become employed to the depth of their "tank" was unacceptable, it was always taught to instead remove yourself as much as possible from every application.
Remind yourself for every one that a rejection will happen for any reason that has nothing to do with you. A lost resume. A position closed. You'll never know. Therefore, any emotional investment is wasted.
Gotta get robotic about it mang
Your skills were verified by the reference checks.
Is this true for other people ?
JobHound Sign Up Works, but the login link takes out of outside the page.
In my case I am a senior JavaScript developer who doesn't like the straightjacket stupidity that is popular large monolithic frameworks. The demand for this skill is stupid ridiculous. If you want a new job simply put your resume online in one of those job boards like CareerBuilder or Monster. Within 2 weeks the recruiters will discover it and I expect to get 6-8 responses eagerly pushing me into interviews once my availability is "discovered". After those initial responses I might get another 10 or so serious asks for my time.
Most people who do web work, in my experience, actually cannot code. If you are a strong coder the interviews are largely a meet and greet, because you probably have a strong answer for everything in your comfort zone and immediately shut down questions about areas where you are weak.
You have to consider that web jobs are generally considered low barrier to entry and so half the people that apply are grossly under-qualified and many that are qualified are just learning to code and incredibly far away from "senior" level. As a senior, an actual senior, expect to enter the job jumping potholes and dodging landmines from the incompetent code already in place. This doesn't mean that I think highly of myself, but rather many companies don't know how to develop or hire strong web developers yet, in the meantime, they still expect work to get done somehow like a mistake mosaic.
As far as salary goes I have generally made more time I have gone somewhere else. Because the demand for senior web developers is ridiculous stupid many employers suspect if you are interviewing with them then you are probably actively interviewing with 3 or 4 other prospective employers, and so if they believe you are a competent senior there is a rushed hurry to get a hiring decision back to you as soon as possibly, often in the same day you interviewed. With that rush comes high salary offerings, which I guess is an effort to outbid the suspected competition.
If you are interviewing in the corporate world and actually are at the senior level age is irrelevant and the preference skews a bit older. Nobody is going to believe you are actually an awesome senior developer if you are under 24 years old unless you are a brilliant child prodigy who has been inventing new software techniques for the last 8 years. I am on my way out of my thirties and my age has not hindered any demand for me.
As far as interviews go what has done me well is honesty. This means telling prospective employers things that might make them throw up in their mouths. I don't like large blunted frameworks and so I prefer to get much of the nonsense out of the way early on. If the disdain for the safety scissors is a deal breaker then don't waste my time and I won't waste yours. Since the demand for seniors is ridiculously stupid I am fortunate to be less afraid of being so blunt and immediately honest.
That probably shows HR is just "working" and doing interviews. Not necessarily to hire anyone.. they might just be gathering data. Maybe harvesting the people available on the market. Checking if you are up to doing homework and not getting paid. Checking what your salary is. Telling you make some ranking challenges. Building a profile about you.
Your profile might get a price-tag and shared on the HR black market. I suspect there are even black lists by segment shared on some HR black markets.
Then, there is also a big mafia/network that makes people only hire friends, recommended or known persons.
1. no one believes anyone can actually code - I experience quite the opposite. People expect others to be able to code just because they are currently employed as software developer. That's not true at all. Sooo many people can't.
2. Coding interviews are not about findign the solution but about showing some skills, showing how you handle things under pressure, your ability to explain what you do etc.
3. homework assignments are not done in professional environments.
4. interviews matter more to you: I agree and really hate this. You need to give 120% before you even get to the point where you can choose what you want. And at this point you suddenly have 90% of the power and often not enough energy anymore to make anything good out of it.
5. And yes it's even part of the job of the company to NOT let you know why you weren't hired. Still, I think you often know after the interview how it seemed. Good feeling = chance, no good feeling = no chance, weird feeling = usually weird job as well.
PS: One side note. A senior coding position might feel age discriminatory because senior is for talented ~28 year olds to mediocre ~40 year olds. A 50 year old should be architect/manager or not switch jobs.
It's fair to assess someone's ability to code. It's also fair to for the interviewee to expect the interviewer to demonstrate an ability to review code.
>> 2. Coding interviews are not about findign the solution but about showing some skills, showing how you handle things under pressure, your ability to explain what you do etc.
Until I have something better to go on, I assume the interview process is a good proxy for what it'd be like to work with you. If I think you're hazing me, even if I 100% ace your interview, I simply won't want to work with you.
>> PS: One side note. A senior coding position might feel age discriminatory because senior is for talented ~28 year olds to mediocre ~40 year olds. A 50 year old should be architect/manager or not switch jobs.
Is that a serious comment?
In other words, it might feel like there's age discrimination because of the age discrimination?
E.g. you want to still code with 50? Then spend your 30s building a network, then go into consulting. (giving up some safety in return)
E.g. you also don't want to bother with career? Join a big, strong company in your 20s and never switch jobs. (giving up some money in return)
E.g. you rather want the flexibility and safety that comes from switching companies sometimes? Move up the ladder. (reducing the amount of time spent coding on the way up)
There is always something that can be done, and even planned for.
Why? What's wrong with coding when you're 50 if you like doing it? That sounds like completely prejudiced and baseless claim.
Also the lowest level of each money-making hierarchy is usually where the unacceptable stuff happens. In IT it's this huge amount of new languages, new frameworks, new patterns that a 50 year old usually can't get into that easily anymore, to some degree because he knows it's just a hype that will be over soon. Even being 32 years old I get that feeling quite often already.
And let's say you really want to just code. Why didn't you spend the last 25 years of your career building a network and now simply do consulting work for $300+/h instead of working as employee for less than half?
Now that I said all of it, I have to say that I actually even agree with it. Everybody should have a plan how he builds and spends his career. And "I do the same thing for 30 years" is neither a plan nor a smart thing to do in IT. You could call it the disadvantage of individualism. You're free to do what you want, but that also means you are responsible yourself to find a way that works with the reality you face.
This assumes developing software is somehow an inferior practice to management. Nothing could be further from the truth.
> if one has a 20 something and a 50 something competing(!) for the same position.
If a person with nearly no experience and a person with 30 years of practical experience compete for a position, you'd choose one with no experience? Odd decision.
> Why didn't you spend the last 25 years of your career building a network and now simply do consulting work for $300+/h instead of working as employee for less than half
Again, you are assuming than developing software is somehow inferior practice to management. Again, this is baloney. And why one would want to trade doing what one loves (development) to messing with contracts, bills, accounting, CRM, etc.? Of course, some people might, but presenting it as the only way to go is nonsense.
> And "I do the same thing for 30 years" is neither a plan nor a smart thing to do in IT.
Coding is not "the same thing". Developing software is an amazingly diverse profession. Of course, you don't have to stay with a profession if you don't like it anymore, but presenting it as if somebody who does is stupid and has no plan is a complete nonsense.