401–410 of 493 posts
I've recently had a couple technical interviews where they were structured much more like a pair programming session. Those were a great experience on my end, and for the interview I expect it gives a much more realistic view of what it would be like to work with someone.
> When was the last time you had to debug an ancient codebase without documentation or help from a team? All the time. 300-400k SLOC in C++. Legacy in the sense that there were no tests of any kind. Little-to-no documentation. Solo developer at the tiny company. Fix bugs and add features while keeping the system available to the tens of thousands of users. A more recent example: here’s a patch for a critical feature…
If you didn't solve your problem in 45 minutes with zero assistance from tools or Google or colleagues, were you immediately fired?
Earlier quoted context omitted.
But is there a good way to find the "better possible hires" which doesn't have other significant disadvantages? If you have a convincing method of doing that, many companies would be interested in your ideas.
Yes, ask give interview tasks which are realistic depictions of the actual job tasks. No, the hiring managers that are into cargoogle culting are not actually that interested in how to do interviewing properly. Not unless, say, google does it and they can copy it. For them the important thing is that leetcode is a safe, defensible choice because "everyone else does it that way".
What would be a "proper" interview in your opinion?
Earlier quoted context omitted.
I've come around to the idea that all people who will be expected to write code as part of their job need to be evaluated for their ability to write code as part of the interview process. I've seen too many people write convincing and impressive resumes without a single ounce of technical ability to their name.
You're hiring for a senior role, not a junior or mid. Your candidates aren't fresh out of school or just starting their careers. They already have plenty of work experience. They already know how to code and have been doing it for years. A conversation will tell you much more about their approaches to problems solving, team work, and mentoring than a coding challenge will. Looking at their GitHub, their work experien…
Through all of the technical interviews I've run on behalf of multiple companies, I've become convinced that our industry is full of imposters. A terrifying number of people who are employed as developers cannot code, beyond making tiny edits to existing code, or slinging StackOverflow answers and AI generated content around. They cannot think for themselves. They rely heavily on their coworkers to make any substantial progress. If anything, modern AIs have made these people more difficult to spot. I've found these imposters within the companies I've worked for too, and if it's not possible to move them to a non-technical role where they can be productive, then it's best to fire them. If that isn't possible, then keep them out of the way of any critical work, but know that they'll continue to be a drag on their team, and will decrease the moral of those on their team who have to keep covering for them.
Once I even worked on a team (as a junior) where only 3 members out of ~16 even knew the language that was exclusively used for the job. The remaining team members accomplished nothing every day. Those stand-up meetings were painful. Drawn out to 45+ minutes of standing in a circle while the unproductive team members found new ways to explain why they haven't made progress. Then I'd see them return to their desks, and not even open their IDEs for weeks at a time. They seemed to keep their jobs because their boss didn't want to fire them, and it cost him nothing personally to keep them around, offering them a sort of corporate welfare. Perhaps having such a large team even helped him politically, but it's unclear if he cared about that since he also spent almost all of his time slacking off, playing games in the break room, while the 3 productive team members carried the rest of the team.
Earlier quoted context omitted.
If I'm interviewing for people to work in some specific tech stack or business, it's just as good to see completely different things they can show. Could be a php site for their book club or whatever. But the key is to have some code to discuss that is their code. Because I want to see them describe and reason about code they know, and it works 10x better if it's code they know, rather than some code I present and sa…
Why not discuss a problem you have? You're obviously hiring for someone to solve your problem. Looking to check if they can code (in a specific language) seems like the XY problem.
Reasoning about a problem i have (even showing some code) is also a good part of an interview. But it's my side of the field. I just found it's much better to move the interview to the interviewee's side of the turf, because they are more comfortable there.
Earlier quoted context omitted.
Sounds like the system worked exactly as intended then. A seemingly smart person got a good job. What's the problem with this story exactly?
Apparently they expect people to work for free for more than a month to learn material they then won't use. In my mind that's a rather nasty practice. Not that I'm complaining. I'm happy to pick up people that are good at computers but wouldn't be able to pass that hurdle, and probably wouldn't hire anyone that has.
You're looking for people who feel like they can't be bothered to learn some of the science and fundamentals of their craft? And you'd actively oppose hiring people who have the determination to go the extra mile? You'd actually discriminate against people who know how to use basic data structures and algorithms, and have that enriched landscape of knowledge to apply to problems that might come up?
Fortunately for you, there are lots of these people available to hire who felt like they are too good to put in the work.
I'm not saying that the data structures and algorithms knowledge is needed to do most software engineering jobs on a daily basis. But for lots of jobs, hiring people with a demonstrated willingness to dive in deep and learn things that aren't necessarily easy or fun actually can be a very good thing, because a lot of engineering problems require a similarly difficult dive into some aspect of specialized domain knowledge.
A small anecdote. A partner of a friend quit their job earlier this year. They then took 4-6 weeks to prepare for each interview with Big Tech companies (4-6 weeks for Meta, 4-6 weeks for Stripe, etc.). Along the way, they also took random interviews just to practice and build muscle memory. They would grind leetcode several hours a day after researching which questions were likely to be encountered at each Big Tech.…
Your friend is not alone, and I don't understand what separates us. Even when I was early career, system design was my favorite.
My biggest issue is performance anxiety when there's a concrete problem to solve that I've never seen before, so coding sessions are absolute hell. Inability to focus, forgetting approaches I've known forever, etc.
Ask me to do system design though, and it's generally freeform, I can talk about different approaches, deep dive on the fly, and draw a nice diagram or many nice diagrams, and interviewers love me and think I'm smart. I've had interviewers who were suspicious after my bad coding performance try to nail me on esoteric implementation details but because I have actual, hard-earned experience I can pretty much explain any approach in my niche and then tell you all the tradeoffs. I can also quickly code up examples, etc. Never had a bad feedback on this portion.
Something about the complete detachment of the coding problem from real life is such a huge mental block and I am continuing to fight it 15 years into my career, after dozens of similar interviews.
Earlier quoted context omitted.
I've come around to the idea that all people who will be expected to write code as part of their job need to be evaluated for their ability to write code as part of the interview process. I've seen too many people write convincing and impressive resumes without a single ounce of technical ability to their name.
You're hiring for a senior role, not a junior or mid. Your candidates aren't fresh out of school or just starting their careers. They already have plenty of work experience. They already know how to code and have been doing it for years. A conversation will tell you much more about their approaches to problems solving, team work, and mentoring than a coding challenge will. Looking at their GitHub, their work experien…
Having hired many developers over multiple decades, let me assure you that you should definitely make sure they can actually code. Do definitely have those conversations, too, but trust me when I say that a technical conversation, a degree and several listed years of experience as a software developer on a resume are not enough to guarantee that they can actually code.
I recently ran an interview process for a relatively senior eng role at a tiny startup. Because I believe different interview methods work better for different people, I offered everyone a choice: 1. Do a takehome test, targeted to take about 4 hours but with no actual time limit. This was a non-algorithmic project that was just a stripped-down version of what I'd spent the last month on in actual work. 2. Do an onsi…
> ~90-95% of candidates chose the takehome test I was expecting "3. submit a code sample" to be the overwhelming winner here - did anybody choose that? Seems like a no-brainer, since it's already done...
As others have pointed out, there are a lot of problems:
- Many engineers don't write code outside of work and so don't have much code they can show off without breaching their employer's trust
- Those that do often don't have recent code.
- Those that have recent, personal code to show off have often written it to accomplish some goal and the code isn't necessarily a great example they feel like showing off
Really, the only people I've seen have good code samples are those who do extensive open-source work. And for those people, I'm probably already aware of that work when I checked their resume + opened their github.