The best companies I worked asked me about my values and ideas during the interview. The worst companies I worked asked me some very specific technical questions and demanded precise answers. Those people built terrible systems and constantly struggled to maintain them. Probably fragility of their systems is the reason behind that approach to the interview. They want to hire a person who will outsmart their terrible architecture and make it work. Their real problem though is always about communication and culture of such organisations. They put a lot of effort to protect their bad design from changes.
Protecting bad Design from changes. That nails it. The reason is often, that they spent years to into that "design" that they inherited by an old coder, who knew what he did, but with the patterns of the past. And if you come and refactor it to something maintaineable, they get very uncomfortable. Let the keep blaming the long gone creator and move on to the company with the heads you can learn from.
I like the idea asking about values and ideas. However, shockingly, many senior engineers struggle with answering some simple coding questions. For example about passing and returning nulls. When would you do it? Is it a good idea?
I think it's the opposite, asking deep technical question create fragile architecture because they end up hiring people that have only the low level technical skills . I lol so hard at the linked list question because i just dropped an application process because they asked me that question in 3 different technical interview for a senior dev position. And my 13 years experience didn't seems believable as i didn't have a textbook answer, but the intern that hasn't finished school would have nailed it!
Technical interviews should just be a senior dev having a beer with you and talking about patterns and architecture and the bullshit you've had to deal with professionally. That's it. Source: me. I have a small software company, and this is how I do them. It hasn't failed me yet (well maybe the guy was ultimately an asshat, but he always knew his stuff).
the last company that I interviewed rejected me because they think I’m not technical enough whereas I have delivered many successful softwares in the last 15 years both as a developer and a lead/manager. I guess they must be building some state-of-the-art solution over there then.
That has happened to me too. But companies have a right to not proceed with candidates that they think might not be a good fit, and not necessarily because "they must be building some state-of-the-art solution". No one owes you a position or an acceptance offer.
I'm almost 20 years in software development. I recently completed 4 rounds of interviews. 1 was a behavioural thing, easy peasy - how do you deal with a difficult manager blah blah blah. I then was subjected to three tech screens. The first two I nailled - a simple depth first search problem, the second one was some stupid merging arrays nonsense and the third interview was this overly complicated problem to improve an algorithm from O(n2) to O(n) time complexity. It was badly written, badly explained and the person interviewing me didn;t have a clue. I'm done. I'm not doing any more of these interviews. The next company who asks me to do a technical screen will be told to stick it up their holes.
A bit over 25 years, for me. I've been known to stop interviewers and ask them what the hell they're really after. What is it you're actually looking for? What is the role you're trying to fill? DON'T waste my time with entry-level, final exam questions; nobody outside those interviewers and new graduates are going to care since they've probably never used any of that crap in the real world. Wanna know how to create a production-ready cloud application from nothing? No worries, gotcha covered! Wanna know how to reverse a linked list? Bite me!
sadly there are enough people with 10, 15, or even 20 years of and a woefully unmatched level of technical ability. some people just coast through their careers and i'm not sure how else to figure out if the person in front of me is legit.
@@trevorprice2490 That's why I do demos, now, for interviews. It shows that I'm able to prepare for and give a presentation addressing technical topics, all on multiple levels tailored to the audience members. Doing a demo in that situation has resulted in some fun comments and discussion and great feedback from interviewers; not to mention being the deciding factor in my hiring.
When I interview people we just talk about what motivates them, how they like to work with others, and get them to draw a system that they have worked on and talk about it - what problems did they have to overcome, what would they have done differently if they were to do it again etc. If they say the problems were all caused by other people then we don't hire them.
I agree. That is similar to what I do. It's important that the interview focuses on the CANDIDATE what they have done and what they know. Not so much on what you know and think others should know (like your favorite Leetcode problem). Every candidate has vastly different experiences so take advantage of the limited interview time to discover what they've done and how they solved the problems. And ask them a lot of details about that rather than what you have in your head.
Just got a rejection from a company after a tech screen and a tough 6 round panel interview. I think it was because I struggled on a Terraform interview since I can't write Terraform from memory. I was also asked to debug Kubernetes manifests from memory. Honestly - who writes Kubernetes manifests from memory?? I was able to figure it out, but I thought it was an absurd way to interview someone. And to think - I mainly interviewed for the company because the recruiter told me they were struggling to find a DevOps engineer with a strong software development background (I spent the first decade of my career in SW Eng roles, but transitioned to DevOps 6 years ago). Yet the interviews didn't ask me any coding or software questions! The interviewers themselves weren't so bad, but the process was stupid and I don't think I'll ever interview for that company again.
I have 8 years of experience and i released 10th of successfull projects but i cant pass many of the test questions they are asking us to do in short time, no access to documentation or internet LOL crazy , so i made a rule any company asks me to do test i reject them im not wasting my time, tell me whats my job going to be ill tell you if i can do the job or not and stop your technical BS nonsense
Same here. I am ruthless in selecting companies that conduct their interviews where I get ask technical questions to their teams. If they aren’t willing to offer that. It’s a red flag. There a ton of companies where interviews are tough without the need for tests, where you can show your accomplishments and in return ask to take deep dive into how they do software.
@amirnathoo4600 im tired theirBS so im focusing on my project i made 9k last year this year im at 17k its growing i hope i wont need to work for any company i wish every programmer start building an alternative to these greedy companies and compete with them and get some of their market share
In real life I often just look at the problem, slope off for a coffee then come back and my brain has the answer..or at least where to look. In an interview I've someone criticizing my every move - the answers always come when I've left the interview. Of course its on me to train my interview technique.
I have 13 yoe and the most complex and promising tech stack under my belt (including algorithmic certifications) but still struggling with this leetcode shit. It is not that hard really but if you don't know how to solve this problem beforehand you'll never figure that out in time set or an interview. That's why LC is BS - just a memorizing skill training.
In my company, instead of asking LeetCode questions, or using time-pressured tools like Codility, we give an assignment to be answered in a week (we simulate our task assignment and also respect the candidates’ time), and once the candidate submits his/her assignment, we check and see if s/he’s code is of company standard. We then proceed with a one or two technical interviews, where we check his thought process on his assignment. We had one hire where his assignment was around average, but he was very good at LeetCodes questions (my previous colleague liked to ask LeetCode questions), and eventually hired him. But he didn’t last long and there were a lot of issues on his coding/designing/architecture skills and were very hard read and maintain. Other than that hire, we have very good hires.
Take home exercise is same as LeetCode. What does that tell you about the candidate ability to solve problems. If every company I applied at asked me of a take home, I’d be spending 40 hours a week just doing that. Like a second job! And guess what? I’d probably use co-pilot to do most of the assignments for me now that we have the technology. And if the company doesn’t like that, I probably wouldn’t work there anyway. We use code assistant at my current job. And we don’t ask for tests or assignments. When I interviewed there, there were 5 rounds. I spent over 6 hours in total preparing those interviews. When I was interviewed by my future teammate. I presented them with a system diagram of how I imagined the product was designed and built. They were impressed, it matched very closely to the actual design. As a candidate you have to have something to show. Maybe a personal project, an open source contributions,etc.. and if the company is unwilling to use that material and insists of giving the candidate non sense tests or take home, it just shows the company doesn’t get it. I have 30+ years of experience and have interviewed countless people as well as being interviewed. The best way is to have the candidate actually interview you. Let them drive one of the interviews that will tell you far more than technical assessments.
@@amirnathoo4600 I agree and we actually do those interviews as well. We don't restrict applicants to use co-pilots or ChatGPT to generate their code, but we do check on certain concepts which I think it will be difficult if they just copy-pasted their answer. If they can better enhance the generated code and understand their changes, we're fine with that. We mainly challenge their thought process through their assignments. The potential of the individual is usually what we focus on during interviews instead of technical skills and knowledge.
Do a pair-programming exercise with REAL CODE instead, don't expect a solution just watch how the candidate works and use it as an excuse to chat about technical stuff. This enables you to see what the candidate works and thinks like. It also gives the candidate an opportunity to see how truly awful your code-base is too.
I agree with the broken side of technical interview. I was once part of a panel of interviewers. I kind of get ticked by questions from my colleagues for technologies that are remotely not used by the application we're supporting. My only concern in a job interview is the candidate should know the basics of programming. At least how an object (class) works and and idea how to connect to the databases. Because everything revolves around it. Now depending on the level of the candidate needed, I probably need to just know how the candidate solves specific problems (no correct answer on this one as I want to probe how the person solves things) then it's up to the hiring manager who the hiring manager has a feel in having as a new hire.
I agree, if I am hiring a Java developer, I expect the person to know basics of OOPS and how to implement them in Java. I also give a piece of code and ask them to write some testing code for that. That's what I expect the person to do everyday ... Imagine hiring a person based on how much he/she knows about algorithm, datastructure etc and takes 6 months just to understand how a small microservice is designed (coz most of the times the leetcoders have never seen a real enterprise app and barely know anything that exists outside `public static void main`).
@@NiranjanNanda and there's a lot of abstraction already in implementing lists, queues, and everything in .NET or Java that we don't need to bother anymore. We have a ton of bigger problems to face than focusing on every nook and cranny details of programming. That's why we have open source to help the community on specific details. My specific problem might be solved by someone else in the community that they are very happy to share to you their solution. And you might've solve some specific problem that someone else is looking help for. We don't need to be a jack of all trades developer because the community is there to help us and hopefully we can help them too.
When I interview people for a developer job, I usually get them to talk about stuff they built earlier, and how easy or difficult it is for them to explain it to me. I'll try to get them to draw a few diagrams to summarize the system. Because I believe the most important skill for a developer is to take a step back from the details and create some overview / abstraction. And this test also gives me insight into how they will function in a team, and the level of complexity the person can handle.
Technical interviews are a joke. I will give you an example gathered from my own experience You interview for company X, they accept you, give you an offer and you decline it for the moment OR they close the position, even though you passed it. You interview for company X 2-3 years later and have to go through the same process again, yet for some reason, this time you do poorly on their shitty 1 hour Codility or Hackerrank test. So they reject you. So the company saw you as great, whereas now it sees you as not great. In this time you have gained expereince, however. So it doesn't make any sense
Heheee...man! amazon, google are even bigger jokers....i always think how is it even possible that you take hours of interview....rounds and rounds of tech interview ...which means you hire the best among the best in the market...and then you lay them off saying they don't perform (i am sure this is the reason most laid off employees get)... and, look at the money these interview prep companies are making. they're the real entrepreneurs coz they took advantage of this broken aspect....lol....
Look, I'm going to level with you. As a director of engineering I dramatically increased the difficultly of our interviews after I walked into my new job and discovered that two-thirds of our senior developers couldn't write code. Like...couldn't write code that I would expect an intern to write without much hand-holding. There's a point where the calculus becomes "It's cheaper to miss out on a good hire than it is to hire a bad fit."
Much of the motivation behind skill interviews seem to be as an automated way to cull candidates down to a shortlist worth the time and effort to sit with a human interview panel. The criteria for culling them are almost irrelevant, as long as it gets you down to a short list of candidates that you can talk with.
Suppose I'm a nurse and applying for a new nursing job. I'm not sure how that works, but do I have to prove to them I know how to be a nurse? I mean, I have a nursing degree; I'm holding a certificate from an accredited organization that vouches for my knowledge and skill of nursing. I've worked as a nurse before. I have references. Etc. Etc. It's pretty binary I would think. Either I have the skills to be a nurse or I don't. Technical programming interviews are a subjective, pseudo-scientific process. It's also highly competitive. The idea that there aren't enough developers in the world is total rubbish as far as I can tell.
Interviews are just never enough time to get to know someone and how they work. It's hard to get a sense of what someone's going to be like on months or years long projects when you've only spent 1-2 exhausting high tension hours in a room with them not working on a real project.
>you're more likely too succeed if you attend interviews Well the problem is - on many markets (not only the US) - it isn't easy to even get an interview these days. Getting consistent zero response after applying and no contacts on Linkedin (ah the fantasy of developers getting actual/fitted offers on Linkedin en masse - lovely lie). You can't even tell if you're good or bad if your workplace has zero mentoring options.
I get a small trickle of recruiters. They always get your resume by searching for keywords and having you show up because it's on a resume that you let LinkedIn index.
I agree, interviews are a terrible way to judge someone's skills. Just like exams in school. One of my favourite "tests" for an interview is to give someone some buggy code, and see how they debug it to figure out what's wrong. You can learn a lot about the interviewee from this, as you' testing their knowledge of the language and logic and many other aspects all at the same time. Let's be honest, a lot of time as a developer is spent debugging.
School tests are different. Because as a student you should know things...many things...even if you don't become a biologist or a physician, you still need to learn biology. But in a software company it is hugely different...you become a leetcoder and get hired to write code or test a springboot application... 😀
FANTASTIC! This is where I am now, and this video is very validating and inspiring. I do think it’s a bit of a game and you just have to practice playing it.
The interviewers should know well in advance to which project they are hiring and what skill are required in there. This hardly happens and so the broken process and nobody till date knows how to fix this core problem.
I went to an on-site technical interview consisting of a timed test working on a unfamiliar laptop, using the squishy built-in keyboard, touchpad with no mouse, debugging Visual Studio on a tiny screen. It was an exercise in frustration just trying to move the cursor to get to the right window, let alone think clearly. The real issue was that it exasperated me so much the rest of my interview was completely off and I didn't apply for another job for months 🤬 Crazy tip #1, take a mouse with you 🐭💻 Crazy tip #2, practice writing simple code with a pen in case a whiteboard makes an appearance. It is easy to learn, but you need to visualise your function/method before you start writing it 🖊 Tip #3, find online tests and beast them. Also look at IQ tests as these type of questions crop up regularly FFS! Tip #4, find some respectable social media influencers who post about your tech stack and review their latest stuff. Tip #5 read books. Tip #6, learn from your experiences, if required take an iterative approach, don't repeat your 'mistakes' and DON'T give up 🧠
I'll take a portfolio on $forge over a technical interview any day, on either side of the desk. An interviewer once asked me "what is your desert island technology or design pattern, and why?" and I feel once you get someone with experience talking about their favourite tools you can tell how deep they go on their assigned tasks. Obviously that doesn't tell you about whether they are good to work _with_.
I have been a contract programmer most of my life. If someone says send in your resume I say OK and forget it. If they say come in, bring your resume, and lets talk; I go in. Then I am usually talking to the director of engineering who needs to solve a problem. I get hired.
Since been made redundant last year I've been to dozens of interviews and most have been an absolute joke. There's the ghosting after the interview (and by the agent so they possibly knew there was never a job) and the irrelevant questions. I'd never heard of leetcode (and never needed to over my long career delivering quality software) until I did some digging after having to solve some irrelevant exercises in an interview - so great, I started doing them and now I'm solving them many times faster than at first... so I'd pass these same interviews but I'm the same developer a few weeks apart. Worst interview experience though is been asked the Friday before an interview to deliver a presentation (cos I've nothing else to do right) then asked also to bring in some real good from a previous project for them to review??!!! Even if I had some (I dont)t his would be hugely unethical for me and surely illegal? I declined on moral grounds - and who know's what they'd expect me to do as part of the job
"Take away technical test's that should only take about 1/2 an hour" are my Achilles Heel. I'm no idiot (well, I like to think I'm no idiot) but I have a perfect 100% failure score on take away technical tests. Do a pair-programming exercise with REAL CODE instead, don't expect a solution just watch how the candidate works and use it as an excuse to chat about technical stuff. This enables you to see what the candidate works and thinks like. *It also gives the candidate an opportunity to see how truly awful your code-base is too.*
The proliferation of LLMs has destroyed the usefulness of take-home projects and online tests. They were of limited worth already, and now we have fewer tools at our disposal to vet candidates.
I like to give a candidate code to review. It’s a core skill, it’s directly applicable to the job, and it’s great vehicle for conversation around their answers.
"Tell us about a technical challenge you faced and how you overcame it" - One can prepare/lie to answer it, not sure it's a good way to rate technical skills.
They can ask in detail about your knowledge of the subject. Especially if it is in their expertise, it is very hard to fool them. If you take time to prepare such elaborate lie, might as well do it for real.
You would be surprised how many candidates I’ve interviewed that stumble on that question. The worse answers were the ones that told me they never faced any. Immediate red flag.
Maybe I don’t understand the question then, been successfully delivering automated execution software for various asset managers I’ve worked for. Whenever there’s a unique/specific requirement, there’re solutions available offered by the language itself or by different contributors. Trisha’s disruptor is one of them, and I know, it was born out of a real challenge/unique requirement. I think, being aware of tech/framework available and applying them accordingly is part of the job. I’ve never encountered a requirement that has been a technical “challenge”. What keeps me awake is ensuring each release is reliable, and I am not alone here.
If you are a competent developer then you can figure out how to reverse a linked list, even if you've never had to do it before. The ability to visualise data/relationships, and write code to manipulate such structures, is absolutely fundamental.
True. The problem is that an incompetent developer who has spent a couple hours on leet code will do it better because they have learnt that pointless skill.
Maybe, just maybe, most people (at least half), including those who are loath to code/program/etc can actually learn to program, despite misconceptions, if they were faced with it. THAT is enough reason for me to hire them, ceteris paribus. I see the unwitting lot landing on a distant shore, & I am quietly fired up, energized that they have chanced to embark. Another, when pressed to look, might see them get as far as the parking lot outside, wave out the glass window, & wait for the spaces to empty once more just for another opportunity to admire the achievement of the impeccably architected parking lot.
This might not work for all of you, but I make demos for the position I'm interviewing for. It doesn't have to be fancy, but it gives the interviewers--especially non-professional ones--an example of what you can really do and how well you're able to present.
Once I was asked how many levels of inheritance C# supported like that was something every engineer should know by memory. Maybe don't hire anyone who knows that answer because they've probably hit it through poor design.
There's actually no problem with the types of activities that people do in technical interviews. Whiteboarding/LeetCode problems are wonderful jumping off point to start to learn about how someone approaches problem solving, and yes even their technical knowledge and coding style. As long as you don't place any weight on whether the candidate actually solves the problem the fastest. The problem is that whiteboarding questions aren't used as a jumping off point anymore. Instead interviewers, and especially groups of interviewers working together on committee, commonly throw out all of the valuable subjective observations from interviews, and base their decision on factors that they see as more objective. Instead of judging whether somebody showed good reasoning, skills and communication skills during their technical problem, they simply rank highest whichever candidate finished the problem fastest or with the best solution. This is a common theme that plagues all kinds of processes. Scrum user stories have the same problem: people want the simple objective formula "as a ___ I want to ___ in order to ___" and end up focusing on formulas and process, rather than using the process as a jumping off point to get to the real thing.
With 44 years working in IT, a programming test is an insult. I know Java23, but in practice I still have to use Java11, because the tea is not agile at all. So a test will be done with the latest features, so the team will not understand my code with theis obsoleted java8 knowledge.
I'm a software engineer of 20 years and now a hiring manager. If you're trying to get a job as a developer, poorly designed technical interviews are worthless and a pain. But if you're hiring, well designed technical interviews are a MUST. Many developers are awful at coding and at talking about code. You owe it to your team and your company to weed them out. The only other option is to plan on firing people when they don't work out, which is far worse than hiring the right people in the first place.
I think that depends. I have worked in environments where we did use the probationary period of people's employment as a sanity check. We were doing VERY difficult things, and not everyone could cope. This was horrible, on the few occasions when it happened, but I always warned people that that was how things worked before hiring them and we did our best to give people who were struggling the best advice that we could, and the chance to improve. I always thought of this a rather like playing elite sports. It is simply true that not everyone can work at that level, and you can't always tell by talking to them for a few hours. It is not always possible to "hire the right people in the first place" however hard you try. So as well as trying as hard as possible to "hire the right people" you MUST also have strategies to recover from mistakes.
As a hiring manager myself, I agree. But the technical questions must be well thought out actually represent skills and characteristics you seek. We may employ, instead, a non timed technical exercise, where we can see how well someone can follow instructions, think and communicate clearly, etc.
I agree that you have to see them code. That's exactly what I do when I administer a coding interview - I give them a problem that isn't too difficult, but involves some fair amount of coding. I let them use their preferred language, and I observe them. After half an hour, i have a pretty good assessment of their language fluency and comfort writing code. The problem is that most companies equate coding skill with leetcode style algorithmic puzzles. Being able to come up with the correct dynamic programming solution, or knowing how to perform a topological sort, or when to use a monotonic stack - these things aren't evidence of coding proficiency. It's evidence that the candidate has practiced a lot of coding problems on Leetcode. The Internet giants like Google who normalized these kinds of interviews know that they have zero predictive power, yet they continue to do it because for all of their money and resources, they can't think of any better interview method. I myself am currently at almost 700 problems solved on Leetcode, and I've reached a point where I can pass coding interviews fairly consistently, but I wish it weren't necessary and I wish I could get the hundreds (if not thousands) of hours of my time back.
I always bail on technical interviews that get me stuck for hours solving a logical math problem that 3rd graders thought it was cool. In reality, if you're not using Google stackoverflow and reading massive documentation on random forums, you're not really a developer. So, such tech interviews are bs, irritable and I doubt that you prove anything besides moon logic.
This is the attitude that keeps this nonsense going. I tell all recruiters that approach me I refuse to do technical leetcode screens. If they want to know what I know I'll walk them through one of my many technical projects or do a take home assignment. I was hired recently with no leetcode crap whatsoever, I'm on $115k plus benefits.
Vast majority of the companies just send a time limited coding test. Even sometimes the time is finish until you understand the issue on the test. Who are really working under these circumstances at the real life. Okey this is the issue, make it in 2 hours, why?? And also they are just asking 5-min-google-search questions. Really :) :) (?)
data structures and algorithms are the great filter - it shows those who put the time in to prep, understand, choose the right tool and practice to the point of being able to reproduce from memory
Absolute nonsense. This is a job your going for, not second year in college. I've worked with complete oddballs who aced the tech screen but you wouldn't put them in front of a client. Ever. How does learning by rote show you that you've just hired a weirdo who wont fit in and wont excel?
To @JReiben111 point. In a competitive job market you need to know the secret handshake essentially. If you pass that step you can usually leverage past experiences and speak to projects you helped deliver. Ideally you have a couple prepared that you can go deep on.
A few years ago I was interviewing for a Java developer job at a local startup. One of the interviewer was an Intern. He showed me some code and asked me what was wrong with it. He was using an IDE I was completely unfamiliar with so I was a bit slow in tracing through the code.. As I was about to tell him what was wrong, he got frustrated and impatient and gave me the answer. At the end of the interview process I was told I didn’t get the job because they needed someone who could “hit the ground running”…mind you I have 24 years of experience in Java…17 years of which it was my primary programming language. I told the company..beware of who you are looking for. If they “hit the ground”, chances are they’ll get hurt first..and never be able to get running. I ended joining another startup and capitalized on unique skills that are in extreme high demand today in the fields of AI and Robotics…And I have swapped Java for Go and Python 😂
The most difficult problem in software engineering is interpersonal communication. Therefore, a good interview should test a candidate's ability to talk about code and the ideas behind it. Even dead simple code can be surprisingly good fodder for conversation. Asking a candidate to write code is unnecessary. If the question is trivial they should be able to describe the code verbally, which demonstrates their ability to communicate. If they need to write the code at a whiteboard or a computer in order to explain it, that's actually a red flag.
I am afraid that I don't agree with that. Certainly the kind of code exercise that assumes that there is one true result is stupid! of course communication is the key, but there is a difference between spoken and written communication, let alone communication through code. I would certainly always spend a lot more time talking to people about their ideas and trying to understand how they approach the problem solving at the heart of what we do, but, sometimes, depending on the person and the role, it is helpful to see how they write code. I have met many, many developers who talk a good game and write terrible code. The best ones can do both, but talking a good game doesn't naturally demonstrate the ability to play a good game.
I believe that the technical interview should be skipped if the candidate has a code portfolio or certifications that already prove their abilities. Many companies practice cargo cult interviewing.
both can be faked, I've interviewed people who's portfolio and cert should mean they can answer basic questions. When asked, they totally drop the ball.
This is a good video. It would be a great one if it touched upon how capitalism makes the interview process worse off. Engineers have always been at the frontier of exploitation - from laying down the railroads by expropriating land to the internet-scale data expropriation to feed AI. This crucial role cannot be entrusted to people who haven't been ideologically browbeaten. Imagine if the engineers revolt or even do the bare basic by unionizing 😅 Therefore, organizations create a gauntlet of an interview process that drives people to be individualistic, narrow-minded, and constantly focused on the unnecessary and irrelevant.
Technical interviews are an example of the Drunk and the Lamp-Post parable. They reveal the incompetance of the hiring team and reveal very little about the interviewee. If technical skills are so important to you then ask for a certification. Be more respectful of people's time.
And therein lies the problem: there is no universal 'certification' method in the IT industry. In the accounting profession you have to undertake your training and qualifications to obtain your certified professional accountant qualification and be a member of the professional institution in your country. Until you get that, you are a junior and you can never hold a position of leadership or authority. Most other professions are the same: engineering, architecture, medical etc. Even the trades have this. The IT industry is way behind. The UK, Australia and Singapore for example, all have their respective Computer Societies. These are the recognised professional bodies in those countries but they are not mandated like in the accounting and other professions. They absolutely should be. Once we have that, then a large amount of the nonsense we see in IT interviews will disappear because proper professional qualifications will ensure that candidates meet given standards and can be measured as such. At the moment, they can't.
This arguments about synchronized in Java is feel-good bollocks. There’s no way you can write threadsafe code if you don’t know the basics. There are better and higher level abstractions, but I don’t believe you know what even a race condition is, if you don’t know synchronized.
I think, in a face to face interview coding task can help to save more time. I had a candidate with a good speech, he knows few languages, so gave him simple task: reverse string. Code logic looked almost good. But he failed on basic principle. He used immutable string as mutable char array.
Anybody else have an instant reaction to Head First Design Patterns? I know lots of people love it, but I hated that book. The "repeat everything 3 different ways" writing style made it feel excessively grindey to read as well as useless for later reference.
The best companies I worked asked me about my values and ideas during the interview. The worst companies I worked asked me some very specific technical questions and demanded precise answers. Those people built terrible systems and constantly struggled to maintain them. Probably fragility of their systems is the reason behind that approach to the interview. They want to hire a person who will outsmart their terrible architecture and make it work. Their real problem though is always about communication and culture of such organisations. They put a lot of effort to protect their bad design from changes.
Protecting bad Design from changes. That nails it. The reason is often, that they spent years to into that "design" that they inherited by an old coder, who knew what he did, but with the patterns of the past. And if you come and refactor it to something maintaineable, they get very uncomfortable. Let the keep blaming the long gone creator and move on to the company with the heads you can learn from.
I like the idea asking about values and ideas. However, shockingly, many senior engineers struggle with answering some simple coding questions. For example about passing and returning nulls. When would you do it? Is it a good idea?
I think it's the opposite, asking deep technical question create fragile architecture because they end up hiring people that have only the low level technical skills .
I lol so hard at the linked list question because i just dropped an application process because they asked me that question in 3 different technical interview for a senior dev position. And my 13 years experience didn't seems believable as i didn't have a textbook answer, but the intern that hasn't finished school would have nailed it!
Technical interviews should just be a senior dev having a beer with you and talking about patterns and architecture and the bullshit you've had to deal with professionally. That's it.
Source: me. I have a small software company, and this is how I do them. It hasn't failed me yet (well maybe the guy was ultimately an asshat, but he always knew his stuff).
@@DudeWatIsThis
Both of us are in the same boat. 👍🏻
I do the same thing over a tea ☕ with some cookies 🍪
I was never disappointed with my selection.
Amen.
the last company that I interviewed rejected me because they think I’m not technical enough whereas I have delivered many successful softwares in the last 15 years both as a developer and a lead/manager. I guess they must be building some state-of-the-art solution over there then.
Some new stupid AI to help people turn pages probably
Not technical enough for me translate to didn't hit the right keyword
That has happened to me too. But companies have a right to not proceed with candidates that they think might not be a good fit, and not necessarily because "they must be building some state-of-the-art solution". No one owes you a position or an acceptance offer.
When they ask if you follow TDD, and then you join them and there isn't any TDD to speak of
I'm almost 20 years in software development. I recently completed 4 rounds of interviews. 1 was a behavioural thing, easy peasy - how do you deal with a difficult manager blah blah blah. I then was subjected to three tech screens. The first two I nailled - a simple depth first search problem, the second one was some stupid merging arrays nonsense and the third interview was this overly complicated problem to improve an algorithm from O(n2) to O(n) time complexity. It was badly written, badly explained and the person interviewing me didn;t have a clue. I'm done. I'm not doing any more of these interviews. The next company who asks me to do a technical screen will be told to stick it up their holes.
A bit over 25 years, for me. I've been known to stop interviewers and ask them what the hell they're really after. What is it you're actually looking for? What is the role you're trying to fill? DON'T waste my time with entry-level, final exam questions; nobody outside those interviewers and new graduates are going to care since they've probably never used any of that crap in the real world.
Wanna know how to create a production-ready cloud application from nothing? No worries, gotcha covered! Wanna know how to reverse a linked list? Bite me!
@@shawnedwards5369Tables are truning
@@shawnedwards5369 just learned the the hard way, will try your strategy next time...
sadly there are enough people with 10, 15, or even 20 years of and a woefully unmatched level of technical ability. some people just coast through their careers and i'm not sure how else to figure out if the person in front of me is legit.
@@trevorprice2490 That's why I do demos, now, for interviews. It shows that I'm able to prepare for and give a presentation addressing technical topics, all on multiple levels tailored to the audience members.
Doing a demo in that situation has resulted in some fun comments and discussion and great feedback from interviewers; not to mention being the deciding factor in my hiring.
When I interview people we just talk about what motivates them, how they like to work with others, and get them to draw a system that they have worked on and talk about it - what problems did they have to overcome, what would they have done differently if they were to do it again etc.
If they say the problems were all caused by other people then we don't hire them.
I agree. That is similar to what I do. It's important that the interview focuses on the CANDIDATE what they have done and what they know. Not so much on what you know and think others should know (like your favorite Leetcode problem). Every candidate has vastly different experiences so take advantage of the limited interview time to discover what they've done and how they solved the problems. And ask them a lot of details about that rather than what you have in your head.
Just got a rejection from a company after a tech screen and a tough 6 round panel interview. I think it was because I struggled on a Terraform interview since I can't write Terraform from memory. I was also asked to debug Kubernetes manifests from memory. Honestly - who writes Kubernetes manifests from memory?? I was able to figure it out, but I thought it was an absurd way to interview someone. And to think - I mainly interviewed for the company because the recruiter told me they were struggling to find a DevOps engineer with a strong software development background (I spent the first decade of my career in SW Eng roles, but transitioned to DevOps 6 years ago). Yet the interviews didn't ask me any coding or software questions! The interviewers themselves weren't so bad, but the process was stupid and I don't think I'll ever interview for that company again.
I have 8 years of experience and i released 10th of successfull projects but i cant pass many of the test questions they are asking us to do in short time, no access to documentation or internet LOL crazy , so i made a rule any company asks me to do test i reject them im not wasting my time, tell me whats my job going to be ill tell you if i can do the job or not and stop your technical BS nonsense
Same here. I am ruthless in selecting companies that conduct their interviews where I get ask technical questions to their teams. If they aren’t willing to offer that. It’s a red flag. There a ton of companies where interviews are tough without the need for tests, where you can show your accomplishments and in return ask to take deep dive into how they do software.
@amirnathoo4600 im tired theirBS so im focusing on my project i made 9k last year this year im at 17k its growing i hope i wont need to work for any company i wish every programmer start building an alternative to these greedy companies and compete with them and get some of their market share
Same here. Not a fan. I’ve even passed a few tests back in the day and never heard back so what a waste.
In real life I often just look at the problem, slope off for a coffee then come back and my brain has the answer..or at least where to look. In an interview I've someone criticizing my every move - the answers always come when I've left the interview. Of course its on me to train my interview technique.
I have 13 yoe and the most complex and promising tech stack under my belt (including algorithmic certifications) but still struggling with this leetcode shit. It is not that hard really but if you don't know how to solve this problem beforehand you'll never figure that out in time set or an interview. That's why LC is BS - just a memorizing skill training.
In my company, instead of asking LeetCode questions, or using time-pressured tools like Codility, we give an assignment to be answered in a week (we simulate our task assignment and also respect the candidates’ time), and once the candidate submits his/her assignment, we check and see if s/he’s code is of company standard. We then proceed with a one or two technical interviews, where we check his thought process on his assignment. We had one hire where his assignment was around average, but he was very good at LeetCodes questions (my previous colleague liked to ask LeetCode questions), and eventually hired him. But he didn’t last long and there were a lot of issues on his coding/designing/architecture skills and were very hard read and maintain. Other than that hire, we have very good hires.
Take home exercise is same as LeetCode. What does that tell you about the candidate ability to solve problems. If every company I applied at asked me of a take home, I’d be spending 40 hours a week just doing that. Like a second job!
And guess what? I’d probably use co-pilot to do most of the assignments for me now that we have the technology. And if the company doesn’t like that, I probably wouldn’t work there anyway.
We use code assistant at my current job. And we don’t ask for tests or assignments.
When I interviewed there, there were 5 rounds. I spent over 6 hours in total preparing those interviews.
When I was interviewed by my future teammate. I presented them with a system diagram of how I imagined the product was designed and built. They were impressed, it matched very closely to the actual design.
As a candidate you have to have something to show. Maybe a personal project, an open source contributions,etc.. and if the company is unwilling to use that material and insists of giving the candidate non sense tests or take home, it just shows the company doesn’t get it. I have 30+ years of experience and have interviewed countless people as well as being interviewed. The best way is to have the candidate actually interview you. Let them drive one of the interviews that will tell you far more than technical assessments.
@@amirnathoo4600 I agree and we actually do those interviews as well. We don't restrict applicants to use co-pilots or ChatGPT to generate their code, but we do check on certain concepts which I think it will be difficult if they just copy-pasted their answer. If they can better enhance the generated code and understand their changes, we're fine with that. We mainly challenge their thought process through their assignments. The potential of the individual is usually what we focus on during interviews instead of technical skills and knowledge.
@@amirnathoo4600 Then you get to the part where they discuss your solution with you....
"Have the candidate actually interview you" I love this approach 👍
Do a pair-programming exercise with REAL CODE instead, don't expect a solution just watch how the candidate works and use it as an excuse to chat about technical stuff.
This enables you to see what the candidate works and thinks like. It also gives the candidate an opportunity to see how truly awful your code-base is too.
I agree with the broken side of technical interview. I was once part of a panel of interviewers. I kind of get ticked by questions from my colleagues for technologies that are remotely not used by the application we're supporting. My only concern in a job interview is the candidate should know the basics of programming. At least how an object (class) works and and idea how to connect to the databases. Because everything revolves around it. Now depending on the level of the candidate needed, I probably need to just know how the candidate solves specific problems (no correct answer on this one as I want to probe how the person solves things) then it's up to the hiring manager who the hiring manager has a feel in having as a new hire.
I agree, if I am hiring a Java developer, I expect the person to know basics of OOPS and how to implement them in Java. I also give a piece of code and ask them to write some testing code for that. That's what I expect the person to do everyday ... Imagine hiring a person based on how much he/she knows about algorithm, datastructure etc and takes 6 months just to understand how a small microservice is designed (coz most of the times the leetcoders have never seen a real enterprise app and barely know anything that exists outside `public static void main`).
@@NiranjanNanda and there's a lot of abstraction already in implementing lists, queues, and everything in .NET or Java that we don't need to bother anymore. We have a ton of bigger problems to face than focusing on every nook and cranny details of programming. That's why we have open source to help the community on specific details. My specific problem might be solved by someone else in the community that they are very happy to share to you their solution. And you might've solve some specific problem that someone else is looking help for. We don't need to be a jack of all trades developer because the community is there to help us and hopefully we can help them too.
When I interview people for a developer job, I usually get them to talk about stuff they built earlier, and how easy or difficult it is for them to explain it to me. I'll try to get them to draw a few diagrams to summarize the system.
Because I believe the most important skill for a developer is to take a step back from the details and create some overview / abstraction. And this test also gives me insight into how they will function in a team, and the level of complexity the person can handle.
Technical interviews are a joke. I will give you an example gathered from my own experience
You interview for company X, they accept you, give you an offer and you decline it for the moment OR they close the position, even though you passed it.
You interview for company X 2-3 years later and have to go through the same process again, yet for some reason, this time you do poorly on their shitty 1 hour Codility or Hackerrank test. So they reject you.
So the company saw you as great, whereas now it sees you as not great. In this time you have gained expereince, however.
So it doesn't make any sense
Heheee...man! amazon, google are even bigger jokers....i always think how is it even possible that you take hours of interview....rounds and rounds of tech interview ...which means you hire the best among the best in the market...and then you lay them off saying they don't perform (i am sure this is the reason most laid off employees get)...
and, look at the money these interview prep companies are making. they're the real entrepreneurs coz they took advantage of this broken aspect....lol....
Look, I'm going to level with you. As a director of engineering I dramatically increased the difficultly of our interviews after I walked into my new job and discovered that two-thirds of our senior developers couldn't write code. Like...couldn't write code that I would expect an intern to write without much hand-holding. There's a point where the calculus becomes "It's cheaper to miss out on a good hire than it is to hire a bad fit."
Much of the motivation behind skill interviews seem to be as an automated way to cull candidates down to a shortlist worth the time and effort to sit with a human interview panel. The criteria for culling them are almost irrelevant, as long as it gets you down to a short list of candidates that you can talk with.
Just pick half at random, because you don't want unlucky candidates!
(I do not take credit for this joke)
Suppose I'm a nurse and applying for a new nursing job. I'm not sure how that works, but do I have to prove to them I know how to be a nurse? I mean, I have a nursing degree; I'm holding a certificate from an accredited organization that vouches for my knowledge and skill of nursing. I've worked as a nurse before. I have references. Etc. Etc. It's pretty binary I would think. Either I have the skills to be a nurse or I don't. Technical programming interviews are a subjective, pseudo-scientific process. It's also highly competitive. The idea that there aren't enough developers in the world is total rubbish as far as I can tell.
Interviews are just never enough time to get to know someone and how they work. It's hard to get a sense of what someone's going to be like on months or years long projects when you've only spent 1-2 exhausting high tension hours in a room with them not working on a real project.
Agreed. What do you suggest?
>you're more likely too succeed if you attend interviews
Well the problem is - on many markets (not only the US) - it isn't easy to even get an interview these days. Getting consistent zero response after applying and no contacts on Linkedin (ah the fantasy of developers getting actual/fitted offers on Linkedin en masse - lovely lie). You can't even tell if you're good or bad if your workplace has zero mentoring options.
I get a small trickle of recruiters. They always get your resume by searching for keywords and having you show up because it's on a resume that you let LinkedIn index.
I agree, interviews are a terrible way to judge someone's skills. Just like exams in school. One of my favourite "tests" for an interview is to give someone some buggy code, and see how they debug it to figure out what's wrong. You can learn a lot about the interviewee from this, as you' testing their knowledge of the language and logic and many other aspects all at the same time. Let's be honest, a lot of time as a developer is spent debugging.
School tests are different. Because as a student you should know things...many things...even if you don't become a biologist or a physician, you still need to learn biology. But in a software company it is hugely different...you become a leetcoder and get hired to write code or test a springboot application... 😀
FANTASTIC! This is where I am now, and this video is very validating and inspiring. I do think it’s a bit of a game and you just have to practice playing it.
The interviewers should know well in advance to which project they are hiring and what skill are required in there. This hardly happens and so the broken process and nobody till date knows how to fix this core problem.
I went to an on-site technical interview consisting of a timed test working on a unfamiliar laptop, using the squishy built-in keyboard, touchpad with no mouse, debugging Visual Studio on a tiny screen. It was an exercise in frustration just trying to move the cursor to get to the right window, let alone think clearly. The real issue was that it exasperated me so much the rest of my interview was completely off and I didn't apply for another job for months 🤬 Crazy tip #1, take a mouse with you 🐭💻 Crazy tip #2, practice writing simple code with a pen in case a whiteboard makes an appearance. It is easy to learn, but you need to visualise your function/method before you start writing it 🖊 Tip #3, find online tests and beast them. Also look at IQ tests as these type of questions crop up regularly FFS! Tip #4, find some respectable social media influencers who post about your tech stack and review their latest stuff. Tip #5 read books. Tip #6, learn from your experiences, if required take an iterative approach, don't repeat your 'mistakes' and DON'T give up 🧠
I wouldn't want to work for a company that lets me be interviewed for a programming job by a non-programmer. Or for a management job by a non-manager.
I'll take a portfolio on $forge over a technical interview any day, on either side of the desk. An interviewer once asked me "what is your desert island technology or design pattern, and why?" and I feel once you get someone with experience talking about their favourite tools you can tell how deep they go on their assigned tasks. Obviously that doesn't tell you about whether they are good to work _with_.
My desert island technology is a machete
I have been a contract programmer most of my life. If someone says send in your resume I say OK and forget it. If they say come in, bring your resume, and lets talk; I go in. Then I am usually talking to the director of engineering who needs to solve a problem. I get hired.
this video nailed it... totally! Good work and kudos to author.
Since been made redundant last year I've been to dozens of interviews and most have been an absolute joke. There's the ghosting after the interview (and by the agent so they possibly knew there was never a job) and the irrelevant questions.
I'd never heard of leetcode (and never needed to over my long career delivering quality software) until I did some digging after having to solve some irrelevant exercises in an interview - so great, I started doing them and now I'm solving them many times faster than at first... so I'd pass these same interviews but I'm the same developer a few weeks apart.
Worst interview experience though is been asked the Friday before an interview to deliver a presentation (cos I've nothing else to do right) then asked also to bring in some real good from a previous project for them to review??!!! Even if I had some (I dont)t his would be hugely unethical for me and surely illegal? I declined on moral grounds - and who know's what they'd expect me to do as part of the job
As soon as I heard biases and assumptions and gate keeping I knew it wasn't going to be about technical skills and how to test them
"Take away technical test's that should only take about 1/2 an hour" are my Achilles Heel. I'm no idiot (well, I like to think I'm no idiot) but I have a perfect 100% failure score on take away technical tests.
Do a pair-programming exercise with REAL CODE instead, don't expect a solution just watch how the candidate works and use it as an excuse to chat about technical stuff. This enables you to see what the candidate works and thinks like. *It also gives the candidate an opportunity to see how truly awful your code-base is too.*
Great subject! and timing 😊! since I've been having a lot of interviews in the last couple of months 😊 Thank you and greetings from Argentina.
The proliferation of LLMs has destroyed the usefulness of take-home projects and online tests. They were of limited worth already, and now we have fewer tools at our disposal to vet candidates.
Living bags of biases and assumptions! I choked on my drink. Good way of putting it!
So so burnt out. wish I could really get the willpower to study.
I like to give a candidate code to review. It’s a core skill, it’s directly applicable to the job, and it’s great vehicle for conversation around their answers.
Being disabled in this....very very narrowed minded industry....has lead me to one truth....Joker is right
"Tell us about a technical challenge you faced and how you overcame it" - One can prepare/lie to answer it, not sure it's a good way to rate technical skills.
They can ask in detail about your knowledge of the subject. Especially if it is in their expertise, it is very hard to fool them. If you take time to prepare such elaborate lie, might as well do it for real.
You would be surprised how many candidates I’ve interviewed that stumble on that question. The worse answers were the ones that told me they never faced any. Immediate red flag.
Maybe I don’t understand the question then, been successfully delivering automated execution software for various asset managers I’ve worked for. Whenever there’s a unique/specific requirement, there’re solutions available offered by the language itself or by different contributors. Trisha’s disruptor is one of them, and I know, it was born out of a real challenge/unique requirement. I think, being aware of tech/framework available and applying them accordingly is part of the job. I’ve never encountered a requirement that has been a technical “challenge”. What keeps me awake is ensuring each release is reliable, and I am not alone here.
If you are a competent developer then you can figure out how to reverse a linked list, even if you've never had to do it before.
The ability to visualise data/relationships, and write code to manipulate such structures, is absolutely fundamental.
True. The problem is that an incompetent developer who has spent a couple hours on leet code will do it better because they have learnt that pointless skill.
Tech interviews is a shitshow to legitimize biases.
Are you guys getting interviews? 🤔
Maybe, just maybe, most people (at least half), including those who are loath to code/program/etc can actually learn to program, despite misconceptions, if they were faced with it. THAT is enough reason for me to hire them, ceteris paribus. I see the unwitting lot landing on a distant shore, & I am quietly fired up, energized that they have chanced to embark. Another, when pressed to look, might see them get as far as the parking lot outside, wave out the glass window, & wait for the spaces to empty once more just for another opportunity to admire the achievement of the impeccably architected parking lot.
love the T-shirt 😄
This might not work for all of you, but I make demos for the position I'm interviewing for. It doesn't have to be fancy, but it gives the interviewers--especially non-professional ones--an example of what you can really do and how well you're able to present.
Once I was asked how many levels of inheritance C# supported like that was something every engineer should know by memory.
Maybe don't hire anyone who knows that answer because they've probably hit it through poor design.
I love point 3. I didn't know I could do that.
This! (Thank you.)
There's actually no problem with the types of activities that people do in technical interviews. Whiteboarding/LeetCode problems are wonderful jumping off point to start to learn about how someone approaches problem solving, and yes even their technical knowledge and coding style. As long as you don't place any weight on whether the candidate actually solves the problem the fastest.
The problem is that whiteboarding questions aren't used as a jumping off point anymore. Instead interviewers, and especially groups of interviewers working together on committee, commonly throw out all of the valuable subjective observations from interviews, and base their decision on factors that they see as more objective. Instead of judging whether somebody showed good reasoning, skills and communication skills during their technical problem, they simply rank highest whichever candidate finished the problem fastest or with the best solution.
This is a common theme that plagues all kinds of processes. Scrum user stories have the same problem: people want the simple objective formula "as a ___ I want to ___ in order to ___" and end up focusing on formulas and process, rather than using the process as a jumping off point to get to the real thing.
Great video !
Living bags of biases! I’m stealing that one!
lying well is absolutely an important skillset. the company is never honest why should you be?
Amen! I want to be a farmer now, the hell with this tech industry.
With 44 years working in IT, a programming test is an insult. I know Java23, but in practice I still have to use Java11, because the tea is not agile at all. So a test will be done with the latest features, so the team will not understand my code with theis obsoleted java8 knowledge.
I'm a software engineer of 20 years and now a hiring manager. If you're trying to get a job as a developer, poorly designed technical interviews are worthless and a pain. But if you're hiring, well designed technical interviews are a MUST. Many developers are awful at coding and at talking about code. You owe it to your team and your company to weed them out. The only other option is to plan on firing people when they don't work out, which is far worse than hiring the right people in the first place.
I think that depends. I have worked in environments where we did use the probationary period of people's employment as a sanity check. We were doing VERY difficult things, and not everyone could cope. This was horrible, on the few occasions when it happened, but I always warned people that that was how things worked before hiring them and we did our best to give people who were struggling the best advice that we could, and the chance to improve.
I always thought of this a rather like playing elite sports. It is simply true that not everyone can work at that level, and you can't always tell by talking to them for a few hours. It is not always possible to "hire the right people in the first place" however hard you try. So as well as trying as hard as possible to "hire the right people" you MUST also have strategies to recover from mistakes.
As a hiring manager myself, I agree. But the technical questions must be well thought out actually represent skills and characteristics you seek. We may employ, instead, a non timed technical exercise, where we can see how well someone can follow instructions, think and communicate clearly, etc.
I agree that you have to see them code. That's exactly what I do when I administer a coding interview - I give them a problem that isn't too difficult, but involves some fair amount of coding. I let them use their preferred language, and I observe them. After half an hour, i have a pretty good assessment of their language fluency and comfort writing code.
The problem is that most companies equate coding skill with leetcode style algorithmic puzzles. Being able to come up with the correct dynamic programming solution, or knowing how to perform a topological sort, or when to use a monotonic stack - these things aren't evidence of coding proficiency. It's evidence that the candidate has practiced a lot of coding problems on Leetcode. The Internet giants like Google who normalized these kinds of interviews know that they have zero predictive power, yet they continue to do it because for all of their money and resources, they can't think of any better interview method. I myself am currently at almost 700 problems solved on Leetcode, and I've reached a point where I can pass coding interviews fairly consistently, but I wish it weren't necessary and I wish I could get the hundreds (if not thousands) of hours of my time back.
I always bail on technical interviews that get me stuck for hours solving a logical math problem that 3rd graders thought it was cool. In reality, if you're not using Google stackoverflow and reading massive documentation on random forums, you're not really a developer. So, such tech interviews are bs, irritable and I doubt that you prove anything besides moon logic.
This video is awesome. Unfortunately, the hiring process is the game. And we have to play it.
This is the attitude that keeps this nonsense going. I tell all recruiters that approach me I refuse to do technical leetcode screens. If they want to know what I know I'll walk them through one of my many technical projects or do a take home assignment. I was hired recently with no leetcode crap whatsoever, I'm on $115k plus benefits.
Vast majority of the companies just send a time limited coding test. Even sometimes the time is finish until you understand the issue on the test. Who are really working under these circumstances at the real life. Okey this is the issue, make it in 2 hours, why??
And also they are just asking 5-min-google-search questions. Really :) :) (?)
data structures and algorithms are the great filter - it shows those who put the time in to prep, understand, choose the right tool and practice to the point of being able to reproduce from memory
Absolute nonsense. This is a job your going for, not second year in college. I've worked with complete oddballs who aced the tech screen but you wouldn't put them in front of a client. Ever. How does learning by rote show you that you've just hired a weirdo who wont fit in and wont excel?
@@Etcher I agree 100% that this kind of test is absolute nonsense - however, i dont make the rules of the game.
To @JReiben111 point. In a competitive job market you need to know the secret handshake essentially. If you pass that step you can usually leverage past experiences and speak to projects you helped deliver. Ideally you have a couple prepared that you can go deep on.
A few years ago I was interviewing for a Java developer job at a local startup.
One of the interviewer was an Intern. He showed me some code and asked me what was wrong with it. He was using an IDE I was completely unfamiliar with so I was a bit slow in tracing through the code..
As I was about to tell him what was wrong, he got frustrated and impatient and gave me the answer.
At the end of the interview process I was told I didn’t get the job because they needed someone who could “hit the ground running”…mind you I have 24 years of experience in Java…17 years of which it was my primary programming language.
I told the company..beware of who you are looking for. If they “hit the ground”, chances are they’ll get hurt first..and never be able to get running. I ended joining another startup and capitalized on unique skills that are in extreme high demand today in the fields of AI and Robotics…And I have swapped Java for Go and Python 😂
Some interviewers seem to show of how good they know stuff.
The most difficult problem in software engineering is interpersonal communication. Therefore, a good interview should test a candidate's ability to talk about code and the ideas behind it. Even dead simple code can be surprisingly good fodder for conversation.
Asking a candidate to write code is unnecessary. If the question is trivial they should be able to describe the code verbally, which demonstrates their ability to communicate. If they need to write the code at a whiteboard or a computer in order to explain it, that's actually a red flag.
I am afraid that I don't agree with that. Certainly the kind of code exercise that assumes that there is one true result is stupid! of course communication is the key, but there is a difference between spoken and written communication, let alone communication through code.
I would certainly always spend a lot more time talking to people about their ideas and trying to understand how they approach the problem solving at the heart of what we do, but, sometimes, depending on the person and the role, it is helpful to see how they write code. I have met many, many developers who talk a good game and write terrible code. The best ones can do both, but talking a good game doesn't naturally demonstrate the ability to play a good game.
Last rejection was because they failed to get zoom to work 😂
Sad
I believe that the technical interview should be skipped if the candidate has a code portfolio or certifications that already prove their abilities. Many companies practice cargo cult interviewing.
both can be faked, I've interviewed people who's portfolio and cert should mean they can answer basic questions. When asked, they totally drop the ball.
This is a good video. It would be a great one if it touched upon how capitalism makes the interview process worse off. Engineers have always been at the frontier of exploitation - from laying down the railroads by expropriating land to the internet-scale data expropriation to feed AI. This crucial role cannot be entrusted to people who haven't been ideologically browbeaten. Imagine if the engineers revolt or even do the bare basic by unionizing 😅 Therefore, organizations create a gauntlet of an interview process that drives people to be individualistic, narrow-minded, and constantly focused on the unnecessary and irrelevant.
Technical interviews are an example of the Drunk and the Lamp-Post parable. They reveal the incompetance of the hiring team and reveal very little about the interviewee. If technical skills are so important to you then ask for a certification. Be more respectful of people's time.
And therein lies the problem: there is no universal 'certification' method in the IT industry. In the accounting profession you have to undertake your training and qualifications to obtain your certified professional accountant qualification and be a member of the professional institution in your country. Until you get that, you are a junior and you can never hold a position of leadership or authority. Most other professions are the same: engineering, architecture, medical etc. Even the trades have this. The IT industry is way behind. The UK, Australia and Singapore for example, all have their respective Computer Societies. These are the recognised professional bodies in those countries but they are not mandated like in the accounting and other professions. They absolutely should be. Once we have that, then a large amount of the nonsense we see in IT interviews will disappear because proper professional qualifications will ensure that candidates meet given standards and can be measured as such. At the moment, they can't.
Use Guerrilla Tactics...
This arguments about synchronized in Java is feel-good bollocks. There’s no way you can write threadsafe code if you don’t know the basics. There are better and higher level abstractions, but I don’t believe you know what even a race condition is, if you don’t know synchronized.
I think, in a face to face interview coding task can help to save more time.
I had a candidate with a good speech, he knows few languages, so gave him simple task: reverse string.
Code logic looked almost good. But he failed on basic principle. He used immutable string as mutable char array.
The last time I was looking for a job, I had 7 interviews in one week. After such a marathon, everything became incredibly easy.
I never had a problem with technical interviews and looked forward to them. I bet I would fail "behavior" interviews.
Anybody else have an instant reaction to Head First Design Patterns?
I know lots of people love it, but I hated that book. The "repeat everything 3 different ways" writing style made it feel excessively grindey to read as well as useless for later reference.
Do you wear this T-shirt in real life? It will be fun to have an interview with someone with such T-shirt :)
I do wear it in real life! It's so good, I can just point to the word when someone asks me a question
My gut feeling is that this woman didn't work in a position of a team leader as a software developer.