by tomaszs on 1/16/24, 11:31 AM with 90 comments
by neonate on 1/16/24, 1:46 PM
by rco8786 on 1/16/24, 12:04 PM
by your_friend on 1/16/24, 11:56 AM
But if we look from the perspective of the company – maybe it's just an filter to get someone very dedicated and nerdy about programming. Less churn, less questions.
by epolanski on 1/16/24, 12:01 PM
by RcouF1uZ4gsC on 1/16/24, 12:14 PM
However, those activities tend to reveal information about their abilities that are useful in an actual game.
Similarly, while you may not be doing those coding problems in day to day development, those coding problems can (ideally) reveal information about your knowledge and abilities in hat does apply to daily coding.
by cturner on 1/16/24, 12:44 PM
Candidates: you need to appreciate how difficult it is to hire good people, the dishonesty of many candidates, and how limited the tools are for identifying talent and filtering out weasels. It is true: party trick Big O questions have low utility in most jobs. It is true: there is talent out there which sucks at Big-O questions. It is true: there are people who are good at little else than the party tricks. Nevertheless: those questions provide an objective judgement about a candidate. That objective judgement is valuable.
You spent several years doing a degree to make yourself employment-compatible. You will be able to achieve this standard in far less time, and there are cash rewards at the end of it. Accept that you will need to burn 1-2 months to develop this capability, and that you will feel awesome once you have.
Get /Cracking the Coding Interview/. I was not impressed by the object-oriented design chapter, but seek to master the other first-11 chapters. Take what you need from the remaining chapters. Develop a set of flashcards. Find problems online. Work intensively for at least two weeks but ideally a month. Then book some interviews at firms where you don't mind if you fail. Some of the FAANGs have awesome pre-interview study material. Try to get into process with a firm like that. Keep training on your flashcards and doing a few problems a day to keep in form. Expect to struggle with early interviews. Learn from those experiences. Revise what you made a mess of, keep working with your flashcards until you have mastered your weak areas. Now start applying at the firms where you want to succeed.
by mike_hearn on 1/16/24, 12:10 PM
https://blog.plan99.net/in-defence-of-the-technical-intervie...
It is, natch, hosted on Medium, so you will see a banner, but unlike this paywalled article it's dismissable. Just click the X to make it go away and then you can read the whole thing for free.
The summary is that many interviewers ask "unrealistic" algorithmic questions because:
1. They fit in the short amount of time available.
2. They get people writing programs that cover all the basic features of the language.
3. They don't ask people to do excessive amounts of work (e.g. takehome assignments)
4. They wash out people who lack basic skills you'd expect programmers to have, like actually starting a new project and being able to compile/run it in their self-chosen editor.
5. They are general and don't tend to require knowledge of specific frameworks or even specific languages.
The questions are unrealistic because they're designed to be fast ways to extract information in an interview setting, not to actually be an accurate sample of the daily work (which in the time available may only cover a fraction of the skills required of a working programmer).
by valval on 1/16/24, 11:51 AM
by can3p on 1/16/24, 12:21 PM
Now, about the scale. Anything run at scale needs standardisation. You need to hire 100 senior developers. How do you know they have more or less same level? If every single interview is hand crafted, you'll either need to get all devs envolved (and not everybody is good at coming up with interview questions) or get standard questions and answers to allow a smaller group of people to deal with candidates and coding puzzles fit great there because they're slef contained and isolated. Every realistic question has multiple facets and that's what you get at the system design interview step.
Another problem I've observed was that the more you give the same puzzles to candidates, the easier they look to you. What the means is that you as an interviewer either need to keep your self in check regarding your reactions or you're risking giving a bad interview score in situations where it's not really warranted or there is a chance that the next question you take will be the one you find more complex (to be equal to position level in your head) and that would push the level of questions up. That's another observation I had when some interview questions would become so complex that I knew some of the existing devs would fail the interview for sure.
Does that give good results on the other end? I don't know, but what we definitely know is that there is the whole industry around leetcode to train peeople to pass these challenges specifically and that means that they only thing the interviewer know is that the candidate has put some effort to prepare for the interview meaning they're motivated to join the company. And maybe it's not the worst data point! Some companies actually explicitly mention this fact on their hiring pages.
To add to it, big corps have different ways to make interviews objective in whatever sense they think and that by definition reduces the personal impact. "Why did you ask this question? We've never done it before, we'll need to have a group call to calibrate". After a handful conversations like this you'll just stick to the standard process.
Is there a way to come up with a more human approach? Personal recommendations with some skin in the game I guess. I'm sure in some niche areas like browser engines all good devs know each other well and no interview is often necessary.
by woliveirajr on 1/16/24, 12:06 PM
Sometimes they are not worried about the specific answer, they're trying to find out your (software engineer) unconscious mind reveals during the process.
by ochronus on 1/16/24, 12:34 PM
by annabyrd on 1/16/24, 12:16 PM
by dave333 on 1/16/24, 2:41 PM
by nunoonun on 1/16/24, 12:05 PM
I thought this was a well known.
by farnulfo on 1/16/24, 12:19 PM
by prakhar897 on 1/16/24, 12:09 PM
No Thanks.
by pydry on 1/16/24, 11:52 AM
by huqedato on 1/16/24, 11:58 AM
by commandersaki on 1/16/24, 12:14 PM
If this is about screening potential software engineers with programming questions during an interview, hasn't this always been a thing even before Google popularised it?
I started my career after the dot-com era but it was in Systems Administration, so I didn't get to experience any programming style interviews until I changed careers and attempted an interview in 2008 with Google.
But hasn't this been the standard modus operandi for big tech companies like Microsoft, Sun, Oracle, IBM, etc. even in the 90s? I recall reading this [1] article from Casey Muratori about programming questions for a Software Engineering intern at Microsoft.
I'm not against this style of interviewing, but I do also think that some questions can be absurd or unnecessarily tricky. I've had my fair share of programming interview questions, and I found my solve rate to be around 3/7 for my last interview with Google back in 2015. Some of the questions posed were really tricky, and I just don't have the ability to solve in a timely manner without properly experimenting with the problem. From my impression and perspective, interviewers would sometimes choose questions with high coolness/leetness factor instead of choosing something more practical for a 30-50 minute session.
[1]: https://www.computerenhance.com/p/the-four-programming-quest...
by _aaed on 1/16/24, 12:02 PM
by hipadev23 on 1/16/24, 12:13 PM