My client, the sky, is suing your client for copyright infringement.
Additionally my client is suing GGP’s client for the offer of water, in which my client believes they have a valid interest but were not given due consideration in the making of this offer.
The sky is in violation of my client Sky Media's trademark. We demand that you immediately cease and desist using the term "sky" and all related vernacular.
Thanks for all of these! It perfectly sums up the tar pit that is patents (trademarks and reservations) and copyrights. A couple made me laugh pretty good. Where there’s an interest, there’s 10 in the wing ready to pounce.
For anyone like me who has struggled with insomnia, I have found that "sleep restriction", as used by this and other apps, to be the most impactful thing I have ever done. I've tried every sleep aide, pharmaceutical, and cognitive practice imaginable and nothing can even hold a candle to sleep restriction. I paid for a different app for a personalized schedule but the process is simple. These are the basics:
- Go to bed very late at a time when you can barely keep your eyes open, for me it was 2am. Do normal sleep hygiene things until this time so stay away from screens and stressful stuff. Do this for the same time every night.
- Do not use bed for anything except sleep. We are rewiring our brains so that bed = sleep and that's it. No reading, no screens, nothing except sleep happens in the bed.
- Wake up after ~5 hours with an alarm. This sucks and I hated it but I stuck with it for 2-3 weeks and it shifted my entire existence. My sleep window was 2am-7am.
- The first days will be hard and you may not sleep through that entire window. The important part is to wake up at the prescribed wake up time or whenever you wake naturally (very hard) consistently for a period of several weeks
- Over time, you should be able to sleep through that window. For me, the process of being able to consistently sleep for a scheduled window was enough to prove that there was nothing "wrong" with me as I had told myself for 20+ years.
- Over a longer time, you bring the bedtime up so you get more and more sleep, generally 15-minutes each time.
After 20 years of insomnia, the past year has been the best sleep of my life. I only get ~6-7 hours or so per night but it is deep, restful sleep that is generally uninterrupted if I stick to this regiment. The beginning is not fun but over time I have adjusted to the hours and, most importantly, have outgrown the story and habits that drove my insomnia. For me, I knew how to sleep but I had decades of sleep anxiety and surrounding stress to get past. Being so tired you can do nothing except sleep helps you rewire your association with your bed away from "sleep is stressful" towards "sleep is easy".
I paid for the Sleep Reset app to walk me through everything. Because I paid money for it, I probably had a higher degree of success than if I just Googled stuff and half-assedly tried to incorporate it. For ~$200, the app certainly has high margins and made money off of me but it was the best $200 I ever spent.
I'm glad you found something that works for you! It's easy for someone suffering from chronic insomnia to just accept that there is nothing they can do (especially if they have experienced it for a very long time). It's great (and motivating for many chronic insomniacs out there) that you found a way to resolve/ cope with your insomnia after 20 years. Thanks for sharing your experience!
The alternative to Gutenberg was allowing thousands of proprietary plugin developers to compete with each other to encode your data in a way that made it impossible to migrate to anything else. Gutenberg was mandatory.
Gutenberg encodes semantics in comments and inhibits migration and interoperability as much as any of the other proprietary plugins you are complaining about.
I think that is normally a good rule of thumb, especially when first party has a track record of accomplishment. It's one that I embrace. I am trying to stick with the original editor and find it increasingly hard as all of the design elements are now requiring Gutenberg. To be clear, I am not advocating for another page builder over Gutenberg, just not embracing Gutenberg because it embeds semantic elements in comments and if and when I need to migrate off of WordPress I don't want to be stuck. I have been using WordPress for 18 years, which is a long time for any technology platform. I don't have plans to migrate but I don't want to foreclose any options.
Side note: I would also pay for a "Landlord as a Service". I want to treat a company like my landlord, even though I own my house. "Hi Bill, my roof is leaking" and they say "Someone will be there next week" and then send me a bill.
I was intrigued by the "Test Rule Performance on Historical Data" feature on the home page. I thought signing up would let me play with the performance of your sample rules but I can't seem to figure that out. Is that possible?
Also, that home page block could be more informative. It shows me a dollar value but not what asset it was actually applied to.
I very informally do this right now. I think of my role as a sports agent for top engineers. The engineers I work with pay nothing and the companies who want access to them give us no bullshit, all access interviews where we're not working with HR or recruiters. It works so well for both parties that I'm scaling it at the moment.
There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process.
Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process.
Part of my job is helping companies "fix" their hiring and one of the ideas that I've been putting forth for years that's slowly gaining steam is developing a "technical apprentice" role. This role would be responsible for tasks that are frequently de-prioritized like documentation, testing, QA, bug fixes, note taking, etc. and would be a foot in the door for entry-level engineers. The role is designed to focus on communication and soft-skills while also giving the person a chance to prove their "grit" on the technical side. Even a few months in an apprenticeship role is generally enough for companies to "take a chance" on someone as an entry-level engineer.
This has been a great way to shift interviews away from algorithms and more towards finding people can add immense value to technical teams even without having on-the-job programming experience.
I'm curious what the HN crowd thinks about that role as a way to bridge the hiring gap.
Seems like a no-brainer to me. Most skilled professions provide some sort of apprenticeship track where you balance some mundane tasks with more complex tasks working with skilled professionals in the discipline to learn the trade better. You're not paid at industry high rates initially but provided a reasonable timeline for full competitive pay employment into the profession.
New and young surgeons don't start out day one on the job after six years or so expected to perform a successful open heart surgery, like software engineers are essentially expected to do. You also don't have civil engineers designing full dams or bridges on day one of their job after their bachelors or masters.
Software on the other hand thinks that for some reason, you transition from student to expert in the blink of an eye or can simply pick up what you need in a few weeks. It's completely unrealistic and businesses need to realize the value and necessity of apprenticeships and mentoring.
The problem with this though is that technology is so diverse (now more than ever) that a certain amount of skill you learn at a business is going to be non-transferable as opposed to other professions where their craft is mostly constant.
This means employees are a little less interested in these commitments because it can tie their skillsets to a specific employer if the employer isn't keeping with popular industry trends. It's also a cost employers and employees often don't want to pay in a world where employer/employee loyalty is non-existent. I think for apprenticeships to work, they need to provide transferable skills/knowledge and or provide some basis of loyalty and long term commitment goals between an employer and employee. Both of these seem like incredible obstacles in the current development climate.
I have taught at the undergrad, which gave me the perspective of observing those undergrads that got job offers and those that didn't. Almost without exception, those students that did well in class and made an effort had no problem getting job offers. It was rare if they got a job at a FAANG company, but I don't think I knew anyone who wasn't able to secure an offer. One thing common to all of these students is they practice technical interview questions. Some had internships, some didn't. Some of the students were very bright from a theory perspective but most had a relatively poor grasp on theory. However, one common trait was they made an effort to grow as programmers.
There were students who really struggled getting jobs and it was not at all surprising. They struggled in their courses and were not proficient programmers. I never got the impression that they spent much time outside of class trying to work on these skills. No matter how hard I tried to motivate them it fell on deaf ears. I do not think an apprenticeship would have much value to these students other than possibly delaying the conclusion that this may not be the field for them.
I see the idea of apprenticeships discussed as a better alternative to the technical interview. My observation is that those that are proposing this have not worked in a "skilled profession" (not entirely sure how one defines that) that has a so-called apprenticeship. A common example I see on HN is that of doctors, where their residency serves as a sort of apprenticeship. The number and difficulty of tests doctors have to go through to practice as a doctor (at least in the US) is pretty incredible. Given the choice between going through that or studying months for the most difficult battery of technical interview questions, I would choose the technical interview route every time. This completely ignores the fact that doctors attend 4 years of post-graduate education (medical school) before even starting the residency. Imagine if companies required a PhD in CS before you could become an apprentice! And their boards are, without question, orders of magnitude more difficult than a PhD defense (I have a PhD in CS and my wife is a spine surgeon, so I am speaking from experience).
The counter argument I suppose is "well maybe not doctors, but what about accountants and actuaries?" I was a fully credentialed actuary in a prior life and can say those exams were way more stressful and difficult than preparing for technical interviews. Once you are through them it is very easy to move around and there are no technical interviews, but it also takes on average 7 years of intense studying and heartbreaking failures to get there.
I am not saying technical interviews are perfect. However, it seems the theme is that the grass is greener in other professions, and I don't think that is actually the case. What other profession can you studying your butt off for 6 months and land a job paying over $250k out of college?! Yes preparing for technical interviews is difficult, but boy is it worth it (at least in my opinion). I personally think they are a great opportunity to grow as a developer as well. Anyways, I suppose I have gone on enough.
We have roughly this concept in my org (field consulting for a major cloud provider). I've been very involved on the training side and on having people directly on my team. Some notes from my experience
1) We still have a pretty intense interview process. We largely aren't taking people from code camps, but people with programming experience in university but who may have not been CS majors.
2) To work, it is necessarily VERY labor intensive. I ask teams taking on of our early "apprentices" to expect to have a senior level person spend at least an hour a day with them for at least a month, and multiple hours a week for a year.
3) You need to have long timelines- On-boarding is hard with well trained with lots of experience. In my experience, "apprentices" often take 6 months plus to be value adding. For a project that will be over in 8 months, this can be hard to swallow. The program and adoption has to be driven at a strategic level.
4) The benefits of the apprenticeship program often do not accrue to the group doing the investment. If it takes 6 months to get someone to the point where there are adding value on average and then another 6 months to the point where they are more than covering their salary and cost, then they are a year into the position. We see a lot of our people choosing to transition at around 18 - 24 months in role. We just sunk a ton of time into people to get them competent, but the benefits of that training are going to another group or company and would have been better off hiring no one.
5) Despite all the above, many of the best people in my org have come through the program. Beyond just being good at their jobs, they bring a diversity of background and experience that really adds our ability to execute on problems.
I'm a big supporter of apprenticeship type programs and think they pay off in the end, but as I've described there are a lot of failure points along the way.
at the moment the comment immediately below this is advising folks to find an internship, and in many ways that's what you're describing - a role with a limited timeline and a low minimum bar, but within which some people will be able to demonstrate abilities and promise far beyond that minimum.
It's reasonable, but it doesn't always work out. One of the larger heartbreaks of my professional mentorship time was bringing in someone who seemed like they could be a "diamond in the rough" but was just unable to ever quite pull it together. Watching this person's limited successes and repeated failures and their understandable, almost always mature emotional responses, and being unable to help them get over the hump was pretty frustrating for all parties involved. I also think it was short-term bad for my career: I felt judged for putting so much energy into someone who wasn't quite working out, and I don't think that opened any doors for me personally.
So - it's still a risk! What I think is that when it works it's great, but the people doing the hiring, evaluation, and training are still taking a fairly time-and-resource intensive risk, and when it doesn't work it's no fun at all. Gives me a lot more sympathy for folks who take the safe route.
Maybe there's a paraphrase of "nobody ever got fired for choosing IBM" along the lines of, nobody ever gets dinged in performance review or passed over for promotion if they only hire candidates who can sail through whiteboard-algorithms questions.
As someone who is regularly helping companies improve the hiring process, I can say with absolute certainty that companies _do_ get dinged for "only hiring candidates who sail through whiteboard-algorithms questions". Companies know that these are not indicators of success and that they lead to uniform teams with homogenous backgrounds.
I will also say that crafting real world "on the job style" interview problems is growing steam, as it should be!
This is a great idea for apprentices/entry level talent. However what I see in FAANGs is that though we claim to have a shortage, the reality is that demand is low (internal headcount) and supply is high (for ELTs). The leetcode style coding interviews is very very pushed for so that we can have a standardized process whether that is what the job entails or not. After all most of the work being done is on some custom stack anyway. The downside of this it ends up impacting experienced engineers who are being evaluated on the standardized tests rather than experience sadly. I feel this may even be the desired outcome!
I like your approach, in fact several people when I started development truly believed that the first 2 years or so, you were only supposed to fix bugs and things like that.
The one problem I see with the approach, and this is an issue with the company not your idea, is that they don't have people to train entry level developers. Most of the senior people I've met are incapable of doing it. They lack real expertise or an ability to effectively communicate and deal with people, or they are simply burned out from it. I've seen a number of places where the senior person is tasked with doing that and it takes up all of the person's time. They get punished for being promoted to that role. Heck I can say that I did for a while too. I took a lower position so I could write code and not deal with all of the politics and stress of leading people.
My experience, as someone who has advocated for hiring people along the same lines, is that this is a pitch that everyone will agree is a good idea. But then when it comes time to actually hire someone under it, people will hem and haw about whether or not they have the capacity to mentor people like this.
Usually it then won't happen unless they fit a very specific "comfortable" mold of person that they believe can be a "self-starter" which usually just means someone who's similar to person/people deciding on the hiring in various ways.
Where I work mentoring a junior person is almost mandatory once you reach a certain level. I've been told flat out one reason I was passed for a promotion was I wasn't mentoring people, event though my department didn't have any juniors in at the time, it still held me back (and my boss also started looking for opportunities to mentor outside the department, but I left before that got anywhere for other reasons)
- a real chance and a clear path to 'upgrading' to a dev role
- generally good integration with the team (AKA not a person 'over there')
- mentoring & pair programming (for example for bug fixes)
- time scheduled for learning
Can be both attractive for an inexperienced applicant and very useful for a team. Just note that if you take an apprentice or even intern, then you have a responsibility of teaching and helping that person grow.
Also note that some of the things you mentioned, specifically QA and documentation, are quite hard to do well. There needs to be some guidance.
The danger is that people just/only give an apprentice tasks that nobody else wants to do. Some of that is fine, but I've seen people give interns/apprentices tasks which required expertise but were 'boring'. This is a failure in my eyes, because now your apprentice is overwhelmed and demotivated.
I'm an advocate for when it works, but it takes real commitment and effort. It takes engineers who want to mentor and see it as part of their responsibilities. It takes managers willing to mentor mentors and hold them accountable.
It takes all of that AND it takes the luxury of a company that has the excess in time and money to invest like that. Some companies don't. I've been in both companies that do and don't. When you're running a tight budget, you can't responsibly hire talent that is going to take a year to do a job you need done today.
There is a shortage of talent but it’s self-induced. There is no common baseline of competency. So when talent seems rare or absent what is cheaper: waiting for talent to materialize or lowering the level of acceptance.
The problem with that is that the new lower level of acceptance only provides temporary relief for the current shortage. Later developers see this new lower level of acceptance the same way prior developers saw the prior level of acceptance and thus the bar must be lowered further because the shortage rate remains unchanged.
I think this is the way that hiring will work in the future, and companies will be slow to adapt it... until a few companies show amazing results, then everyone will get onboard, in order to lock down good results early.
I imagine a big part of the success of this approach, though, is that the companies have the proper orientation towards the technical apprenticeship.
So, if the technical apprenticeship goes well, of course the apprentices benefit, but I suspect the members of their teams that support them also derive massive benefit.
What a cool opportunity for less-senior developers, to play a role in helping the technical apprentices make a large impact.
I'd love to talk more about this with you. I didn't find your email address - would you be willing to share it, or send me an email at josh@josh.works?
this is a domain I've spent a lot of time on, and have only scratched the surface.
Internships are generally thought of as something you do during college (summers or otherwise). Most CS grads would scoff at getting an "internship" after graduating. Internships are also very structured and generally involve working on a specific project within a technical team (I know they're all different).
The apprentice role, the way I've been pitching it at least, is different. This is a role where you join an engineering org and learn the product by QAing it, join technical discussions and help out by taking notes for the team, show off your communication skills by documenting new features and, big picture, you find ways to add value to the team in whatever ways they need. Over time, the bugs fixed get bigger and the person can bite off small features, etc.
The problem is that companies _want_ to hire new grads (even bootcamp grads) but don't feel comfortable paying SWE rates for someone who hasn't worked as a SWE (often rightfully so). The comp for this is equivalent to a QA eng but has a clear path towards being an entry-level SWE (3-6 months maximum). If after 3-6 months it's not clear if the person can add value as an engineer then it's clearly not a good fit.
This is an interesting approach. My concern would be that companies too often consider their senior engineers to be purely technical and set them to work on "the hard problems," rather than intentionally setting aside part of their days for mentorship, exploration, and thought leadership.
That culture shift is going to be difficult for organizations that don't already embrace it. It's not something you can quantify easily for an executive board.
I think it’s a fantastic idea and applaud you for your work. The major hurdle is leading companies only want to hire senior devs. Why spend money and implement a training program when you can outsource it. There seems to be 3 paths in. One, go to a top 10 CS college. As a hiring manager, our internship choices were broken down by school with less than a dozen choices: Stanford, Harvard, MIT, Berkeley, CMU, etc. and a few diversity conferences. The candidates resumes where literally partitioned in folders for each school or “diversity”, so to peruse through hundreds of candidates you had to go by school or conference, with no way to see who had interests or experience in distributed systems, front-end, AI, etc. without choosing a school or conference to look through. I couldn’t believe how biased it was. Two, go work at a startup or small company for below market wages to get experience and try to work your way up to better and better companies. Three, work overseas for a couple years, pay full price for a masters in the US, and then work the H1B masters recruiting pipelines.
While there are exceptions the bootcamps seem to be geared toward path two. I wish bigger companies had training programs. I was working with a veteran who recently graduated from a local college and helping him with interview prep. He couldn’t pass the phone screen for the role I had available and ended up working for a small local consultant which seemed to be more IT focused than dev. I couldn’t in good faith just hire him without support from the team. I wish companies had training programs to hire local people into these jobs, but there really isn’t a shortage of talent that requires them to set these programs up. The shortage is in quality senior devs who could get into a top company but are willing to work for less elsewhere. Anyone who sets up one of these training programs and doesn’t pay FAANG salaries, is just training up candidates to move to FAANG. I guess in a way path two and three really are the training programs you are talking about.
And the stuff you are talking about regarding documentation, testing, etc. also sounds like other tangential roles like TPM or quality, which unfortunately are just being put on developers themselves at many places. I think most companies should have more people in these roles with the aspiration of moving into dev. Maybe a “training” role focused on this could help, but you may also run into resistance from people who are in these roles in organizations.
> a rapidly growing population of devs who feel like they're locked out due to the technical interview process.
I’m not convinced all these articles about “hiring is broken” and “interviews are broken” actually help with this problem. They are pining for something that may not exist (and may not be possible), and failing to help candidates understand and excel within the current system’s imperfections.
I get the impression that many young devs have skewed expectations and aren’t practicing job interviews before attempting them, and believe that their coding skills are the only things that should matter. The article here reinforces those expectations by repeatedly talking about evaluating competency without acknowledging that competency in soft skills like writing and communication and attitude are often at least as important as competency in software engineering, for example.
That said, I would very much agree with your approach and that a technical apprentice is a nice way for both the candidate and the company to learn about each other. Internships naturally do this without necessarily having the expectation of hiring the intern - though I’ve seen a lot of interns hired because they prove themselves competent.
One problem with a technical apprentice role as an alternative to longer interviews is that you have to expect to not hire a large percentage of the apprentices (otherwise there’s no point). In that sense, the apprenticeship becomes a much more demanding interview, and the commitment and risks are much higher for both the candidate and the company. As someone who does a lot of interviewing and resume reading and hiring, I’m not sure I would change my interview process if I hired more apprentices (but I already spend a lot of time looking for potential over experience.)
I would argue that _none_ of the articles about “hiring is broken” and “interviews are broken” actually help with this problem.
There is near-universal consensus that technical hiring is atrocious and yet very few people putting forth possible solutions and/or companies willing to experiment with the status quo.
My ideas are:
* Real-world interview questions
* Standardized testing for "soft" skills. It can be done.
* Dedicated onboarding resources
* Apprenticeships for entry-level engineers with dedicated training programs
* Remove all names from all inbound job applications
* Offer _more_ money for internal referrals. Make them on par with what you'd pay a recruiter.
> There is near-universal consensus that technical hiring is atrocious
I hear this a lot on Hacker News, but not inside any companies. And when asked why people think it's atrocious, I rarely get a set of answers that agree on the specifics. I'd love to hear more about what metrics show evidence that hiring is atrocious, as well as what is making it atrocious for you. What does that mean in the pre-coronavirus context? Are companies not finding people, and are people not getting jobs? I'm asking honestly and seriously, so I can improve my own hiring practices. I don't doubt there's a problem, I just don't have a handle on exactly what it is, and the reports here on HN aren't matching my own experience. I admit I don't match the profile of the average web developer, so I may be ignorant of what's happening in the broader tech world today, especially regarding recent hires from school.
In my own experience interviewing at and hiring for multiple companies over the last 20 years, what I've seen and done matches some of your ideas. We are getting and giving real world interview questions. The interviews are at least somewhat standardized. There are dedicated onboarding resources.
I haven't seen names redacted anywhere, and that's a good idea to normalize cultural or gender biases, but problematic if you want people to review your online portfolio, or if you know someone in the company who can vouch for you, both of which many candidates do want.
It is my experience that internal referrals have significantly higher chance of success, pay for the candidate is likely to be higher than for external candidates, and referrers are typically rewarded financially for the referral. Many people complain that the referral system is part of the problem under the logic that it can encourage nepotism and echo chamber behavior. I don't fully agree, but I don't think this is as obvious of a win as you suggest either, or that the majority of people would agree with it.
It's atrocious but most companies won't reveal specifics because _those_ people were hired via the same process. So it plays into survivorship bias. And nothing will change.
Could you elaborate on why you think it’s atrocious?
I’m not sure I agree that the processes are hidden, every company I’ve ever worked for (several large corps you’ve heard of + several startups) talks about hiring practices publicly. Glassdoor and other sites, including HN, have all kinds of information & stories about what happens during interviews.
Software engineering is a field that is both requires breadth and depth at a very high bar for acceptance. From the interviewing side and the many interviews I've been through, it often feels impossible to overcome. The breadth that the field requires leaves gaps in knowledge, where anecdotally I've been asked what's a language I'm an expert in, or to detail the deep particulars of react app development, or to solve X problem with the greatest efficiency with ease and have lots of input on your thought process. I don't mean to paint a picture where you're not allowed to test anyone on anything, but as an average dev, it feels like stabs in the dark compounded with not having a clear path to improving, because everyone's interviews are different. You can improve on the fundamentals, but that only helps so much.
To me, communication and problem solving skills are the biggest factors of what makes a good SWE. I find that most technical interviews don't look for talent that's acceptable, but what's exceptional; not for who's capable, but for who's accomplished.
My firm belief is that many devs who struggle getting a job now, could have walked into any company pre 2010 and gotten a job with the skills they have now.
This is all with the caveat of the knowledge that high salary commands high talent, but my opinion is that the bar is set ridiculously high without regard for how arduous the process is.
I have had a few very fair, but challenging interviews, and I do think that's a step in the right direction.
Seems totally reasonable, thanks for sharing your perspective. I’d agree that a lot of interviews can range from hard to insane. I’m really curious what that means in terms of measurable outcomes... like how many fresh CS graduates are completely failing to land a job? How many companies are failing to find candidates? Stuff like that...
FWIW, I warn people I’m going to ask questions they don’t know, and I ramp the questions up until people can’t answer them. I know it can be uncomfortable, but I also like finding the bounds of what people know. I do ask a lot of easy questions, and the majority of the interview isn’t knowledge questions at all, it’s open-ended conversation, usually about experience. I don’t have a sense for whether asking a few questions that are too hard for the candidate puts my interviews in the category you’re describing, or whether you’re talking about an entirely different level of arduous.
Oh that's fascinating! Can you talk about what questions are scientifically proven to make a difference, and/or the methodology of proving it? I've read bits and pieces here and there, but not seriously followed such research. I imagine that style, specific words, amount of follow-up, and even mood in the room can play important factors here in the "success rates" of certain interview questions...?
I just ask the prepared questions... That is a good question but I force myself to concentrate on other interesting questions.
They have said that if we want a new question added to the list we need a good link controlled experiment : ask a random sample of candidates, don't use the answer, and then evaluate after 6 months if there is a difference between the two groups performance on the job.
Care to back that up with any reasons? Engineers are absolutely not immune to cultural and gender biases, the evidence may be pointing the other way, that we currently have greater than average biases in tech. Isn’t oversight likely to make it better, not worse? While it may be a problem to not be able to ask some kinds of technical questions, like the GP comment alluded to, what is wrong with the idea of trying to limit questions to those that are proven to be relevant to candidate performance? This seems similar to how I heard that graduate school performance and success in the sciences doesn’t correlate with GRE math & science scores anywhere near as much as it correlates with the language & writing tests... I wouldn’t be surprised if technical interview questions do not do a good job of identifying who you should hire...
Some technical questions are really sink or swim. [0]
I've seen interviews get totally derailed by a simple FizzBuzz question. [1]
I wonder if the GRE situation doesn't have more to do with selection bias, ie applications with a score lower than a certain threshold aren't considered at all or that folks that aren't convinced of their ability in math & science simply won't apply to graduate school.
I’d completely agree that asking some technical questions is pretty important, and my experience is that they don’t have to be particularly difficult at all, you can filter a lot of people with very basic questions. I have several first hand stories that match the one you heard about the FizzBuzz question. People who refuse to answer easy technical questions and/or get angry about being asked them are a HUGE red flag. Sometimes you have to do mundane tasks at work, and anyone who thinks they’re above it doesn’t deserve the job. Getting angry about easy questions is short-sighted, I mean they’re easy. It’s a sign the person doesn’t enjoy coding or work.
Anyway, you could be right, but I don’t think the GRE thing is selection bias, I looked this up a while back but I can’t find the study now - I’ll add a link if I can find it. Choices and scores were controlled for, and the takeaway was that people who are good at language truly did perform better in grad school. I think it’s plausible since success in grad school and primary output in grad school is papers & writing & a thesis. The same is true for working at a company, the majority of very successful people aren’t the coders (with some exceptions) but they are more often people who are good at communication, writing, planning, strategizing, and rallying others to work together.
I wouldn't jump to that conclusion. It might be true sometimes, but there are people who can code but get offended by such tests. I'm saying it doesn't matter if they can code or not, because getting angry about easy questions is a good reason to reject the candidate, aside from their technical skills. It's demonstrating a lack of willingness. They might be an amazing coder, but not a team player. They might be unfriendly. They might be defensive about their skills, or assuming a golden resume should exempt them from coding tests. They might not be able to code. No matter what the cause is, I have a reason to avoid hiring that person.
> What's missing from the picture is that a great communicator who isn't a chemist will never apply to a PhD program in chemistry.
While true, I'm not sure why that matters? PhD applicants do have a wide range of scores on their GREs, and you can still control for those scores and adjust, as well as being able to look at all science fields and not just chemsitry. If the correlation between outcomes and writing scores is higher than the correlation between outcomes and math/science scores, it doesn't really matter that you haven't measured people who weren't interested, does it?
BTW, googling around currently gets me a metric ton of results and studies concluding that GREs don't predict graduate school success beyond the first year. I'm not finding much on the subject tests vs math vs language, but it looks like the current consensus is that GREs are bad predictors and cause some gender/race/class bias problems.
> That's not really going to help fill technical positions.
I'm saying the successful coders are the ones who are better at communication, among the coders -- counting only coders who already have the job. And the successful grad students are the ones who are better writers, counting only grad students who are already enrolled in a science PhD. That's what I meant about controlling for the bias. Being able to communicate and write well is a major skill needed in technical positions, and the technical people who excel are the ones who are better at explaining, communicating, writing, publishing, etc.
I don't know how to find them, and leetcode and interview puzzles clearly aren't it. However, we've all worked with folks that get way more done than others. We've also worked with people that are a net negative for company. Your paid internship only kinda works at the entry level, and doesn't fix that the filter is broken for mid and senior level.
At mid and senior level, those engineers' peers know who they are. I know we're culturally allergic to using reputation/personal experiences in hiring, but the information is there if you really want it.
> There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process.
Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process.
I'm extremely skeptical of bootcamps, especially after learning that some of the TA's at these are hired to help with teaching as little as two months into the program as students[0].
I'm afraid that a lot of these bootcamps train the students on "practical and applied skills" that makes them one trick ponies. ie, they know how to do one thing and one thing only and if the project's stack change it's unclear if they will be able to adapt.
> This has been a great way to shift interviews away from algorithms and more towards finding people can add immense value to technical teams even without having on-the-job programming experience.
I'll play devil's advocate here and say that algorithms are a pretty good proxy for on-hire performance. I can, as an interviewer, expect most grads from serious CS programs to have had an algorithm class. Being able to demonstrate that they are capable of learning algorithms and applying them gives me confidence that they will be able to learn new stuff fast when joining the team.
It's a sink or swim situation where I believe that it's very hard to teach CS fundamentals on the job but relatively easy to teach new tools and new frameworks. So I would rather hire someone with strong fundamentals
While I have never done an algorithm style interview in 25 years of being a developer across 8 jobs, I have softened my stance to it.
One of the biggest problems CS grads face is that they can’t break out of the cycle of not having experience and can’t get a job and can’t get a job so they can’t get experience. After the first job it gets easier.
You can practice for algorithm type interviews and get a job. It also doesn’t matter where you went to school. It’s the great equalizer if you can teach yourself.
If I were trying to get my first job today instead of in the mid 90s, I would have been spending time “grinding LeetCode”.
> One of the biggest problems CS grads face is that they can’t break out of the cycle of not having experience and can’t get a job and can’t get a job so they can’t get experience
Serious CS programs often have employment rates really close to 100%.
This makes sense and it's a wonder that most companies aren't doing it. There are a lot of people who can do the work with the right apprenticeship/training. IMO, there really isn't a shortage of people who can learn to do the work, but there is a shortage of companies willing to make the investment in people.
There's nothing wrong with apprenticeships but if senior hiring remains unfixed then what is the apprenticeship for? As long as going from one company to another is a major hardship with risks and drop out tech is not really a career path.
My previous employer did this pretty well. They had a paid internship program, but they also had started as an AS/400 shop writing RPG code, which none of the local colleges taught anymore.
So, they basically developed their own course, and kept it fairly consistent over several years. The first 20 or so hours was some computer based learning modules they had purchased to teach fundamentals and syntax. After that was a series of well documented training assignments.
For the first assignment, they'd be handed an existing report program with several bugs that they'd have to figure out. After that, they would start on a simple CRUD program that they would expand on. At the end was a capstone assignment that simulated a real project from interviewing a "stakeholder" to gathering requirements, writing documentation, and implementing the solution before finally promoting it through the change control process.
Altogether it was 150-200 hours of training, which corresponded to about 2-3 months for a student working part time.
The company recorded everyone's performance, so after the first dozen went through the program, they had a solid baseline for comparison to tell if someone was falling behind or blasting ahead. If a trainee proved they were solid, they might get to skip the last assignment. If they were horrible, it would quickly become apparent and after a few chances to turn things around, they'd be let go.
I ended up on the team responsible for running the training program. Even as the development started shifting to Java, they still used the RPG training for a long time, since it was at least a gauge of a person's ability to pickup unfamiliar tech. Part of my job was to help develop a Java version of the course to eventually become the new default.
Reviewing the assignments was kind of fun and taught me to appreciate people in QA roles. Submissions didn't have to be perfect, but they had to meet a certain level of quality before the trainee could proceed.
Sometimes someone would bomb one of the early assignments, and that was okay, even if fixing the issues and resubmitting took longer than normal to finish. The real red flag was repeating the same mistakes over and over again.
Even though the training program was created for interns, a few of the dev managers would have all their new hires, including senior engineers, go through the same program. Normally the full time hires would "graduate" early, but I know of at least one mid-level dev who didn't make the cut at all. The hiring manager was thankful to have dodged a bullet, and have the historical performance data to back up his decision when he went to talk to HR.
> There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process.
I think there are ways for both of those things to be happening simultaneously. (Well, sort of- employers claim a talent shortage, but really it's a shortage of talent at prices they wish to pay.) The fundamental problems are that it's not possible to measure a broad swath of candidates' abilities, and that hiring an engineer is very expensive.
I interview people all the time who have job in "top" companies, who then proceed to do a pretty poorly in the interview. Now that could be the interview's fault, or my fault, bad luck/nerves, or at the very least you can say the interview may not provide an accurate depiction of the candidate's abilities. And I am sympathetic to that, I've been on the other side of that and I know what that's like. But the two fundamental problems remain.
My advice is different than a lot of what is here. My suggestion (engineer turned exec turned investor after some exits) is to speak with the team lead directly about the issues you're having with their leadership. Try to be clear and be sure to present what your ideal best-solution would have been for 1 or 2 cases where you've had issues.
Either in parallel or after, depending on how the talk goes, also speak with the founders about your issues. If you're solving the big hairy problems for the business, you could suggest a role that's tailor-made to your strong suits (not working with a team lead, not needing to supervise engineers, whatever it is you want). In any case, any founder worth their weight in salt would want to hear that their star engineer is not getting along with a team lead. If it was me as the founder, I'd take your feedback and then solicit more from other people on the team and then make a call as to where the "fit" seems off.
As to burnout, if you've "solved" the big problems and are giving the company a pathway to revenue/profitability/etc. then I would strongly suggest you don't quit. You're well on the way to being indispensable and can use that as leverage in any future salary/role discussions. At the very least, tell the founders where you're at and say you want a vacation.
