Tag: interviewing

The New Version “F1 Help” of the 00s – Code Challenges – A 2nd Rant on Modern Interviews

Hey folks, let’s take a trip down memory lane. Some of y’all remember the good ol’ days of the early 2000s when we’d hit F1 and magically summon the help documentation to save us from our coding woes? Ok, maybe it was Stackoverflow then, but regardless we had a whole set of companies that thought it a good idea to base interviews off of the documentation, and that became dubbed the
F1 Interview” or “Documentation Interview”. Fast forward to 2024, and here we are, stuck with the modern equivalent of that dreaded F1 interview: the infamous “code challenge” in technical interviews. It’s time we talk about why these challenges are the new bane of existence for building effective software development teams.

The Rise of the Code Challenge

Oh the magnificent code challenge /s. It’s like a rite of passage now. You’ve got your resume polished, your GitHub repo gleaming, and your LinkedIn profile looking sharp. But before you can even think about landing that dream job, you’re hit with a coding challenge that makes you question your very existence.

These challenges usually involve solving some obscure problem that you’ll never encounter in the real world. You know the ones: reverse a binary tree, find the longest palindromic substring, or implement a LRU cache. It’s like being asked to juggle flaming swords while riding a unicycle for a bicycle messenger gig. Pointless. Sure, it’s impressive and cool being able to juggle flaming swords on a unicycle, but how often are you going to need that skill on the job?

Continue reading “The New Version “F1 Help” of the 00s – Code Challenges – A 2nd Rant on Modern Interviews” →

The Great Advantage of Meritocracy: How Algorithm Interviews Keep Your Hiring Pipeline Narrow

Ah, the joys of algorithm and data structure interviews. Or as I like to call them, the “let’s weed out anyone who isn’t a robot” interviews. You see, these code challenge interviews are touted as the pinnacle of assessing a developer’s true potential. Because nothing says “I can build scalable, maintainable software” like solving a problem about reversing a linked list on a whiteboard, right?

Let me break down the astounding advantages of these interviews for you.

Narrowing Your Candidate Pool

First and foremost, if you want to reduce the number of applicants faster than a bad odor clears a room, code challenge interviews are the way to go. These challenges are a fantastic method for eliminating a huge percentage of your candidate pool. Who cares about that candidate with 10 years of solid, hands-on experience in system design and architecture? If they can’t recall the exact time complexity of bubble sort, they’re clearly not worth your time. Because everyone knows that bubble sort is essential knowledge in the real-world scenarios you’ll encounter daily. Sure, buddy.

Continue reading “The Great Advantage of Meritocracy: How Algorithm Interviews Keep Your Hiring Pipeline Narrow” →

The Fallacy of “Years of Experience” in Software Development

In the ever-evolving landscape of software development, the metric of “years of experience” has long been considered a gold standard for assessing a developer’s expertise. However, as the industry matures and the complexity of technology deepens, it’s becoming increasingly clear that this measure is not only outdated but often misleading. Let’s dive into why “years of experience” should no longer be the primary gauge of a developer’s prowess and explore what truly reflects a developer’s skill and impact.

The Irrelevance of “Years of Experience”

  1. Experience Doesn’t Equate to Expertise: Merely clocking in years at a job does not guarantee a deep understanding or mastery of software development. A developer with ten years of repetitive, unchallenging tasks may know far less than a developer with three years of intense, varied projects. Quality and diversity of experience eclipse the sheer passage of time.
  2. Rapidly Changing Technologies: The tech world is in a constant state of flux. Programming languages, frameworks, and best practices evolve at a breakneck pace. A developer who hasn’t kept up with these changes may find their once-relevant skills becoming obsolete. It’s not about how long you’ve been coding but how well you’ve adapted to and adopted new technologies.
  3. Innovation and Problem-Solving Over Time Served: Software development is fundamentally about solving problems and innovating. A developer who consistently finds creative, effective solutions and can bring them to fruition is far more valuable than one who simply logs hours. Innovation is not a function of time; it’s a function of mindset and approach.

