I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’. Every technical interview feels like rolling the dice in proving I am a competent developer. Giving me 50 minutes in a high pressure situation in an environment i am unfamiliar with and people I just meet will never product my best results, and then add to the fact that I could be asked any question, and my ability to answer is it being ranked against other candidates. Maybe someone else _just_ did a similar question in another interview and it’s fresh on his mind. Maybe someone spend their entire career focusing on just this type of problem given in the interview, but the question in the interview is only partly related to the actual job.
I did an interview with Reddit - whom I hope sees this comment - and they not only provided zero information about the context of the tech interview in advance, or whether it would be one, but also the interview itself was like playing a random version of tech Jeopardy, but without the category columns, and very few of the questions had anything to do with the job I would be doing.
I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups. That includes hiring countless developers, so I get both sides of the situation. And my partner is also a tech recruiter for a top tier HFT / market maker, so I know what a demanding but respectful hiring process looks like.
Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs. And a year later the role is still open.
I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.
When the interview was over I thought, "Is this how working with these guys is going to be?" If I ran into a problem and went to them for help, would they just stare at me, waiting for me to figure it out on my own?
They didn't extend an offer to me and, based on my performance in that interview, I can't say I blame them. I'm not sure I would have accepted if they had, however. That experience really left me with a bad taste in my mouth and a low impression of that company.
We as an industry really REALLY need to figure out a better way of conducting interviews.
As someone passively looking, thank you for this. I'll remove Reddit from my list. That is unacceptable. I do 5 interviews a week on average for my company, and if we did that to candidates, heads would roll.
As an interviewer your two objectives are:
1. Ensure the candidate has an excellent experience
2. Collect data points
In that order. Sometimes we run into candidates who make the second item difficult. They fail to complete the specific technical problem. They can't speak about their experiences in detail. We need to drag data out of them screaming. It doesn't matter, your priority is to ensure they feel respected, and leave thinking they WANT to work there.
One of my buddies gave me this useful insight once: the impression you give your candidates, even the ones you don't end up hiring, will likely be the last impression you'll get to make on that candidate and the tech world is very small. Negative experiences will impact how candidates perceive your company and word of that experience will spread. Always be respectful to the candidates. If nothing else, they took the time out of the day to meet with you and go through various obstacles, etc.
It's too bad your experience was so negative. That's going to be a datapoint in my mental dataset of companies to consider when the time comes.
> Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs.
And from a completely non-technical persons perspective Reddit is incredibly disorganized at the executive management and corporate level. The amount of turnover, controversy, business model revamps, etc. for a 16 year old company with the hype they have is unique and unprecedented. It's not surprising whatsoever that their hiring practices are similarly disjointed.
I interviewed for a front-end dev position (it was my first ever interview in the industry, I vomited before I got there so it was a pretty crazy day).
I come in. The front-end guy starts asking me questions to try and solve something he is working on. No-one else is there yet. He is asking me about why a JS compiler is removing his comments, I say I don't know, I have never had that issue before...I make an off-hand comment that I use React and most of my JS code doesn't have comments because I am just working on projects by myself, and I don't do a lot of library code...the manager comes in at this point, and proceeds to berate me about why commenting is essential. I say: I use comments where they are needed. Off he goes, again.
Interview starts. Manager proceeds to go through a series of questions designed to expose my ignorance. None of which are related to the job. One classic was him explaining to me that database normalization made no difference to the size of the database because "the data is all the same on the disk" (which is, ofc, not accurate...I tried to explain, he just kept repeating that over and over...he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin). For some reason, there was also a back-end guy there who, upon hearing that I built something in Java, proceeded to launch into a series of questions on internals of Java (for example, he asked me what the difference was between certain versions of Java and the size of the heap...perhaps unsurprisingly, he also got some of this stuff wrong but began laughing when I said I thought X was Y).
The only two questions that I had about front-end dev were: the front-end guy trying to ask me to help solve an issue he was having (before the interview, when no-one was there), and a question about the value of this in arrow functions (which I got wrong, but is also an excruciating thing to try and explain, so I don't think the guy knew whether I got it wrong...it is a terrible question). That was it.
Had a colleague have a similar interview with Reddit for an infosec/appsec role. They said it was a shit show, no feedback, never heard back. Sourced through an external recruiter, so Reddit is burning some recruiter's time churning through candidates. Picked up by someone in finance at similar comp a few days later.
I interviewed for a director of engineering role there — met the CTO, very informal ahead of the actual interview loop. Recruiter said they would follow up. Crickets. I followed up. Silence.
I also interviewed with Reddit, although it was a few years back at this point.
I thought I nailed their code challenge and expected to continue through the process, but after that session that was pretty much the last I heard from them. It was pretty disappointing.
My favorite interview surprise was when I was asked to craft a presentation on an interesting project and be prepared to discuss it. When I got on site, it turns out they wanted me to present it cold to the entire dev team of 50+ people.
The last technical interview I did was for Facebook, and say what you will about them, it was a great experience. Before the interview they actually gave me a couple paragraphs about what I was going to be tested on. Needless to say, I nailed it. :D
Reminds me of how too long ago they ended up hiring someone with a very controversial background, and quickly backpedaled on the decision. Seems like they need to take a long look at their hiring practices
I have a not dissimilar background and what you describe is exactly what caused me to throw up my hands and leave the tech world. It's just not worth the BS.
I had an technical interview with a company early last week, we did a shared session using VS Code. The interviewer wrote the function signature, and I filled out the implementation. I did great, according to the interviewer, and moved to the next set of interviews.
The next interviewer, which turned out was also technical, ended up opening up a shared Google Docs to write code it. I asked if I could just share my screen in my own editor, but they couldn’t give me permissions to do that. I was given an extremely vague question. When I asked questions, he told me to stop because he was holding out for next iterations of my implementation (again, in a Google Docs). Given no structure and an absurd environment, I completely bombed it. And to top it off, instead of getting an email saying they were not interested in me, they just ghosted me all together. A complete waste of time. I wish them luck in their endeavor to find the best engineer to write code in Google Docs, since that is apparently what they are interviewing for.
reminds of of the systems design interview I had with Google, the interviewer had his webcam off, barely spoke English and had me trying to make diagrams of system architecture in google docs with no reference of what he was actually looking for
it was like sitting in a confusing nightmare for an hour
I'd almost rather physically writing on a whiteboard than using something like Google Docs to pseudo code in. I don't know how someone even remotely technical would think that was OK.
The first time I interviewed at Google I didn’t make it past the phone screen. I bombed a question about an appropriate length of a Bloom filter because I hadn’t recently been thinking about Bloom filters, and I was summarily rejected for onsites. The second time I interviewed I was asked a number of questions that I was perfectly “primed” to answer. Because those were in my brain’s cache, I was able to get through the full interview loop with a “hire” recommendation.
My focus is security, and so the second time around I got Travis Ormandy as an interviewer. I was able to impress him well enough with my IPSec foo to make it onsite. Then I got asked a question I had already been asked in another interview with another company, and I was able to knock that out of the ballpark (I mentioned I already knew that question, but the interviewer wanted me to answer it anyway). Then I got asked a question that used recursion, and because I took a graduate course on induction and recursion within the past year, that was effortless for me. Then I got asked a question that involved a kernel feature, and because I happened to recall the Linux kernel list macros and semantics (something I couldn’t repeat now over 10 years later), I really impressed that interviewer.
I ended up having a really successful part of my career at Google, even though I ended up not really writing much code when all was said and done. However what code I did write was highly impactful.
Looking back, things could have gone very differently if I had gotten a different set of interviewers and/or questions. The questions I got just happened to coincide with what was “paged in” to my “working memory,” so to speak.
this needs to be one of the highest rated comments squarely due to how much luck (or gruelling prep) is involved in effectively memorizing answers, i.e. the issue with technical interviews to begin with.
> I bombed a question about an appropriate length of a Bloom filter because I hadn’t recently been thinking about Bloom filters, and I was summarily rejected for onsites.
I've never even heard of a Bloom filter, so I know how I would have done.
Yeah the amount of trivia folks like to throw out, and the assumptions made based on them is absolutely absurd.
I've ran into "OMG he didn't know that!" responses when one dev disapproves of a candidate. Inevitably I ask "Really how often do you need to know that? and if you needed to wouldn't you just google it and be done?" but we assume it means so much more and there you go.
Then someone else gets hired and they knew the trivia, but can't apply it or worse only really knew the answer and not the ramifications... or they just can't wrap their mind around / don't care to think of second order effects or whatever.
That all makes sense, and it bothers me, too, but they do hire somebody eventually, which implies that somebody can produce quality results in 50 minutes in a high pressure situation in an environment they're unfamiliar with and people they just met.
Note: This depends on hiring style. Some companies have a bar and everyone who meets that bar is hired. Other companies are hiring for a position that gets one person...
These results may be "curved".
If you give the same easy test with no pressure and everyone is sufficiently good, then it was a waste of everyone's time.
In such an approach, you do something that is sufficiently hard that you're able to identify the people who are the better performing ones along with a reasonable idea of how well they work under pressure (because that will happen at some point).
Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).
>implies that somebody can produce quality results in 50 minutes…
This is more a random fluke as much as sampling bias. Akin to someone either getting lucky or someone who is coming from a very similar environment. This isn’t a measurement that guarantees someone is competent, rather it’s a guarantee that someone is coming from just as incompetent an environment as you have.
Or they just hire the guy they knew through their network. A lot of "how to beat the tech interview process" advice is about how to break down the door with a battering ram when you don't have the key.
I have done that in the past, and I've failed miserably in the past as well.
Am I on the top of my game right then and not stressed about anything and the questions out of the random million possible questions that could come up are ones that I just happen to have had on my mind recently? Then I ace the interview.
The last time that happened it was in a big international consulting company, they then put me through 5 other interviews afterwards, each one telling me I would hear something back in the next couple days.
The last one I got told couple more days, they didn't call me back for nearly two weeks. Then they call: Hey Bryan, we would complete the offer process now hope you're still interested?
Uhm unfortunately I got an offer last week for a 6 month consulting project, sorry but I had to take it because they said they couldn't wait to see how this turned out.
In many other fields (medicine, law) people study a standardized body of knowledge, take a standard test and then get a license so they can do something others cannot.
However, this doesn't prevent a lot of awful and a lot of great people getting through. You would still need to interview a lot of them. I wonder if it sets a minimal level.
For the top law firms, things are pretty straightforward. You have to pass the bar, there's the school you went to, your class rank at the school, internships and clerkships, and then associates are largely up or out.
I assume it actually works pretty well but there's obviously a huge amount of gatekeeping involved.
> I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’
Someday soon we may accept that what gets classified as software engineering is actually an amalgamation of skills from an entirely different set of titles/careers, most of which treat software creation and management as a tool and means to an end.
I don't generally consider a blacksmith and a welder to be the same occupations. You can lump them under metalworker, but would you really expect the interview process for these roles to be at all similar?
If they were applying in the tech industry you would. Might as well lump in metallurgist, chemist, materials scientist, and sheet metal workers because we do this in the tech industry. Everyones a generalized set of specialists rolled into one.
It's because there isn't one. So much professional advice seems to be based around a SV/FAANG mode of operations, but that just doesn't apply to a good 90% of the industry. Most tech work is done on line of business software, not megascale internet companies. Building high-design marketing websites is completely different from enterprise SaaS is completely different from infrastructure is completely different from video games is completely different from desktop software. Not just requiring different tech skills, but different personalities and working styles.
True. Furthermore, many of these FAANG sites work terribly and are ridiculous to navigate. Where is the logout button? Oh, they purposely hid it several levels deep under a strange tiny icon menu where users won’t find it … so users stay logged in and they can be tracked by the advertising markers.
Or, why did the screen just scroll down and lose my place in the paragraph? Oh, they loaded an ad in the middle of the document and the page re-rendered itself causing jerks and fits on the screen. Nice job FAANG site!
Or try performing a sort of items by price or whatever other criteria … doesn’t work because the website wants the user to see the “suggested” items no matter what search criteria was desired y the user.
This really is the problem. And I think it leads to a lot of the dysfunctional interview behavior that we've all seen. Interviewers are having to make up their own evaluation methods but really haven't thought through what the acceptance/rejection criteria should be.
The best interviews I've had, either as the interviewer or the candidate, have been when there was a discussion and a free flow of information in both directions. Unfortunately, it seems that in a lot of places, this degrades quickly into a hazing ritual.
It really would be nice to have some kind of license at this point. For interviewees, it sucks because you basically have to take your license exam for each company you apply to. Interviewers have to administer this exam, and they may not be that good at doing that either. They’re more interested in getting to know candidates and hearing about their experience.
I had an interview with a company a few years ago -- on paper it looked like a perfect match. During the interview things seemed to go well, but things took a turn for the worse with the technical lead's interrogation.
He asked five or six questions related to C and C++ undefined behaviour, a very open-ended one about a technology I'd never used. I answered as best I can, but always opened with "I'd be referring back to the C standard and opening a JIRA task to fix the code". We got on to how I'd fix the code -- remove the UB, but only if there's a unit test covering it. What if there are no unit tests? What if there's no JIRA? Lots of what-if-maybes.
A few days later I was on a 3-way call with the recruiter and one of the guys that interviewed me. They spent the whole thing telling me how "any decent developer" should have known what the UB would result in, shouldn't have to refer to standards or books... and on and on. But as a courtesy, they'd be happy to make an offer.
Half the minimum posted salary, no benefits. It was right in the middle of the minimum wage and the "living wage" lines.
I declined politely, and the recruiter hung on the call...
"Wow. I don't know what to say. That's never happened before... do you mind if I share the recording of that call with my manager?"
They were still advertising to fill several positions when I last stumbled across them on Glassdoor a few months ago...
I thought the actual thing with C (and probably C++) UB is that, well, pretty much ANYTHING is allowed to happen (by the standard)? Including, but not limited to, nasal daemons.
this is advice i give to a lot of people trying to get into the business or switch jobs. no matter how prepared or qualified you are, every interview is a roll of the dice. maybe the interviewer is in a bad mood. maybe you're in a bad mood. maybe there's a communications barrier. maybe there's some organizational issue (too many candidates in pipeline, re-org, etc.) that causes the bar to temporarily be set extremely high. It's ultimately a numbers game and it doesn't make sense to get too invested in one company or read too much into one result
It doesn't help that so many concepts on CompSci show up in different places under different names and labels.
I haven't participated in technical interviews in a long time, but when I was asked to do it, I made it a point to throw as many lifelines as I could until I got a satisfying answer. For instance, if want to know if the person understands generics and they can't answer the question outright then I'll ask them about C++ templates. Similarly, if someone can't describe the term "idempotence" I'll ask them "can you tell me what makes a function pure".
Mind you those terms aren't interchangeable but if you catch one it should be trivial to understand the latter.
Even if someone's never heard of idempotence, it's enlightening if you can get them to discover it for themselves by asking questions like, "What happens if this request gets sent twice due to a network issue?"
I think it's because software varies vastly in complexity and spans many domains. Every software engineering role may use a generalized skillset to a degree, but I feel like there can never be one all-encompassing bar that can effectively cover the requirements of every role.
The same would apply for law and medicine, but those fields have chosen to make a requirement where specialists do have to be generalists first and have to learn and be examined on the whole field.
Becoming a specialized divorce lawyer still requires you to pass certification on things like criminal law and constitutional law (among many other things), you won't be permitted to practice law if you know just your specialty, no matter how well you know it.
Becoming a heart surgeon still requires you to pass certification on pharmacology and gynecology (among many other things), you won't be permitted to practice medicine if you just know your specialty, no matter how well you know it.
But for software workers we do accept that you can ignore many related (and even relevant) fields and just learn only one niche of technology - we could make an all-encompassing bar, but it would be a major change and I'm not sure if we would want that.
>our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’.
They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I started in this field in 1997. The interviews were more old fashioned, a few tech questions, see if you were an oddball, then they'd get back to you. If you didn't work out, they would just fire you. Pretty simple.
My current company works predominantly with 2 major programming languages: Python and JavaScript. This is made very clear when advertising our open software engineering positions. Despite this fact, we once had a CS graduate (from a top-tier US university) who applied and was unable to write a for loop in either language. Yes, that's right: a for loop.
> If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I’ve interviewed many people with 4 year CS degrees who can’t really code. I’m not sure how this happens, but it definitely does. I disagree that having a CS degree should excuse candidates from coding interviews.
If it's not enough for an employer, it's because that employer devalues what's taught in most CS programs. Granted, there's a significant mismatch between CS degree work and real world work, but that's true in lots of engineering. Ask any engineer in whatever subfield how much time they spend solving differential equations. I mean, great that I learned how to balance a binary tree and write a heapsort in my DS&A class, but have I ever needed to do that at work? Other than to pass some stupid coding interview?
recently interviewed with Robinhood. Their phone screen started with a system design interview, but man I felt so uncomfortable using the tool that they had shared. The interviewer created a text box in the tool and copy pasted a multi paragraph question. The font sizes were little too big, I had to constantly scroll up and down to read the question. After brief introductions, giving previous work/project summary, understanding the question, stating and clarifying my assumptions, writing down product requirements, identifying tech stack, I was already 25 minutes in for 50 minutes interview and from there on I was told to speed up and within the next 20 minutes, I was asked to make it scale, fault tolerant and all this even before I could properly illustrate and communicate my design. It was very confusing to be constantly switching between different design paradigms before being able to explain one. As expected I didn't clear it but at the very least the recruiter later did follow up and I communicated my feedback on the interview. Hopefully they take these feedback and make the interview process better.
I’d be happy if some organizations started accepting a credential in lue of a coding interview, and just did a design/architecture and cultural interview.
We made the interview process very simple and traditional in our current organisation. 30 minute chat, judge whether the person can do the job or is a good fit, if yes then offer a year contract with 1-3 months of evaluation period. Changing a job is risky also from the candidate's perspective so if the person is pretending, the lies will catch up. Most of the scenario it has worked pretty well.
Sometimes, people who you think are not capable to do the job, often outperform expectations too. It is all about taking a risk on a person and giving them respect and a chance. We could have done leetcode, or pair programming session. It takes more energy and effort to do it from both sides and probability of finding a good candidate is more or less the same.
> if yes then offer a year contract with 1-3 months of evaluation period
Contract work is a great way to find good talent, but it's a different candidate pool. Lots of good candidates can't or won't give up their full time jobs to take a time-limited contract job.
Those who can take contract work are often more talented and more in demand, meaning they're less worried about finding another job if the contract isn't renewed. Contract work (without benefits) is not an option for a large number of developers.
Isn't contract work looked down upon in the US? Here in the UK, its the opposite, contractors make atleast 2x the money, and most wouldn't dream of going back to salary position because no company wants to pay that for a permanent employee (apart from american companies and qaunt finance with nice bonuses)
> Sometimes, people who you think are not capable to do the job, often outperform expectations too.
I think everyone, employers and employees get too caught up in requirements and forget that humans are very general purpose. And in particular, highly capable and intelligent humans can rapidly acquire skills.
In particular, if you are hiring someone for a potentially lengthy career, capacity for change seems incredibly more important than immediate skill.
Key problem is software engineers are generally bad at hiring. Hiring is a skillset of it's own. For example, you are technical writer for writing user facing docs, similarly I think it is specialized job where you use cognitive abilities to make a judgement, use psychology to see how the person will be in various situation.
With a traditional interview and job offer process, a new employee can ramp up without worrying their job is on the line. And I think this is important, because it can take awhile to ramp up to full productivity, which can be stressful if the new employee feels like they're being evaluated already.
Where I've worked, my new manager told me "Hey, welcome to the company. Please feel relaxed and take your time ramping up, you've already passed the interview and we're happy to have you here."
With your process, how do you deal with people getting stressed out during ramp up or feeling imposter syndrome?
Wouldn't people go from stages similar to culture shock?
1) Wow, very interesting company. I didn't know so many things can be done in different ways than I'm used to. Very smart ideas out there.
2) OMG, this company is full with idiots. Everything is done the wrong way but somehow it has not collapsed yet.
3) Yeah okay, some stuff is the way it is because it would't be feasible any other way due to the quirks of the business. Other things are the way it is because of historical reasons and it doesn't make sense to re-do it at the moment.
4) You know what, I think I understand what this company is all about. It's not perfect but people are actually doing great things here.
5) OMG, this business is crime against humanity. It shouldn't exist, I don't know how I'm supposed to do this anymore. Money can't buy me.
6) Well, the world is not perfect and I understand the imperfections and I can function. It's not like they are doing it any better anywhere else. I grew to appreciate upper management, now I understand our business and I'm happy to do my part.
3 months should be enough for a nice honeymoon stage. Both sides can know that longterm relationship is achievable if they have a nice honeymoon stage.
If you are a semi-experienced software engineer and haven't been deliberately lying during your interview, you shouldn't really worry about getting fired.
Can I get a job? I've been on multiple stages of interviews, of which, some are 2+ hours of coding and even if it seems promising and that everyone's happy... I still end up getting looked over. Even programs like returnships that are specifically for people who've been out of the game for 1+ year, despite showing them that I can code and architect software... I'm still kept waiting and don't get in. I feeling pretty dispirited at this point.
This is something that I have never quite understood. In most of the places where software engineering is big, you have very loose labour laws. But companies treat hiring as if employees are signing on for life (compare this to how they treat downsizing). It is very strange, particularly given: the fact that almost no-one thinks current hiring practices are perfect, and the difficulty in producing a process that actually works (again, it seems odd that people hiring are engineers but take an approach to hiring that is very precisely wrong, rather than roughly correct...this confusion between precision and correctness seems common with engineer backgrounds).
If I remember right, Google found something similar too. Everyone knows Google makes the candidates jumps through a lot of hoops to evaluate them and hire the "best and the brightest". But an internal study showed that apart from the really top talent (the rare few), all that technical knowledge doesn't matter much in the long run:
> "Google originally set its hiring algorithms to sort for computer science students with top grades from elite science universities. In 2013, Google decided to test its hiring hypothesis by crunching every bit and byte of hiring, firing, and promotion data accumulated since the company’s incorporation in 1998. Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills ..."
> "Project Aristotle analyzes data on inventive and productive teams. Google takes pride in its A-teams, assembled with top scientists, each with the most specialized knowledge and able to throw down one cutting-edge idea after another. Its data analysis revealed, however, that the company’s most important and productive new ideas come from B-teams comprised of employees who don’t always have to be the smartest people in the room. Project Aristotle shows that the best teams at Google exhibit a range of soft skills ..."
All that tells me is that Google is a big company and, like all big companies, "success" is dominated by politics.
Politics never goes away unless you're the only employee, but the ratio of politics to technical ability that defines success changes drastically the smaller the company.
Some people that don't have ability just "surf" projects. They try to stay as long as possible without contributing anything, then they find another one. I worked with people like that.
They do it because they can't do honest work that will pay comparably to their scheme.
The only way to deal with them is to not let them in.
We tried similar in my last job. Interviews were often in the 45 minute range, but similar idea.
We didn't get into deep technical questions. Rather, we asked questions meant to figure out if the person excited about the work or not. I can bring somebody up to speed on our language, but I can't train my way into curiosity or interest.
For example, we asked what source control software they'd use if they were starting a project. Ultimately I don't care what they're into, so much as that they have used something and see enough value to have an opinion to offer - even if they've only ever used one tool.
30 minutes? Not even an hour? I'm a senior and I need an hour to work my way through deep questions (not just technical) to see what real-world experience the candidate has while simultaneously judging cultural fit. I prefer an hour and a half to allow time for the candidate to feel more comfortable and come up with their own questions.
I definitely agree with the taking risks part. Hiring should not be about the most talent or experience, but the best mix of qualities (including their own personal goals) to fit what you're hiring for.
Trying to measure people is a very hard thing, especially people who are not at senior levels. IMHO, top talent can show some signs but other than that it is all about the motivation.
Given the chance, motivated people can improve at great rates.
The other thing that could matter is deep knowledge. I think I heard it from Steve Jobs, in one speech he was talking about hiring people with deep knowledge in a topic and not only because you can leverage that but because the person will know what it takes to acquire deep knowledge.
Are you using this contract with juniors?
Maybe this is a cultural difference but I would never accept a one year contract. Especially because In EU a permanent contract has a trial period in it.
This reminds me of this historian's theory that WWII generals were unusually successful because of the dynamic way they were assigned and potentially reassigned within weeks: (US Berkeley Events 2011) https://www.youtube.com/watch?v=AxZWxxZ2JGE
Same. Except, we actually hire them as a full employee, with a 90 day "probation" period. That's just the 90 days we get where we can let them go for any reason without having to pay them unemployment.
It's worked out well so far, especially for those tasked with doing the hiring.
That's completely irrelevant to the discussion. We're talking about positions for which many people will apply. You're not going to be able to eliminate enough with a 30 minute informal "chat". Honestly, I think your comment says more about how programming still isn't taken seriously in Europe to a large extent (just look at the salary gap vs US).
Very few firms want to hire juniors, while nearly all firms desire senior-level talent.
This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).
Also, because lots of software requires specific expertise, there are vacancies that can't be filled because of a knowledge gap (novel industries / projects, etc). For example, how could SpaceX possibly fill all their engineering roles? Surely money is not a limiting factor, but rather the limited supply of qualified expert rocket engineers?
Worse, many firms are put off by juniors for entirely preventable reasons. In their minds, juniors are undesirable because the moment they are trained up, they tend to jump ship for senior positions elsewhere. Why train your competition, right?
The reason they jump ship is because the firm refuses to re-evaluate them for what they are worth, and keeps them on work meant to free up the company's existing senior staff (i.e., dead-end grunt-work that results in burnout). If you, as a junior developer, want to be re-valued, you need to jump ship.
This creates a feedback loop. Companies view juniors as a cheaper developer you _might_ get 2 years of low-cost work out of (after training) before they'll leave, creating a self fulfilling prophecy.
I've watched (and experienced) this loop multiple times. It's utterly baffling how firms would rather go through the cost and drain of finding and replacing talent rather than re-evaluate and pay their existing, proven talent what they are worth on the open market.
Workers would rather not move around. Workers would rather have a stable position in a job they like, in a community where they can purchase a home and build lives and/or families. Once you get past 35, playing the required musical-chairs needed to advance your career is a real drag. It does not need to be this way.
I really disagree. These junior engineers you're talking about are mostly in their early 20's (even if they're older and switching from a different career track, they're by definition new to the industry and still have a lot to learn). In my experience, they definitely do want to move around. And even if there is a great track for internal promotions and the compensation is going to be the same whether they stay or leave, it honestly is usually in their best interest to move around every couple of years anyway early in their career. They'll meet more new people to grow their professional network faster, work on new problems, see different ways of how teams operate and what works better/worse, and gain more experience faster.
I do think that for the very top performers, most companies should probably be much more aggressive than they are. If someone is really crushing it, like in say the top 1-5% of performers, be ridiculously proactive and promote them from junior engineer to Staff Engineer within 18 months or something. I've seen a couple of people over my career that actually were performing at that level, and no external company is going to give them that big of a boost, so it's a good chance to use your inside information to be more competitive. Otherwise, for the majority of folks that are learning/advancing at a more normal pace, I don't think there's really much a company can do to keep them longer. (Not that you shouldn't even try, it's still a continuum and if you do a really bad job at career growth internally you'll lose even more people faster. But you shouldn't expect to be able to keep most people beyond 2-3 years).
Hiring Juniors is a positive externality that the company does not see a penny of. They only see a penny of that externality if they don't give a raise, and that Junior chooses to stick around anyway. You get to exploit that he made friends or is stuck in your part of the city due to a lease or otherwise makes a poor financial decision.
It's interesting that the worse the interview process, the less the Junior will want to go through it, the more the company benefits. You make your process painful so your competitors make their process painful so both of you hold onto your Juniors for more time.
If you can fix the externality problem this goes away, but that's not easy.
I work at a fairly small company that hires juniors. We pay them well, and give them more responsibility in pay as we see them improving.
Most of them still want to move on, usually to change technologies or gain more responsibility even faster.
Sometimes they want to move cities for almost random reasons, and they're willing to just find a new job and do it.
So while I somewhat agree that devs don't want to move jobs, juniors devs often do, and I think they're a lot more likely to move jobs than senior devs.
Honestly, I think having engineers come and go is a net win for companies. I've worked at places where the "old guard" has been around forever and they are inevitably stubborn, obstinate, and convinced there is no other way to solve the problem. By changing jobs and environments, you get to see in practice that there are many different ways to implement a solution. Only seeing one set of systems (unless they are a FAANG, which is large enough to have the breadth to counteract it), would ultimately cause those architectures to stagnate, injecting new blood is also injecting new ideas.
I do however, agree with your sentiment, those junior folks that are getting all the work done only get rewarded with more work to do.
It's not that they don't want to hire juniors, it's that you need a solid ratio of mentors to mentees.
I've worked at a LOT of companies, and for the more well known one, the ratio of junior resumes to seniors was easily 1000:1.
We hired entire cohorts of juniors, often interviewing HUNDREDS of them in a couple of weeks, hiring dozens. That still meant that from all the resumes we got, only a few % made it through.
What choice did we have though? We can only train mentors so fast, and hiring them is hard and expensive. You can't ask someone with 5 years of experience to train 30 people at the same time.
People often underestimate just how many people are entering the field right now, vs how many were 10-20 years ago. Add in people who EXIT the field, as well as people who are poor fits to be mentors, and it gets really dicey.
To go in line with firms not wanting to hire juniors, I think generally firms do not want to invest heavily in employee training or education. I would, for example, happily make a shift from CRUD webdev and distributed networking to hardware and embedded and more lower level type work, but I doubt a firm would hire me near my current level and train me up.
I think you hit it on the nose. Companies don't want to invest in training their new hires. They just want someone to hit the ground running with as little hand holding as possible.
The problem is likely that most people are willing to learn on the job, but then take that learning and go get a better job. A large portion of this problem is companies not being willing to increase pay to match the value you add by learning that skill, but it does lead to the doubt about bothering to train.
that is true for firms that never hire juniors. For me, I have a small team, we can only absorb a small number of juniors at any given time, because I have to have people free enough to train them up. And now, having lost most my seniors in my team to attrition, I'm hiring more mid-level developers (and hoping to find seniors)
The problem is that nobody wants to pay you intermediate/senior salary for junior ability until you learn their field. More than that, even if you volunteer to take the pay cut, they may be afraid you'll jump ship quickly, or that it's just not worth the risk of doing something unconventional.
Why would any company spend 2 years to train a junior, only for that junior to jump ship?
Oh and it's not that easy to even find a "trainable" junior. Even if you have a fairly strict hiring process, at least 1/3rds of the people coming out of the edication system will be draft busts if using sports terms
Most software positions at SpaceX, even those working on critical flight code, do not require aerospace knowledge. And SpaceX is not a great example as they hire a lot of interns and junior people willing to grind.
how are senior engineers supposed to be created if very few companies are willing to train junior engineers? Why aren't these companies offering paid apprenticeships if they are so desperate for workers?
In part because you have to jave enough sr people able to mentor. There's not a great industry framework.
As a plumber, you pay your apprentice usually 60% sr/journyman salary with a 5% increase every 6 months to match the value of the skill up.
There are also industry standard, industry funded classroom settings, that teach things like building codes and industry standards and some adjacent trade craft.
Instead you just throw a Jr to an overworked mid/Sr and they can help with some design and questions and code review but that takes 10-20 hours per week so you have to pretty much have one or more per Jr. Position. Then, after 18 months when the Jr hasn't received a 15% pay raise to reflect the enormous amount of time an knowledge you've sucked out of a Sr position, they go elsewhere for a 20% raise and it looks like you've waisted your time.
In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.
A sufficiently fast growing startup hires a lot of juniors and then due to turnover, general chaos, etc. leaves them with outsized responsibilities and little supervision. Those who “swim” in that environment are the next generation of senior engineers. It is not like you’ve been supervised for N years, you’re senior now. You get thrown into independence first and if you can hack it, the title and comp follow.
> This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).
At a lot of non-tech companies, the trick is to get hired as a consultant.
Juniors write a lot of code. Often significant amounts for a company's products and services. They're the ones who are implementing all the decisions that seniors spend their time making in all their meetings.
Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
The seniors are valuable, making decisions, coming up with solutions, building frameworks etc, but it's the juniors who then take that and run with it and build everything on top of it.
So while some will still code, it's far less than what the junior engineers are creating.
Yes they require some more training, and clear direction, but they are the ones actually creating and executing the vision of the company informed by the seniors.
What companies really want, like others have said, are senior engineers who are willing to accept a junior salary.
While of course companies would love senior engineers willing to accept a junior salary I'd say
> Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
Is actually a symptom of the shortage of senior engineers. Big companies that can afford to hire as much talent as they want actually will let seniors write code all day (my company does) because they have the economies of scale that lets them afford doing so; no one else can.
Had this happen to me at my first official dev job. Had 'junior developer' in bold at the top in my resume, application, and in several emails to the hiring manager. Got hired, and quit within 2 months. Manager would become upset at times over knowledge gaps I had as a result of being a junior, and the solution they came up with was for me to dedicate my weekends to unpaid, self-directed training.
At some point I actually reminded the manager that I was a junior, which resulted in them acting shocked and saying something to the effect of "well, let's hope that's not the case", and was basically flat out told they have no time for a junior. This was the manager who interviewed me, read my resume, and recommended me for the position.
I was replaced by a university undergrad student on summer break when I quit. I don't think people realize how the problem here often isn't you. Organizations with deep dysfunction are more common that you'd like.
Happy ending though. Got a new position the week I quit, and all turned out well.
It's because in software engineering your work product is confidential/proprietary and work samples take a very long time to produce.
If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Instead we have to simulate work samples through whiteboard coding, pair programming sessions, take home coding projects, coding knowledge tests, etc. We know that none of these methods are particularly good, so we err on the side of failing candidates when we are on the fence. They also take a long time to complete, so software engineers are reluctant to change jobs because they know how much of a pain it will be to go through interviews again.
It is much easier for product designers and product managers to pass interviews. You can see their work product.
At my company we're working on a way to create standardized coding projects that can't be faked so you can use them across job applications. If you are interested in this space, shoot me a message: robert at facet dot net.
I do something very similar and it works quite well for anyone except fresh grads (I've a different variant for them).
I pose a situation and introduce the v1 code. They look for bugs and propose fixes. Then I add on a new feature, and they look for more bugs. I've maybe 4-5 levels overall each having different classes of bugs, some of more or less subtlety. Fits on one whiteboard / single piece of paper in the end.
There are no syntax errors, just logic. Errors are in categories like: robustness, failure handling (internal or external), data/thread races, unforseen side effects, etc. The more experienced you are, the more problems I expect to be found. A "I don't know" is just fine (and often the following discussion is MORE informative).
I'm using the same technique. Taking MRs from Junior Devs together with the Ticket description, reducing the scope a bit and sprinkling different errors or incomplete implementations here and there.
In the interview, I'm checking of problems that the applicant notices and see how he approaches the problem.
So far I've been satisfied with all hired who passed that test. And they liked not having to solve stupid whiteboard problems.
> If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants.
I disagree, somewhat. In positions where I work with a medium or large team, any code of mine you reviewed would give you an idea of how the team leads want code to be written, not really how I as a candidate write code. I've often disagreed on design/architecture but was forced to go through with it because I really didn't feel like arguing and getting on the shitlist of a high-ranking engineer with influence in the company.
If you want an idea of how I would design something, it's probably best to have me write something specific to the job. I'm not talking a whiteboard red-black tree implementation, but something that is actually indicative of the work I'll be doing.
Instead we have to simulate work samples
through whiteboard coding, pair programming
sessions, take home coding projects, coding
knowledge tests, etc.
Very small sample size but we've had good results skipping coding exams entirely, and simply talking through some scenarios with candidates.
- give them a hypothetical problem ("the page is loading slowly") and role play how they'd troubleshoot it - do they understand how different bits of the stack fit together? have they ruled out network issues before digging into the code? etc.
- "tell us about a tricky technical challenge you solved"
- ask them what makes a for good code review on a pull request / what makes good code review culture in general
- ask them about things the team did well at their previous role(s) and things they'd improve, and how they'd improve upon them. (not looking for "correct" answers or opinions - but they should have some opinions)
- what are some technologies/frameworks/languages you'd like to learn next? again there's no "right" answer. but if they don't have any - red flag, right?
- etc
This of course presumes that some minimal screening has been done to make sure they're actually a software developer; an initial Fizzbuzz screen etc.
At each step of the way we discussed relevant technical bits in a natural and conversational way. For example if they mention that they "optimized" or "refactored" or "fixed" something at a previous job then naturally we ask them for the details and usually wind up swapping some stories as well.
If they passed this conversational interview, we usually extended an offer to them within 24 hours or less. Sometimes we waited longer and they got snatched up by another company.
Of course this sort of interview doesn't tell you about their work ethic and how reliable they are and so on. But, neither does a lengthy coding assignment-based process either. And the "conversational" method gives you a sense of how they'll fit in with the team.
Considering how quickly good candidates are snapped up, doing "fast" interviews like this can be a big advantage for your hiring efforts. If worst comes to worst, and they don't work out, you can part ways. It's not like either side is locked into the employment agreement. Depends on your specific locale a bit, of course -- and at my current employer we're helped by being a remote team, so it's not like we're asking folks to relocate or anything.
> - give them a hypothetical problem ("the page is loading slowly") and role play how they'd troubleshoot it - do they understand how different bits of the stack fit together? have they ruled out network issues before digging into the code? etc.
I don't know. I think I'm pretty good at troubleshooting on the job (since I can be the one to troubleshoot & solve the trickier bugs) but thinking about doing it in an interview setting makes me nervous. It feels too fickle & up to the biases of the interviewer that day, not to mention that any serious production bug relies on knowing how the software stack operates & which things are relevant, all things that are ambiguous in an interview the interviewee would just be stuck grasping in the dark to try to figure out which scenario you might be describing.
The rest seems fine, but I'm curious about your experience with the live debugging & if you've considered cutting it.
I've generally found more people flunk this sort of interview than flunk a whiteboard one.
Namely, if you've had only boring, uninteresting jobs so far, you might not have a truly interesting "tricky technical challenge you solved," and similar gaps around the other questions. Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing or...
Whereas tossing an algorithm question or two at them too to see if they can figure it out at least potentially screens for potential in a way this conversation doesn't.
So I always make sure we do both on interview loops, because I don't want to reject you just for lack of good past jobs, OR because of lack of studying algo problems recently (the good senior candidates crush the conversational one even if they're rusty on the algorithms).
As a software engineer for 20+ years, I've talked with my sister, who is an ER doctor about this often. Most folks outside of engineering think our interview processes are crazy.
Keep in mind, there's significantly more training that goes into the medical field, so there's more emphasis on the institutions. Where did you go to school? What hospitals or facilities did you work with? Your resume and references speak more strongly.
Other hurdles in software engineering hiring:
- It's both a technical and (often) a creative field.
- Most work requires teams to complete and there's very little insight into who contributed what into a project.
- You don't have many of the signals from other fields, such as published papers, law cases, or hard numbers such as sales, certifications, etc.
Long story short: we don't have good mechanisms within companies to measure engineering productivity, let alone measure programmers outside of an institution.
I'm reminded of Steve McConnell's intro to "Software Estimation":
"Meanwhile, the typical software organization is not struggling to improve its estimates from +/-10% to +/-5% accuracy. The typical software organization is struggling to avoid estimates that are incorrect by 100% or more."
No, but they have a legalized cartel to make sure there's never an over-supply (that would lower the price for the consumer, we don't want that!) that also gatekeep credentialing.
Meanwhile in Software there are initiatives for "Gender X of Minority Y can Code" and "Everyone can be an Engineer after 3 months of BootCamp".
> It is much easier for product designers and product managers to pass interviews. You can see their work product.
You don't see any more work of a product manager than of an engineer. What you see is always the finished product, and you have no idea who contributed what parts. If the overall product that can be publicly experienced is good, then some engineers in that team seem to have been doing a good job. You won't easily know which ones - and you especially don't know whether a product manager on the team really a lot of influence on this or whether the products vision and execution was mostly driven by engineers.
And the second point:
> If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Sometimes employers can - because candidates have open source code. But experience has shown that these datapoints are not used, and employers still fall back to the default process of assuming nothing and doing whiteboard/leetcode style interviews.
The top comment seemed to capture the problem best:
"What is in extremely high demand is programmers with 20 years of experience in a technology that has been around for 5, no older than 19 and working for 20k a year.
And that demand will be high, forever.
Pay more and you get more. Pay this and what you get is code monkeys that couldn't find a better employer"
This is often done to hire H1b applicants. You run the local applicants through an interview that ends up with them even if they are qualified not taking the job then go and hire the H1b that you really wanted because the H1b is then dependent upon you for staying the United States. You can now hold that over the person and anything you want they have to do like working 100 hours a week.
I saw a posting for a full stack engineer last year with a rate of $20/hour. It was temping to apply just find out what they expected. I can only think since this was a startup they were trying to "fill a seat" to look better for investors because having a higher headcount would seem impressive?
When I was trying to get my first internship it took me 160 applications to get 1 interview, before that I applied every year for ~20 internships at the big names and never got 1 interview. Similarly for my senior year I applied to full time and internship positions it took me ~145 applications to get 2 interviews for internships (I would be interning after I graduate). I did the resume prep, went to the career fairs to talk to recruiters and get feedback, went to hackathons to add to my resume, I don't feel that it really did anything. I even tried cover letters as some people on HN suggested to me.
The process seems completely random and based more on pedigree than on anything else. If you have a signal like an Ivy League school, an older friend in the industry who can refer you, or a FANG on your resume those seem to be the only ways to be picked from the sea of resumes.
IMO the only advice I can give college students trying to break into tech is to always have a tech related internship every summer no matter what. Even if you have to apply to nonprofits looking for an IT admin intern, just have a track record of work experience + having coworkers who could move on to other tech companies and give you a good referral is key. Also make sure to have a linkedin and proactively connect with your coworkers so you can later ask for referrals if you need one, don’t lose contact.
Also since I’m writing advice, don’t ever stop applying to places. You might feel demoralized after everyone gets offers and you don’t have a single one in May, or in my case getting 149 oddly similar rejection emails from different companies, but I applied to a place in June and got an interview and offer a week later its never too late and in fact you might find a company/team who also thought it was too late to get an intern for the summer.
If you can build a specialized skill set you can make things much easier. When I got out of school with no experience, no internships and a degree from a second tier state school, I still had good luck on the job hunt.
What worked for me was that I had been studying Kubernetes and was probably the cheapest guy on the market with that skillset :)
It's hard to get a job because there are a lot of charlatans out there and it's often very hard to get rid of them once hired. Even worse is hiring someone merely mediocre and not actively harmful.
That said of course the modern coding interview is I think only very loosely correlated with quality.
A team of well managed mediocre members will be less of a headache and ultimately more value to a company than a team of rockstars.
Besides all that, mediocre literally means average. You (collective) should be fine with average and stop overloading terms making general life more difficult than it needs to be.
Top talent means different things to different businesses and many people forget or don't see that. Most companies don't need and are probably actively hurt by people that would be considered top talent at Facebook or something; they need people who can churn away on boring stuff (maintenance, crud, ...), reliably and in a predictable way from 9-5, 4-5 days / week. And like that kind of job and want to do it for decades and decades on end for you; people who don't reload LinkedIn looking for 'new challenges with the latest framework' 20x a day. I would like to hire almost only 'top talent' like that. I like to have 1-2 top performers that 'could've or did' work for Google etc but the rest, no; it's actually risky to have those people in that position because they get bored too quickly, job hop, like new things too much, want to redo stuff they think is badly done etc. Money is not really a thing that binds them either (maybe if you go crazy town, but who besides the FAANGs can pay that?): I had people walk off that were paid US wages in Spain by us (work from home, before covid) because they 'found a more interesting opportunity for their career'. That's not top talent to me.
Edit: and that similarly goes for how you define mediocre; I think my toptalents are your mediocre. I'll have your mediocre please!
This is a talent strategy at some companies (mine included). Our business model simply doesn’t allow us to compete for the “top” engineers. Our best engineers have been people who are just general technologists dabbling in solo projects within the business side of a corporate or working as the lone IT person at a small business. They have enough of the fundamentals to hit the ground running and learn quickly, but not enough experience to attract the big offers.
Are they mediocre developers? Yeah, absolutely. But under the right guidance they can absolutely be valuable to a company, and our turnover tends to be low because we have a 9-5 culture. It’s less about being a mediocre company versus a company that can’t compete for talent on price, so our talent strategy is to keep it a nice place to work so people want to stay.
I think the thing is there are a certain core number of critical things a business has to do where if they are continually messed up it’ll go out of business eg payrolls, strategy around capital expenditure etc. The issue might be that even small business involved in e-commerce mean cross over with these areas. For example storing sensitive data is dangerous. PHI/PII is digital toxic waste. Like with real toxic waste do you want trained experienced professionals or inexperienced charlatans.
> "I get the feeling that mediocre business should be able to run just fine on mediocre people."
The mediocre app/system quality and performance and mediocre security for customer and business data that results creates a (sub-)mediocre customer experience.
Most developers are mediocre, no way around that. And every developer was bad and mediocre before he became better. Companies that don't invest in employees don't really deserve performance anyway. Exception might be start-ups though, developers need to adjust expectations especially around pay.
I have seen enough software projects that certainly didn't fail because the devs lacked ability, there was always another reason and mainly that is leadership not knowing about the problem they try to solve.
A bit of an exception might be more artistic topics like video games. Here marketing and chance play a larger role than management.
Sure, maybe you do cutting edge research, here ability is important again, but that is truly exceptional.
That said, I don't think it is hard to get a job currently.
Because a person's worth is directly tied to how much value they can produce for their company's shareholders.
And if someone mediocre ends up being able to do the job, the company's management may face the fact that they're just a bunch of lame yuppies spending their life in the office to make someone else richer, not changing the world/making the world a better place/any other bullshit eaten from the trashcan of ideology (sniffff).
> For obvious statistical reasons most companies [...] are mediocre
That's assuming companies exist on a one dimensional spectrum. The more prevailing wisdom is that companies will be mediocre or bad at many things, and good at a couple of particular things, and those couple of things are what make the company viable. This is the essence of a "unique selling point".
But to the point: most companies don't need great developers. Nowdays most medium sized businesses employ some tech staff, but IT is not core to their business.
Instinctively, they know it. The old cult of management-as-a-profession believes that by skillfully directing the activities of replaceable cogs, a company's managers can achieve outsized results.
But they can't admit it because they're afraid that knowledge would demotivate the replaceable cogs.
What's the "modern coding interview" trying to achieve? The other day, a guy showed me a 30-line convoluted, deeply-nested, redundant, and contradictory conditional statement and then rolled his eyes at me when I took longer than 5 minutes to parse it. Maybe I'm slower, but my quality is just fine.
Sounds like the purpose of that interview was to stroke the interviewer's ego. You should have asked him if that was his code, or was that code in production, then rolled your eyes back and left.
On top of this, it’s hard to select for qualified people because the vast majority of interviewees are terrible candidates. Truly qualified job applicants get callbacks for (almost) every job they apply for, choose to interview at a few select companies, and get offers from most of the places they interview at. Thus, they’re only briefly in the interview pool. On the other hand, unqualified people are constantly getting rejected at every step of the process, and must continually re-insert themselves into the interview pool, and thus comprise the vast majority of interviewees.
Because of this, the interview process is not designed to efficiently handle a minority of qualified candidates, but rather efficiently weed out a majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it.
>it's often very hard to get rid of them once hired
Every state in the US is an "at will" state, meaning a company can fire you with no reason as long as it isn't discriminatory towards a protected demographic.
I wouldn't be surprised if most of those states have laws for unfair dismissal as well. Companies develop an internal process to cover their backs for such eventualities. Running that process to the end is the costly bit.
Even with at will, the company can get into difficulty with unfair dismissal and other issues.
The few times I've seen someone fired (and fired fired not PIP or layoff) have been for clear and undeniable issues. The "your work isn't up to performance standards" without a PIP falls into the rare bucket (and more likely at the small companies than the larger ones).
Those who want someone removed are usually not the people empowered to remove someone.
Even complaining to their manager (which is often a bad move) usually wont result in the removal of that person
I assume the logic is that, at many/most places, the charlatan may actually be let go if they really don't work out whereas the person who is just "OK" will be allowed to cruse along indefinitely. Most companies aren't pro sports teams.
There’s a tonne of variance between software engineers. Even at the same level (junior, intermediate, senior, etc.), it’s not uncommon for a strong hire to be ~5x better than a weak hire. By this I mean more productive, better at helping others, writes fewer bugs, creates more maintainable abstractions, makes better architecture decisions, can tackle more difficult problems, etc. And at the same level, the strong and weak hires get paid roughly the same, so companies REALLY want the strong hires. This is not a McDonalds type situation, where anyone lightly competent will do, you’re trying to hire someone outstanding at their job every single time.
Firing sucks, but it’s hard to truly tease out quality during interviews. So most companies go for false negatives over false positives. Generally this means that of the 3-to-6 interviewers, all have to have strong positive opinions of the candidate for the hire to happen.
Because of this, as a candidate, it’s a bit of a number’s game. You can be a great candidate, but still not get hired on any individual interview, because companies heavily bias towards allowing lots of false negatives to avoid the odd false positive.
> hard to truly tease out quality during interviews
I'm not sure I agree here. I doubt most interviewers have actually given much thought to what they are actually trying to look for in a potential candidate. The widespread practice of over-focusing on algorithmic whiteboard questions is a symptom.
There's got to be better processes in assessing candidates' qualities beyond solving algorithmic puzzles (which perhaps is 5% of a software engineer's job at best).
I dunno, I’ve conducted about 100 dev interviews over the years. Have tried various combinations of whiteboarding, architecture/design questions, take home problems, talking about past projects/experience, and sitting down together with the interviewee and pair coding on bugs or small features. I don’t know that any approach was clearly more effective than another, and for all of them I think the ability of myself and other interviewers to predict performance at the company was decent, but far from excellent. The clearest signal is probably a super enthusiastic referral (from a highly trustworthy source), but it’s rare to be able to get that.
It’s just really tough to figure out in 2-3 hours how someone is going to perform in a given role over the next few years. Interviewing is an inexact art, not an exact science, and it’s very much my experience that companies compensate for this by favouring false negatives (not hiring possibly strong candidates) over false positives (hiring weak candidates).
The 5x engineer at my last job created 5x the features and 5x the bugs, and consequently caused 5x the number of job postings because we needed so many people to put out fires all day. I have to thank him because he is the reason I was hired.
Yeah, I don’t mean just 5x the LOC or features. More a combination of all of more productive, helps others more effectively, creates fewer bugs, can tackle a wider range of problems, makes better architectural decisions, writes more materials abstractions, etc. Basically I think it’s pretty common for a strong engineering hire to produce 5x the long term value of a weak hire, taking all of the above into account.
Readit News
I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups. That includes hiring countless developers, so I get both sides of the situation. And my partner is also a tech recruiter for a top tier HFT / market maker, so I know what a demanding but respectful hiring process looks like.
Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs. And a year later the role is still open.
When the interview was over I thought, "Is this how working with these guys is going to be?" If I ran into a problem and went to them for help, would they just stare at me, waiting for me to figure it out on my own?
They didn't extend an offer to me and, based on my performance in that interview, I can't say I blame them. I'm not sure I would have accepted if they had, however. That experience really left me with a bad taste in my mouth and a low impression of that company.
We as an industry really REALLY need to figure out a better way of conducting interviews.
As an interviewer your two objectives are:
1. Ensure the candidate has an excellent experience
2. Collect data points
In that order. Sometimes we run into candidates who make the second item difficult. They fail to complete the specific technical problem. They can't speak about their experiences in detail. We need to drag data out of them screaming. It doesn't matter, your priority is to ensure they feel respected, and leave thinking they WANT to work there.
https://alexgolec.dev/reddit-interview-problems-the-game-of-...
It's too bad your experience was so negative. That's going to be a datapoint in my mental dataset of companies to consider when the time comes.
And from a completely non-technical persons perspective Reddit is incredibly disorganized at the executive management and corporate level. The amount of turnover, controversy, business model revamps, etc. for a 16 year old company with the hype they have is unique and unprecedented. It's not surprising whatsoever that their hiring practices are similarly disjointed.
I come in. The front-end guy starts asking me questions to try and solve something he is working on. No-one else is there yet. He is asking me about why a JS compiler is removing his comments, I say I don't know, I have never had that issue before...I make an off-hand comment that I use React and most of my JS code doesn't have comments because I am just working on projects by myself, and I don't do a lot of library code...the manager comes in at this point, and proceeds to berate me about why commenting is essential. I say: I use comments where they are needed. Off he goes, again.
Interview starts. Manager proceeds to go through a series of questions designed to expose my ignorance. None of which are related to the job. One classic was him explaining to me that database normalization made no difference to the size of the database because "the data is all the same on the disk" (which is, ofc, not accurate...I tried to explain, he just kept repeating that over and over...he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin). For some reason, there was also a back-end guy there who, upon hearing that I built something in Java, proceeded to launch into a series of questions on internals of Java (for example, he asked me what the difference was between certain versions of Java and the size of the heap...perhaps unsurprisingly, he also got some of this stuff wrong but began laughing when I said I thought X was Y).
The only two questions that I had about front-end dev were: the front-end guy trying to ask me to help solve an issue he was having (before the interview, when no-one was there), and a question about the value of this in arrow functions (which I got wrong, but is also an excruciating thing to try and explain, so I don't think the guy knew whether I got it wrong...it is a terrible question). That was it.
It was quite weird.
I thought I nailed their code challenge and expected to continue through the process, but after that session that was pretty much the last I heard from them. It was pretty disappointing.
Do you want a pat on the back or something?
I had an technical interview with a company early last week, we did a shared session using VS Code. The interviewer wrote the function signature, and I filled out the implementation. I did great, according to the interviewer, and moved to the next set of interviews.
The next interviewer, which turned out was also technical, ended up opening up a shared Google Docs to write code it. I asked if I could just share my screen in my own editor, but they couldn’t give me permissions to do that. I was given an extremely vague question. When I asked questions, he told me to stop because he was holding out for next iterations of my implementation (again, in a Google Docs). Given no structure and an absurd environment, I completely bombed it. And to top it off, instead of getting an email saying they were not interested in me, they just ghosted me all together. A complete waste of time. I wish them luck in their endeavor to find the best engineer to write code in Google Docs, since that is apparently what they are interviewing for.
it was like sitting in a confusing nightmare for an hour
I really dislike when companies do this. It's very time consuming and psychologically/emotionally draining.
My focus is security, and so the second time around I got Travis Ormandy as an interviewer. I was able to impress him well enough with my IPSec foo to make it onsite. Then I got asked a question I had already been asked in another interview with another company, and I was able to knock that out of the ballpark (I mentioned I already knew that question, but the interviewer wanted me to answer it anyway). Then I got asked a question that used recursion, and because I took a graduate course on induction and recursion within the past year, that was effortless for me. Then I got asked a question that involved a kernel feature, and because I happened to recall the Linux kernel list macros and semantics (something I couldn’t repeat now over 10 years later), I really impressed that interviewer.
I ended up having a really successful part of my career at Google, even though I ended up not really writing much code when all was said and done. However what code I did write was highly impactful.
Looking back, things could have gone very differently if I had gotten a different set of interviewers and/or questions. The questions I got just happened to coincide with what was “paged in” to my “working memory,” so to speak.
I've never even heard of a Bloom filter, so I know how I would have done.
Dead Comment
I've ran into "OMG he didn't know that!" responses when one dev disapproves of a candidate. Inevitably I ask "Really how often do you need to know that? and if you needed to wouldn't you just google it and be done?" but we assume it means so much more and there you go.
Then someone else gets hired and they knew the trivia, but can't apply it or worse only really knew the answer and not the ramifications... or they just can't wrap their mind around / don't care to think of second order effects or whatever.
These results may be "curved".
If you give the same easy test with no pressure and everyone is sufficiently good, then it was a waste of everyone's time.
In such an approach, you do something that is sufficiently hard that you're able to identify the people who are the better performing ones along with a reasonable idea of how well they work under pressure (because that will happen at some point).
Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).
This is more a random fluke as much as sampling bias. Akin to someone either getting lucky or someone who is coming from a very similar environment. This isn’t a measurement that guarantees someone is competent, rather it’s a guarantee that someone is coming from just as incompetent an environment as you have.
Am I on the top of my game right then and not stressed about anything and the questions out of the random million possible questions that could come up are ones that I just happen to have had on my mind recently? Then I ace the interview.
The last time that happened it was in a big international consulting company, they then put me through 5 other interviews afterwards, each one telling me I would hear something back in the next couple days.
The last one I got told couple more days, they didn't call me back for nearly two weeks. Then they call: Hey Bryan, we would complete the offer process now hope you're still interested?
Uhm unfortunately I got an offer last week for a 6 month consulting project, sorry but I had to take it because they said they couldn't wait to see how this turned out.
on edit: clarification.
In many other fields (medicine, law) people study a standardized body of knowledge, take a standard test and then get a license so they can do something others cannot.
However, this doesn't prevent a lot of awful and a lot of great people getting through. You would still need to interview a lot of them. I wonder if it sets a minimal level.
I assume it actually works pretty well but there's obviously a huge amount of gatekeeping involved.
Someday soon we may accept that what gets classified as software engineering is actually an amalgamation of skills from an entirely different set of titles/careers, most of which treat software creation and management as a tool and means to an end.
I don't generally consider a blacksmith and a welder to be the same occupations. You can lump them under metalworker, but would you really expect the interview process for these roles to be at all similar?
Or, why did the screen just scroll down and lose my place in the paragraph? Oh, they loaded an ad in the middle of the document and the page re-rendered itself causing jerks and fits on the screen. Nice job FAANG site!
Or try performing a sort of items by price or whatever other criteria … doesn’t work because the website wants the user to see the “suggested” items no matter what search criteria was desired y the user.
And …
I mean, we have things like the SWEBOK (https://www.computer.org/education/bodies-of-knowledge/softw...) that could be used to build a set of interview questions and acceptable responses, but does anyone use it for that?
The best interviews I've had, either as the interviewer or the candidate, have been when there was a discussion and a free flow of information in both directions. Unfortunately, it seems that in a lot of places, this degrades quickly into a hazing ritual.
He asked five or six questions related to C and C++ undefined behaviour, a very open-ended one about a technology I'd never used. I answered as best I can, but always opened with "I'd be referring back to the C standard and opening a JIRA task to fix the code". We got on to how I'd fix the code -- remove the UB, but only if there's a unit test covering it. What if there are no unit tests? What if there's no JIRA? Lots of what-if-maybes.
A few days later I was on a 3-way call with the recruiter and one of the guys that interviewed me. They spent the whole thing telling me how "any decent developer" should have known what the UB would result in, shouldn't have to refer to standards or books... and on and on. But as a courtesy, they'd be happy to make an offer.
Half the minimum posted salary, no benefits. It was right in the middle of the minimum wage and the "living wage" lines.
I declined politely, and the recruiter hung on the call...
"Wow. I don't know what to say. That's never happened before... do you mind if I share the recording of that call with my manager?"
They were still advertising to fill several positions when I last stumbled across them on Glassdoor a few months ago...
I haven't participated in technical interviews in a long time, but when I was asked to do it, I made it a point to throw as many lifelines as I could until I got a satisfying answer. For instance, if want to know if the person understands generics and they can't answer the question outright then I'll ask them about C++ templates. Similarly, if someone can't describe the term "idempotence" I'll ask them "can you tell me what makes a function pure".
Mind you those terms aren't interchangeable but if you catch one it should be trivial to understand the latter.
Becoming a specialized divorce lawyer still requires you to pass certification on things like criminal law and constitutional law (among many other things), you won't be permitted to practice law if you know just your specialty, no matter how well you know it.
Becoming a heart surgeon still requires you to pass certification on pharmacology and gynecology (among many other things), you won't be permitted to practice medicine if you just know your specialty, no matter how well you know it.
But for software workers we do accept that you can ignore many related (and even relevant) fields and just learn only one niche of technology - we could make an all-encompassing bar, but it would be a major change and I'm not sure if we would want that.
Deleted Comment
They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I started in this field in 1997. The interviews were more old fashioned, a few tech questions, see if you were an oddball, then they'd get back to you. If you didn't work out, they would just fire you. Pretty simple.
Not all CS degrees are created equal I'm afraid.
I’ve interviewed many people with 4 year CS degrees who can’t really code. I’m not sure how this happens, but it definitely does. I disagree that having a CS degree should excuse candidates from coding interviews.
If it's not enough for an employer, it's because that employer devalues what's taught in most CS programs. Granted, there's a significant mismatch between CS degree work and real world work, but that's true in lots of engineering. Ask any engineer in whatever subfield how much time they spend solving differential equations. I mean, great that I learned how to balance a binary tree and write a heapsort in my DS&A class, but have I ever needed to do that at work? Other than to pass some stupid coding interview?
Deleted Comment
Deleted Comment
In other words, there flipside of what you said is that sometimes you'll excel and be offered the job on very attractive terms.
Dead Comment
Credentialing organizations already exist[1], but none have lobbied the US government to prevent the uncredentialed from practicing.
Perhaps it's time. If none of the existing orgs are good enough, start a new one.
1. https://www.computer.org/product/education/professional-soft...
https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...
Sometimes, people who you think are not capable to do the job, often outperform expectations too. It is all about taking a risk on a person and giving them respect and a chance. We could have done leetcode, or pair programming session. It takes more energy and effort to do it from both sides and probability of finding a good candidate is more or less the same.
Contract work is a great way to find good talent, but it's a different candidate pool. Lots of good candidates can't or won't give up their full time jobs to take a time-limited contract job.
Those who can take contract work are often more talented and more in demand, meaning they're less worried about finding another job if the contract isn't renewed. Contract work (without benefits) is not an option for a large number of developers.
Probably should be...? You're typically getting paid more because of "no benefits". (I HATE the word 'benefits', FWIW).
Buy your own health insurance - it's more accessible in the US via ACA. Yeah, you might miss out on some 401k matching. Save it yourself?
I think everyone, employers and employees get too caught up in requirements and forget that humans are very general purpose. And in particular, highly capable and intelligent humans can rapidly acquire skills.
In particular, if you are hiring someone for a potentially lengthy career, capacity for change seems incredibly more important than immediate skill.
With a traditional interview and job offer process, a new employee can ramp up without worrying their job is on the line. And I think this is important, because it can take awhile to ramp up to full productivity, which can be stressful if the new employee feels like they're being evaluated already.
Where I've worked, my new manager told me "Hey, welcome to the company. Please feel relaxed and take your time ramping up, you've already passed the interview and we're happy to have you here."
With your process, how do you deal with people getting stressed out during ramp up or feeling imposter syndrome?
1) Wow, very interesting company. I didn't know so many things can be done in different ways than I'm used to. Very smart ideas out there.
2) OMG, this company is full with idiots. Everything is done the wrong way but somehow it has not collapsed yet.
3) Yeah okay, some stuff is the way it is because it would't be feasible any other way due to the quirks of the business. Other things are the way it is because of historical reasons and it doesn't make sense to re-do it at the moment.
4) You know what, I think I understand what this company is all about. It's not perfect but people are actually doing great things here.
5) OMG, this business is crime against humanity. It shouldn't exist, I don't know how I'm supposed to do this anymore. Money can't buy me.
6) Well, the world is not perfect and I understand the imperfections and I can function. It's not like they are doing it any better anywhere else. I grew to appreciate upper management, now I understand our business and I'm happy to do my part.
3 months should be enough for a nice honeymoon stage. Both sides can know that longterm relationship is achievable if they have a nice honeymoon stage.
> "Google originally set its hiring algorithms to sort for computer science students with top grades from elite science universities. In 2013, Google decided to test its hiring hypothesis by crunching every bit and byte of hiring, firing, and promotion data accumulated since the company’s incorporation in 1998. Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills ..."
> "Project Aristotle analyzes data on inventive and productive teams. Google takes pride in its A-teams, assembled with top scientists, each with the most specialized knowledge and able to throw down one cutting-edge idea after another. Its data analysis revealed, however, that the company’s most important and productive new ideas come from B-teams comprised of employees who don’t always have to be the smartest people in the room. Project Aristotle shows that the best teams at Google exhibit a range of soft skills ..."
Source: The surprising thing Google learned about its employees — and what it means for today’s students - https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...
Politics never goes away unless you're the only employee, but the ratio of politics to technical ability that defines success changes drastically the smaller the company.
They do it because they can't do honest work that will pay comparably to their scheme.
The only way to deal with them is to not let them in.
We didn't get into deep technical questions. Rather, we asked questions meant to figure out if the person excited about the work or not. I can bring somebody up to speed on our language, but I can't train my way into curiosity or interest.
For example, we asked what source control software they'd use if they were starting a project. Ultimately I don't care what they're into, so much as that they have used something and see enough value to have an opinion to offer - even if they've only ever used one tool.
I definitely agree with the taking risks part. Hiring should not be about the most talent or experience, but the best mix of qualities (including their own personal goals) to fit what you're hiring for.
Could you expand on how do you evaluate the cultural fit?
Given the chance, motivated people can improve at great rates.
The other thing that could matter is deep knowledge. I think I heard it from Steve Jobs, in one speech he was talking about hiring people with deep knowledge in a topic and not only because you can leverage that but because the person will know what it takes to acquire deep knowledge.
It's worked out well so far, especially for those tasked with doing the hiring.
Deleted Comment
This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).
Also, because lots of software requires specific expertise, there are vacancies that can't be filled because of a knowledge gap (novel industries / projects, etc). For example, how could SpaceX possibly fill all their engineering roles? Surely money is not a limiting factor, but rather the limited supply of qualified expert rocket engineers?
The reason they jump ship is because the firm refuses to re-evaluate them for what they are worth, and keeps them on work meant to free up the company's existing senior staff (i.e., dead-end grunt-work that results in burnout). If you, as a junior developer, want to be re-valued, you need to jump ship.
This creates a feedback loop. Companies view juniors as a cheaper developer you _might_ get 2 years of low-cost work out of (after training) before they'll leave, creating a self fulfilling prophecy.
I've watched (and experienced) this loop multiple times. It's utterly baffling how firms would rather go through the cost and drain of finding and replacing talent rather than re-evaluate and pay their existing, proven talent what they are worth on the open market.
Workers would rather not move around. Workers would rather have a stable position in a job they like, in a community where they can purchase a home and build lives and/or families. Once you get past 35, playing the required musical-chairs needed to advance your career is a real drag. It does not need to be this way.
I really disagree. These junior engineers you're talking about are mostly in their early 20's (even if they're older and switching from a different career track, they're by definition new to the industry and still have a lot to learn). In my experience, they definitely do want to move around. And even if there is a great track for internal promotions and the compensation is going to be the same whether they stay or leave, it honestly is usually in their best interest to move around every couple of years anyway early in their career. They'll meet more new people to grow their professional network faster, work on new problems, see different ways of how teams operate and what works better/worse, and gain more experience faster.
I do think that for the very top performers, most companies should probably be much more aggressive than they are. If someone is really crushing it, like in say the top 1-5% of performers, be ridiculously proactive and promote them from junior engineer to Staff Engineer within 18 months or something. I've seen a couple of people over my career that actually were performing at that level, and no external company is going to give them that big of a boost, so it's a good chance to use your inside information to be more competitive. Otherwise, for the majority of folks that are learning/advancing at a more normal pace, I don't think there's really much a company can do to keep them longer. (Not that you shouldn't even try, it's still a continuum and if you do a really bad job at career growth internally you'll lose even more people faster. But you shouldn't expect to be able to keep most people beyond 2-3 years).
It's interesting that the worse the interview process, the less the Junior will want to go through it, the more the company benefits. You make your process painful so your competitors make their process painful so both of you hold onto your Juniors for more time.
If you can fix the externality problem this goes away, but that's not easy.
Most of them still want to move on, usually to change technologies or gain more responsibility even faster.
Sometimes they want to move cities for almost random reasons, and they're willing to just find a new job and do it.
So while I somewhat agree that devs don't want to move jobs, juniors devs often do, and I think they're a lot more likely to move jobs than senior devs.
I do however, agree with your sentiment, those junior folks that are getting all the work done only get rewarded with more work to do.
It's not that they don't want to hire juniors, it's that you need a solid ratio of mentors to mentees.
I've worked at a LOT of companies, and for the more well known one, the ratio of junior resumes to seniors was easily 1000:1.
We hired entire cohorts of juniors, often interviewing HUNDREDS of them in a couple of weeks, hiring dozens. That still meant that from all the resumes we got, only a few % made it through.
What choice did we have though? We can only train mentors so fast, and hiring them is hard and expensive. You can't ask someone with 5 years of experience to train 30 people at the same time.
People often underestimate just how many people are entering the field right now, vs how many were 10-20 years ago. Add in people who EXIT the field, as well as people who are poor fits to be mentors, and it gets really dicey.
Oh and it's not that easy to even find a "trainable" junior. Even if you have a fairly strict hiring process, at least 1/3rds of the people coming out of the edication system will be draft busts if using sports terms
Is this a euphemism for an employer overworking and underpaying their talent?
how are senior engineers supposed to be created if very few companies are willing to train junior engineers? Why aren't these companies offering paid apprenticeships if they are so desperate for workers?
As a plumber, you pay your apprentice usually 60% sr/journyman salary with a 5% increase every 6 months to match the value of the skill up.
There are also industry standard, industry funded classroom settings, that teach things like building codes and industry standards and some adjacent trade craft.
Instead you just throw a Jr to an overworked mid/Sr and they can help with some design and questions and code review but that takes 10-20 hours per week so you have to pretty much have one or more per Jr. Position. Then, after 18 months when the Jr hasn't received a 15% pay raise to reflect the enormous amount of time an knowledge you've sucked out of a Sr position, they go elsewhere for a 20% raise and it looks like you've waisted your time.
In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.
At a lot of non-tech companies, the trick is to get hired as a consultant.
Juniors write a lot of code. Often significant amounts for a company's products and services. They're the ones who are implementing all the decisions that seniors spend their time making in all their meetings.
Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
The seniors are valuable, making decisions, coming up with solutions, building frameworks etc, but it's the juniors who then take that and run with it and build everything on top of it.
So while some will still code, it's far less than what the junior engineers are creating.
Yes they require some more training, and clear direction, but they are the ones actually creating and executing the vision of the company informed by the seniors.
What companies really want, like others have said, are senior engineers who are willing to accept a junior salary.
> Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
Is actually a symptom of the shortage of senior engineers. Big companies that can afford to hire as much talent as they want actually will let seniors write code all day (my company does) because they have the economies of scale that lets them afford doing so; no one else can.
Wait, not even that.
Even if you are senior you can get that job (because, for example, you are from another country and suddenly you are "cheap" even if senior).
That's a red flag. Because we all know the top of the market, no matter where, is working at SV rates.
Or many firms want to hire senior-level talent at junior-level prices.
Also why companies will hire someone with 3 years of experience into a senior position.
At some point I actually reminded the manager that I was a junior, which resulted in them acting shocked and saying something to the effect of "well, let's hope that's not the case", and was basically flat out told they have no time for a junior. This was the manager who interviewed me, read my resume, and recommended me for the position.
I was replaced by a university undergrad student on summer break when I quit. I don't think people realize how the problem here often isn't you. Organizations with deep dysfunction are more common that you'd like.
Happy ending though. Got a new position the week I quit, and all turned out well.
If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Instead we have to simulate work samples through whiteboard coding, pair programming sessions, take home coding projects, coding knowledge tests, etc. We know that none of these methods are particularly good, so we err on the side of failing candidates when we are on the fence. They also take a long time to complete, so software engineers are reluctant to change jobs because they know how much of a pain it will be to go through interviews again.
It is much easier for product designers and product managers to pass interviews. You can see their work product.
At my company we're working on a way to create standardized coding projects that can't be faked so you can use them across job applications. If you are interested in this space, shoot me a message: robert at facet dot net.
This helps us look for good signal around their communication skills, mentoring skills, empathy, reasoning skills and software development skills.
We used this review as a diagnostic - there are no wrong answers since we know they’re not aware of our style guide and conventions.
It worked for us. Maybe it could work for others.
I pose a situation and introduce the v1 code. They look for bugs and propose fixes. Then I add on a new feature, and they look for more bugs. I've maybe 4-5 levels overall each having different classes of bugs, some of more or less subtlety. Fits on one whiteboard / single piece of paper in the end.
There are no syntax errors, just logic. Errors are in categories like: robustness, failure handling (internal or external), data/thread races, unforseen side effects, etc. The more experienced you are, the more problems I expect to be found. A "I don't know" is just fine (and often the following discussion is MORE informative).
In the interview, I'm checking of problems that the applicant notices and see how he approaches the problem.
So far I've been satisfied with all hired who passed that test. And they liked not having to solve stupid whiteboard problems.
Thanks for sharing.
I disagree, somewhat. In positions where I work with a medium or large team, any code of mine you reviewed would give you an idea of how the team leads want code to be written, not really how I as a candidate write code. I've often disagreed on design/architecture but was forced to go through with it because I really didn't feel like arguing and getting on the shitlist of a high-ranking engineer with influence in the company.
If you want an idea of how I would design something, it's probably best to have me write something specific to the job. I'm not talking a whiteboard red-black tree implementation, but something that is actually indicative of the work I'll be doing.
- give them a hypothetical problem ("the page is loading slowly") and role play how they'd troubleshoot it - do they understand how different bits of the stack fit together? have they ruled out network issues before digging into the code? etc.
- "tell us about a tricky technical challenge you solved"
- ask them what makes a for good code review on a pull request / what makes good code review culture in general
- ask them about things the team did well at their previous role(s) and things they'd improve, and how they'd improve upon them. (not looking for "correct" answers or opinions - but they should have some opinions)
- what are some technologies/frameworks/languages you'd like to learn next? again there's no "right" answer. but if they don't have any - red flag, right?
- etc
This of course presumes that some minimal screening has been done to make sure they're actually a software developer; an initial Fizzbuzz screen etc.
At each step of the way we discussed relevant technical bits in a natural and conversational way. For example if they mention that they "optimized" or "refactored" or "fixed" something at a previous job then naturally we ask them for the details and usually wind up swapping some stories as well.
If they passed this conversational interview, we usually extended an offer to them within 24 hours or less. Sometimes we waited longer and they got snatched up by another company.
Of course this sort of interview doesn't tell you about their work ethic and how reliable they are and so on. But, neither does a lengthy coding assignment-based process either. And the "conversational" method gives you a sense of how they'll fit in with the team.
Considering how quickly good candidates are snapped up, doing "fast" interviews like this can be a big advantage for your hiring efforts. If worst comes to worst, and they don't work out, you can part ways. It's not like either side is locked into the employment agreement. Depends on your specific locale a bit, of course -- and at my current employer we're helped by being a remote team, so it's not like we're asking folks to relocate or anything.
I don't know. I think I'm pretty good at troubleshooting on the job (since I can be the one to troubleshoot & solve the trickier bugs) but thinking about doing it in an interview setting makes me nervous. It feels too fickle & up to the biases of the interviewer that day, not to mention that any serious production bug relies on knowing how the software stack operates & which things are relevant, all things that are ambiguous in an interview the interviewee would just be stuck grasping in the dark to try to figure out which scenario you might be describing.
The rest seems fine, but I'm curious about your experience with the live debugging & if you've considered cutting it.
I have so much trouble remembering previous challenges I've overcome. I don't ruminate on them, I just move on...
Namely, if you've had only boring, uninteresting jobs so far, you might not have a truly interesting "tricky technical challenge you solved," and similar gaps around the other questions. Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing or...
Whereas tossing an algorithm question or two at them too to see if they can figure it out at least potentially screens for potential in a way this conversation doesn't.
So I always make sure we do both on interview loops, because I don't want to reject you just for lack of good past jobs, OR because of lack of studying algo problems recently (the good senior candidates crush the conversational one even if they're rusty on the algorithms).
As a software engineer for 20+ years, I've talked with my sister, who is an ER doctor about this often. Most folks outside of engineering think our interview processes are crazy.
Keep in mind, there's significantly more training that goes into the medical field, so there's more emphasis on the institutions. Where did you go to school? What hospitals or facilities did you work with? Your resume and references speak more strongly.
Other hurdles in software engineering hiring:
- It's both a technical and (often) a creative field.
- Most work requires teams to complete and there's very little insight into who contributed what into a project.
- You don't have many of the signals from other fields, such as published papers, law cases, or hard numbers such as sales, certifications, etc.
Long story short: we don't have good mechanisms within companies to measure engineering productivity, let alone measure programmers outside of an institution.
I'm reminded of Steve McConnell's intro to "Software Estimation":
"Meanwhile, the typical software organization is not struggling to improve its estimates from +/-10% to +/-5% accuracy. The typical software organization is struggling to avoid estimates that are incorrect by 100% or more."
Meanwhile in Software there are initiatives for "Gender X of Minority Y can Code" and "Everyone can be an Engineer after 3 months of BootCamp".
> It is much easier for product designers and product managers to pass interviews. You can see their work product.
You don't see any more work of a product manager than of an engineer. What you see is always the finished product, and you have no idea who contributed what parts. If the overall product that can be publicly experienced is good, then some engineers in that team seem to have been doing a good job. You won't easily know which ones - and you especially don't know whether a product manager on the team really a lot of influence on this or whether the products vision and execution was mostly driven by engineers.
And the second point:
> If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Sometimes employers can - because candidates have open source code. But experience has shown that these datapoints are not used, and employers still fall back to the default process of assuming nothing and doing whiteboard/leetcode style interviews.
The top comment seemed to capture the problem best:
"What is in extremely high demand is programmers with 20 years of experience in a technology that has been around for 5, no older than 19 and working for 20k a year.
And that demand will be high, forever.
Pay more and you get more. Pay this and what you get is code monkeys that couldn't find a better employer"
The process seems completely random and based more on pedigree than on anything else. If you have a signal like an Ivy League school, an older friend in the industry who can refer you, or a FANG on your resume those seem to be the only ways to be picked from the sea of resumes.
The best way to get an interview if you didn’t go to Stanford or MIT (I didn’t) and haven’t yet worked at a famous company is to get a referral.
Which requires somehow making a friend or connection with someone at the place you want to be.
Also since I’m writing advice, don’t ever stop applying to places. You might feel demoralized after everyone gets offers and you don’t have a single one in May, or in my case getting 149 oddly similar rejection emails from different companies, but I applied to a place in June and got an interview and offer a week later its never too late and in fact you might find a company/team who also thought it was too late to get an intern for the summer.
What worked for me was that I had been studying Kubernetes and was probably the cheapest guy on the market with that skillset :)
That said of course the modern coding interview is I think only very loosely correlated with quality.
Of course, every business likes to pretend they're the top and can only hire top talent.
Besides all that, mediocre literally means average. You (collective) should be fine with average and stop overloading terms making general life more difficult than it needs to be.
Edit: and that similarly goes for how you define mediocre; I think my toptalents are your mediocre. I'll have your mediocre please!
Are they mediocre developers? Yeah, absolutely. But under the right guidance they can absolutely be valuable to a company, and our turnover tends to be low because we have a 9-5 culture. It’s less about being a mediocre company versus a company that can’t compete for talent on price, so our talent strategy is to keep it a nice place to work so people want to stay.
The mediocre app/system quality and performance and mediocre security for customer and business data that results creates a (sub-)mediocre customer experience.
Dead Comment
I have seen enough software projects that certainly didn't fail because the devs lacked ability, there was always another reason and mainly that is leadership not knowing about the problem they try to solve.
A bit of an exception might be more artistic topics like video games. Here marketing and chance play a larger role than management.
Sure, maybe you do cutting edge research, here ability is important again, but that is truly exceptional.
That said, I don't think it is hard to get a job currently.
What's so bad about... mediocrity? For obvious statistical reasons, most companies, most jobs, and most people are mediocre (or worse).
And if someone mediocre ends up being able to do the job, the company's management may face the fact that they're just a bunch of lame yuppies spending their life in the office to make someone else richer, not changing the world/making the world a better place/any other bullshit eaten from the trashcan of ideology (sniffff).
That's assuming companies exist on a one dimensional spectrum. The more prevailing wisdom is that companies will be mediocre or bad at many things, and good at a couple of particular things, and those couple of things are what make the company viable. This is the essence of a "unique selling point".
But to the point: most companies don't need great developers. Nowdays most medium sized businesses employ some tech staff, but IT is not core to their business.
Nothing, but engineers are expensive, so if you can spend a couple thousand dollars to get better value for the money, you might as well.
Of course, some companies spend far more than that, which is probably not economical.
Nothing, if company managers would admit it.
Instinctively, they know it. The old cult of management-as-a-profession believes that by skillfully directing the activities of replaceable cogs, a company's managers can achieve outsized results.
But they can't admit it because they're afraid that knowledge would demotivate the replaceable cogs.
Because of this, the interview process is not designed to efficiently handle a minority of qualified candidates, but rather efficiently weed out a majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it.
Dead Comment
Dead Comment
Every state in the US is an "at will" state, meaning a company can fire you with no reason as long as it isn't discriminatory towards a protected demographic.
https://worldpopulationreview.com/state-rankings/at-will-emp...
Even with at will, the company can get into difficulty with unfair dismissal and other issues.
The few times I've seen someone fired (and fired fired not PIP or layoff) have been for clear and undeniable issues. The "your work isn't up to performance standards" without a PIP falls into the rare bucket (and more likely at the small companies than the larger ones).
How is hiring a mediocre developer worse than hiring a charlatan?
Firing sucks, but it’s hard to truly tease out quality during interviews. So most companies go for false negatives over false positives. Generally this means that of the 3-to-6 interviewers, all have to have strong positive opinions of the candidate for the hire to happen.
Because of this, as a candidate, it’s a bit of a number’s game. You can be a great candidate, but still not get hired on any individual interview, because companies heavily bias towards allowing lots of false negatives to avoid the odd false positive.
I'm not sure I agree here. I doubt most interviewers have actually given much thought to what they are actually trying to look for in a potential candidate. The widespread practice of over-focusing on algorithmic whiteboard questions is a symptom.
There's got to be better processes in assessing candidates' qualities beyond solving algorithmic puzzles (which perhaps is 5% of a software engineer's job at best).
It’s just really tough to figure out in 2-3 hours how someone is going to perform in a given role over the next few years. Interviewing is an inexact art, not an exact science, and it’s very much my experience that companies compensate for this by favouring false negatives (not hiring possibly strong candidates) over false positives (hiring weak candidates).