It depends. A welder looking for a job -- even with a certification -- will often have to demonstrate his welding skill to the jobsite supervisor before he is hired. An airline pilot -- even with a rank of "captain" with 5000+ hours -- when trying to find employment with another airline, will still have to demonstrate piloting skills with a "check ride" as part of the hiring approval process. Sometimes, experienced pilots fail the check ride for whatever reason.
The common theme is that "existing credentials" is sometimes not enough.
Those kinds of demonstrations are also very for professional jobs outside of hiring new grads.
And even in the trades it isn’t common.
Airline pilots that were laid off and are trying to find employment with another airline do study airmanship in preparation for interviews with another airline. Especially if the pilot is not type rated for the particular airplanes the other airline flies. E.g. the experienced pilot currently is rated for Airbus A320 but the airline he's applying only flies Boeing 747. The pilot studies because he wants to stand out from other candidates so the prospective airline wants to hire him and willingly pays for ongoing 747 training. Yes, the airline interview and check rides with the flight instructor are stressful because they can still fail even though they have 1000s of hours of existing flight experience.
That makes sense then because they are applying for a slightly different job.
It would make sense for a Java programmer to spend time prepping for a Python interview as well.
In short - unless you really are just moving to ‘same job different company,’ not just same title, but same actual work - you’re gonna need to brush up while you’re trying to find your next gig. It helps you stay engaged with your profession, anyway.
In programming you can apply to the same type of job using the same language, the same teamwork, in the same domain with 20 years experience and you’d still be expected to spend time practicing for a test that has almost nothing to do with your day to day work.
I don’t know anyone who spends time prepping for the work they plan on doing at the job they are interviewing for. They just brush up on leet code, or language syntax if they are interviewing for a place that uses a different language or framework share than they normally use.
The example in the post (sum all even numbers in a list) is a perfect example of something programers do on the job every day. It's not leetcode puzzle bullshit; filtering and aggregating lists is an extremely frequent task in software, and no competent programmer should have to study to perform it.
I was basing this on the 30 minute live coding session the author talked about.
Yeah that screening is simpler than fizzbuzz. I also think it’s a worthless test and I believe the tweet is extremely misleading.
I’ve been doing this for a long time and if you exclude candidates that fail the most basic resume screen, I would be surprised if 10% failed that test.
If you filter for only senior candidates with verifiable experience, I’d be surprised if more than 1% failed it.
If 75% of the candidates that get through to your coding screen fail that something is extremely wrong with your hiring process.
Source???
I'm definitely aware of welders and machinists having to show the quality of their work for interviews.
You might not think that basic coding/algorithms problems are good tests of actual performance, but being able to solve a problem, talk about your approach, debug issues when they come up, and then discuss expanding the solution in prod including trade-offs is actually a really great indicator of future performance in my experience.
Some people so often say that credentialing helps all these industries that they know nothing about, when in fact the norm or high-performing end of those industries do the exact same thing.
This is hilariously out of touch with real world hiring.
If you put up a job ad, there are so many people who will apply with all the certifications you can name. And if you ask them to write code, even something quite simple, they will fail utterly and completely.
I've interviewed a bit over 400 people at this point. When I was doing it as a full time job, people only talked to me after they pass a screening test - which already screens out the majority of applicants. Even then, about 3/4 of the people I've interviewed were terrible. So bad they could barely write hello world in the half hour we give them. This is on their own computer, in their favorite programming language. They did not have to talk to me during the process at all. A lot of the people who fail have graduated from decent universities. Some said they had 30 years professional experience.
I'm sure some of that is due to nerves. But a lot of it is simply because programming is hard, and most people don't have the right kind of brain for it. Lots of people - probably the majority if we're honest - bluster their way through certification programs or degrees. Many of them learn the theory but struggle with the practical skills. Sometimes they gather together in low performing teams at large companies where management doesn't know any better.
If you graduate from a music conservatory, you can probably play an instrument. But that isn't true of most computer science degrees. Lots of people graduate without being any good at programming.
Its also a numbers thing. Good programmers don't stay on the job market for long. Great people will send 1-3 applications and be hired. Or more likely be hired through word of mouth. Bad applicants might send hundreds. As a result, most job applications are written by dedicated people who get turned down over and over again by employers.
There's a reason fizzbuzz has become a cliche in our industry. If you put up a job ad, most people who send in an application won't be skilled enough to program it up.
I wouldn't have any time to prepare for this unless I was laid off unexpectedly, then grinding leetcode would be a full time job for a while.
On one hand this demonstrates that it isn't useful for testing innate skill.
On the other hand, it was the best paid work I've ever done. It was an essential part in me getting a job (not at Meta) that paid multiples better than previous roles.
This work allowed me to place myself in a group of people who can pass the test. Some of the people who are outside this group would make fine employees but don't want to or think to put in this work, for understandable reasons. But all of the lackadaisical applicants will fall outside this group. I get to signal that I'm not one of them.
I spent 4 years in higher education for a non-essential positive signal to employers: 2 weeks is nothing.
In the past I hated Leetcode, now I've begun to think of it as an opportunity. While as an individual my opportunity to shift the consensus on this form of interview is low, my opportunity to benefit from the arbitrage is high. Don't hate the player, etc.
Almost nobody bothered to read that document before the interview. And the people who did were usually the better candidates. We joked internally about skipping the entire interview process, and just passing everyone who read our study notes.
I can. So can a lot of the better candidates I interviewed. Most googlers and fb engineers can pass this stuff too.
Theres a much better way to test for senior engineers though, and it’s this: prepare a small program (200 lines or so) with some bugs in it. Write a few test cases which highlight the bugs. Then give the candidate the code and the tests and ask them to fix the buggy code.
Good senior engineers - in my experience - aren’t better than smart young grads at programming. But they’re soooo much better at reading code and debugging it.
I interviewed this insanely good Ruby engineer once. He had the body of a bear, and a bushy, greying beard to match. During the interview he gave me a masterclass at debugging. Before he even looked at our tests, he read the code and named out loud assumptions he was making about it. Then he started writing his own test suite to validate those assumptions during the interview. He fixed a few of our bugs before he even looked at our tests, in the first 10 minutes of the assessment. And he fixed another bug we didn’t know about. I can’t remember how he did at the programming section of our interview. But I’d hire him in a heartbeat from watching him debug.
The one thing to keep in mind if you do this is that most people will overestimate how much debugging you can do in half an hour or an hour and overcomplicate the program you give candidates. If you make a test like this, make the code simpler than you think and actually calibrate its difficulty with your coworkers.
Even if I did, the solution would probably end up running in O(n!) time.
Even this article falls into this trap. The first thing he quotes is fizzbuzz-level, but then the research paper he uses to argue against fizzbuzz actually used a much harder leetcode style problem.
IMO fizzbuzz-level problems are totally fine. You can't really argue against them. They filter out tons of people who I wouldn't want to hire, and nobody who should be hired can fail them, even under ridiculous pressure.
It's more debatable when you get to actually difficult algorithm problems but that's another argument.
(Also fizzbuzz itself is a pretty terrible "simple" problem because it feels like there should be an elegant "trick" solution but there actually isn't. Don't actually use fizzbuzz. The example in this article - filter out odd numbers from a list - is totally fine though.)
People actually find being fired a greater inconvenience and humiliation than a 60 minute whiteboard interview.
If you don’t lie about being able to code, you’re no more likely to be fired than if you had passed a whiteboard interview.
Did anyone say to only do a whiteboard interview?
I have never seen someone get fired for things that otherwise would have showed up in a whiteboard interview (at places that didn’t do them).
Why do you think that famous employees get straight offers without doing anything verses many engineers still getting leetcoded and get left with no offer despite being over-qualified?
Soham was able to pass most programming assessments so well, the folks at bookface were discussing to ban him from applying to their startups.
You can see that another system has been created to make sure that the role is reserved for friends of the founder, ex-collegues of another team over an extremely qualified engineer out of no where.
That should be more than enough to assess if someone is fit for the job.
At some point of your society has decided it values job security, the jobs will have to become secured. It is a trade-off.
I was just pointing out that your "that wouldn’t be caught in a live-coding interview either" does not shed any additional light on the topic I personally am interested in, namely, the choice between a free market in labor and legal regime that grant employees some job security.
Thanks for the info.
That's just a risk we all have to take.
A developer is likely quitting another job they are heavily invested in, possibly moving across the country, and taking a risk when changing health insurance.
If you ask them to do all of that and then immediately turn around and fire them because you didn't really hire them, you just did so probationally without telling them, then you are running an absolutely toxic business. Word will get out and no decent candidate will even consider working for you.
I’ve hired many construction workers over the years. In the construction industry, if an interview goes longer than 15 minutes you’re doing it wrong.
Interview summary: Interviewer: “Can you do the work?” Interviewee: “Yes.” Interview over.
When they start working, if they can’t do the work, they’re fired.
Labor laws in many places are less “flexible” than those in the US, and they don’t support what you’re proposing, for good reason. I wouldn’t quit my job or uproot my family just to convince a manager I’m worth keeping.
There have always been “brain dumps” for certifications as far back as 2007 with Microsoft certs.
The AWS certificates are easy to cram and pass with no real world experience. I only got mine as a guided learning path with a goal at the end. In fact, I passed the first one in 2018 without ever logging into the console and got all three (at the time) associate level certs within 6 months after opening the console at my job at a startup and the two “Pro Certs”.
Even AWS Professional Services (AWS internal consulting department where the consultants work for AWS full time) doesn’t make certifications a requirement coming in. But you have to get a couple within 90 days (associate) and 6-9 months (pro cert) depending on your position. I’m no longer there.
There's no code to match for software like there is construction. Auditors don't know anything. Managers and abibey are often to disconnected from work to know what's good and bad.
They will make friends, spend time learning the domain, and a company will invest quite some hours.
During the interview phase, it is easier to swap candidates.
Now, a month later - fired - it's worse than not having worked at all. Good luck reaching back out and starting over from scratch with your best options now off the table.
If we could fire bad hires instantly, tech hiring could be a lot easier.
However it's still rare and companies rarely terminate that fast. They require lots of documentation, even in probationary period.
Why? Liability. You can fire someone in the probationary period, but it's not free. You can't fire them for being black or being disabled. That's still illegal.
So, to protect yourself, companies get documentation.
> A certificate confirming he did learn the job
What would that certificate be?
College degree should also work as you usually gather some job experience during university.
What i not meant were specific certificates like the Cisco ones.
Even a letter of recommendation from a previous employer would count for me.