Better Measures of a Developer’s Skill

  1. Successful Solutions Deployed: A more meaningful measure of a developer’s capability is the number and impact of successful solutions they’ve deployed. This includes applications, systems, and features that solve real-world problems, meet user needs, and provide business value. A track record of successful deployments speaks volumes about a developer’s practical skills and effectiveness.
  2. Longevity and Iteration of Solutions: For developers with 5+ years in the field, an excellent metric is the longevity and continuous improvement of their solutions. How many of their deployed solutions are still in production and actively used? More importantly, are these solutions being iterated on and enhanced, either by the original developer or by others? This indicates not only the robustness and relevance of their work but also their ability to build maintainable, scalable systems.
  3. Breadth and Depth of Projects: Evaluating the variety and complexity of projects a developer has tackled provides insights into their adaptability and breadth of knowledge. Developers who have worked across different domains, tackled diverse challenges, and delivered under varying constraints are likely to have a richer, more versatile skill set.
  4. Community and Contribution: Active participation in the developer community through open-source contributions, technical blogging, mentoring, and speaking engagements can also be a strong indicator of a developer’s passion and expertise. These activities demonstrate a commitment to continuous learning and sharing knowledge, which are crucial traits for staying relevant in the tech industry.

The Path Forward

As we rethink how we assess software developers, it’s crucial for hiring managers and team leads to shift their focus from years of experience to more meaningful metrics. By valuing successful solutions, the longevity and iteration of these solutions, and the breadth and depth of project experience, we can better identify truly skilled and impactful developers.

In practice, this means asking different questions during interviews, emphasizing problem-solving and project-based assessments over resumes and tenures. It’s about fostering an environment where continuous learning, adaptability, and innovation are prioritized and rewarded.

In conclusion, while “years of experience” has been a convenient shorthand, it’s time we move beyond it. Let’s embrace a more nuanced, accurate understanding of what makes a developer truly great. Because at the end of the day, it’s not about how long you’ve been in the game; it’s about how well you implement and play it.

The Toxic Truth About Coding Challenges in Technical Interviews

When I think about the hiring process in our industry, there’s one element that sticks out like a bullet wound with a band aid on it—the ubiquitous coding challenge. It is indeed a horrid mess. While coding challenges are often hailed as the great equalizer, providing a standardized measure to assess candidates’ technical abilities, they can, in reality, be a double-edged sword. Where the edge you cut yourself on draws far more blood than your opponents. Let’s get into why these challenges might be more toxic indicator than beneficial in the context of interviews.

The Illusion of Objectivity

At first glance, coding challenges seem to offer a clear-cut way to compare candidates. You give everyone the same problem, see who solves it the fastest or most efficiently, and voilà—you’ve identified your top talent. However, this approach can be deceiving. The assumption here is that everyone starts on equal footing, but this couldn’t be further from the truth.

Continue reading “The Toxic Truth About Coding Challenges in Technical Interviews” →

Those People That We’re Always Looking For…

I’ve been rereading Joel Spolsky’s “Smart and Gets Things Done”.  His writing style is entertaining.  I’m not always in 100% agreement with the guy, but who ever agrees 100% with anyone right?  However, Joel has a ton of things that are smart, well thought out, and when one pays heed can really help out during the course of a software project.  Since I’ve been writing on this topic lately, I figured it would be a great idea to give this a read and maybe even add my two cents to a few of his passages.

I didn’t get very far and I had already found one bit that I wanted to elaborate on.  This part was in remark to hiring college interns and the fact that the best college students are often already good programmers.

“The good news about our field is that the really great programmers often started programming when they were ten years old.  And while everyone else their age was running around playing “soccer” (this is a game many kids who can’t program computers play that involves kicking a spherical object called a “ball” with their feet (I know, it sounds weird)), they were in their dad’s home office trying to get the Linux Kernal to compile.  Instead of chasing girls in the playground, they were getting into flamewards on Usenet about the utter depravity of programming languages that don’t implement Haskell-style stype inference.  Instead of starting a band in their garage, they were implementing a cool hack so that when their neighbor stole bandwidth over their open-access Wi-Fi point, all the images on the web appeared upside-down.  BWA HA HA HA HA!”

This got me thinking.  I’d like to find programmers who have started a band, chased the girls, played soccer, flipped the images, argued the Haskell points, compiled a Linux Kernal (or two or three), and more.  I don’t want the all exclusive nerd only programmer, because today they’re often not that useful on software projects.

When I’m looking for other developers to hire and work with I want a number of things.  The technical bits are of course important, very much so, but I want to work with developers who know about all sorts of things.  I want programmers that know why financial application development pays well and non-profit work doesn’t, I want them to know about the successes and losses of business endeavors within the software industry.  Most importantly, I want them to be personable, approachable, and interested in life beyond just hacking lines of code 24/7.  Nothing wrong with the later, but that is only helpful for about 20-40% of the time on a project.

Warren Buffet looks for the criteria of “integrity, intelligence, and energy”.  I’m curious, readers out there in reader land, when you’re looking to work with a team or hire a team member what do you look for?  What are some key indicators besides the white board coding questions and technical bits?