Key definitions for this article:

“Code Challenge” Culture: This culture is more of a “do as we say, we’ll grow you as we see fit, and you may then continue with us if you perform accordingly” type of environment. It starts with a more defined, strict adherence to an academic achievement type environment that enforces one do things a certain way and follow a certain path, and to ensure you too will do those things a code challenge is used to gate keep a particular job role. There are obviously good and bad results to this culture, and this article is going to get deep into those cultures.

Wholistic Culture: This culture is more open to getting a larger picture idea of a candidate in the interview pipeline. With more of an intent around having the individual develop the organization and for the individual to learn. The possibility of bringing knowledge that can help one improve the organization is readily accepted as is an individual that might not pass a rigorous academic code challenge to shift arrays, or move bits, or trickle values around a binary tree! There are however, good and bad outcomes to this type of culture.

Caveats: In both cultures there are numerous additional criteria that changes them. In this article I’ll write about them in a general sense, and then when detailing something specific, I’ll state that caveat with a call out.

The Big Organizations & Smaller Niche Organizations

I’m going to use three big companies and three small companies here that have varying degrees of “Code Challenge” Culture. In that, I’ll dive deeper into the problems that arise from a strict “Code Challenge” Culture vs. a Wholistic Culture.

The Big Organizations

• No Zama – This is technology company that has e-commerce, hosting, and related services and products they offer. Let’s say its revenue is about $500 billion and across all these offerings they’ve got several thousand teams working on building and supporting all of these things. This company leans heavily into the “Code Challenge” Culture.
• JoonBugle – This is a technology company that offers hosting and service mechanisms to find things across the internet. This company has a couple hundred billion in revenue and has even more teams supporting and building out these offerings. It also leans heavily into “Code Challenge” Culture, but a little less than No Zama and a good bit more than “LargeStone”.
• LargeStone – This is a software company that builds a wide range of software solutions, some open source but a bulk of revenue comes from enterprise software and respective hosting of enterprise software. We’ll give this company a $210 billion in revenue, and it also has thousands of teams too, and uses “Code Challenge” Culture but not real heavily. As it has matured over time it has used more and more of a wholistic approach for new candidates.

Smaller Niche Organizations

• Developer Consulting of Igor Gatekeeper – This organization has a few hundred employees and relies on a heavily academic and performance based “Code Challenge” Culture. Along with other gate keeping mechanisms it uses, this agency is oriented very specifically toward consultants that produce at X pace consistently.
• Atty Comms – This is a communications organization that doesn’t particularly offer software development but does have a multitude of teams working on their respective communications products and services.
• Starzy – This is a software company of about 50+ developers that primarily earns income, like many companies, from enterprise subscriptions and contracts, but is actively involved in open source and the community at large. They have a wholistic culture and do little in the way of official academic code challenges.

With all those companies described, it is time to get deep into their current outcomes and state of affairs when it comes to “Code Challenge” Culture vs. Wholistic Culture. For each of these I’ll give a % of each culture and discuss their current situational report (SITREP) and what their outcomes have been.

The Big Orgs Culture and Outcomes

No Zama – This company, now that it’s a bit older and has moved into multiple geographical markets continues to hire based on a strict academic “Code Challenge” type of model along with other strict criteria, without emphasizing for wholistic fit and uninterested in improving its own culture to ensure longevity of candidates once employees. For this type of culture this outcome – numerous hires with a goal of keeping the top performers and removing the theoretical lower performing – is the point. However, it perpetuates that top performers end up being missed and often leave from the toxicity of it and the lower performing are often positioned to fail because of the inflexibility of the culture.

In the end the outcome looks like this; a pipeline that has nowhere near the top talent, but instead gets a rough middle demographic of candidates, that are often there for the sole purpose of collecting lucrative salaries and bonuses. Then after a few years leaving to something with a better, healthier, more humane culture.

The outcome, is not particularly ideal. So much so, that the leadership often opines that their pipeline is limited in the markets they have a large footprint, seemingly clueless to having shot themselves in the foot.

JoonBugle – This company, unlike the first tends to have a moderately healthier culture and more humane work life balance for its employees, but still adheres to a strict academic “Code Challenge” type of culture which leads to an interesting gap of folks who regularly – and this is seen even in products as their released – are short sighted on what the overall market looks like or how a product would fit into it.

Because of an increased work balance their retention is marketably higher, while finding work for lower performers to be productive at and keeping high performers retained through bonuses and more choice work. This seems to work, and overall the “Code Challenge” combined with some wholistic hiring practices seems to have done this company well, however without also being massive and having lucrative salaries and bonuses, the probability of having a very limited pipeline of hires would be a significant issue.

Even as it stands, the SITREP for this company remains that the pipelines are slow, costly, and have a mixed outcome result. Lots of candidates, often very competent candidates, go into pipeline and few are hired and fewer tend to remain past six months to a year.

LargeStone – Over the years this company has backed away from the heavy handedness of academically strict “Code Challenge” Culture and focsed more and more on wholistic cultural fit with the additional flexbility of teams organizing more, and having more options to organize as they need, around their respective team and individuals. The result of this is some of the best retention in the industry and – over time as this shift has occurred – a growing retention.

The Smaller Niche Orgs Culture and Outcomes

Developer Consulting of Igor Gatekeeper – Developer Consulting of Igor Gatekeeper embodies a deeply entrenched “Code Challenge” Culture. With a few hundred employees, the organization focuses on consultants who produce at a consistent, high pace, maintaining a rigid, academic, and performance-based hiring process. Candidates are expected to excel in code challenges that emphasize specific technical skills and problem-solving abilities, often rooted in academic principles. This strict approach aims to ensure that new hires can immediately contribute at a high level. While this culture can result in a team of highly skilled technical experts, it also risks alienating potentially valuable employees who might not perform well in high-pressure testing environments but could excel in a more supportive, collaborative atmosphere.

The work however also matches this assembly line style “Do X, only X, and be done” type of work. It’s very much command and control dictate vs. dynamic thinking, something that if lots of Xs need completed as quickly as possible works real well, but for a company working on hard problems that aren’t well defined the need to innovate, invent, or otherwise create solutions and sometimes even find the problems themselves – this is a horrible way to hire and work. The simple reason is, X task often doesn’t exist outside of very well defined problems.

Atty Comms – Atty Comms, a communications organization with a diverse range of products and services, does not heavily focus on software development. This company leans more towards a wholistic culture, seeking candidates who bring a broad set of skills and experiences. Their interview process is designed to understand the candidate’s overall potential and fit within the company rather than just their ability to solve specific technical challenges. This approach allows Atty Comms to hire individuals who contribute to the company’s growth through innovative ideas and diverse perspectives. The flexibility of this culture can attract a wide range of talent, fostering an environment where employees feel valued for their unique contributions, leading to potentially higher retention and job satisfaction.

This is a type of company that can, under the right circumstances, have absolutely stellar high performing development teams. However, in this particular company the leadership is extremely scatterbrained and rarely utilizes or sets up their development teams for success. Often shifting their goals and projects in a way that seems random and haphazard. A prime example of how wholistic hiring is great, and can build great teams, but if leadership doesn’t back it up or doesn’t provide – ya know, leadership – things sort of fall apart anyway. Opportunities not seized!

Starzy – This is software company with around 50 developers, thrives on a wholistic culture and has minimal reliance on formal academic code challenges. This company values community involvement and open-source contributions, seeking candidates who are passionate about their work and can bring fresh insights to the team. Their hiring process is flexible and open-minded, aiming to identify individuals who are not only technically competent but also align with the company’s values and collaborative spirit. This inclusive approach helps Starzy build a diverse team with varied strengths, promoting innovation and a strong sense of community within the organization. As a result, employees at Starzy often feel more engaged and committed to their work, leading to better overall performance and job satisfaction.

In an exception to the norm, Starzy also retaining their employees for dramatically longer than most companies in the industry, even so much as some have worked for and retired – i.e. actually retired, not just having *left* – from the company.

Company Culture Outcome Ratings

No Zama

• Current Hiring Ability:
  • Effective in hiring due to its strong brand and substantial resources, but struggles in maintaining top talent due to the rigid hiring process.
• Hiring for Candidate Effectiveness:
  • Initial effectiveness is high within the first 1-3 months.
  • Effectiveness decreases by 6-12 months, with a significant percentage of new hires leaving due to the inflexible and high-pressure environment.
  • Retention rate is low, with only about 50-60% of hires remaining after 12 months. To note, this retention is pretty low even with the “large corp” or FAANG/MAAAN style bonus pay style which is often tens of thousands, or more, extra on top of base pay over the year. Even with rather large pay packages many people do not prefer these conditions, and being the software industry choose to not stay.
• Street Reputation:
  • Thumbs down. Known for its demanding hiring process and high turnover, leading to a reputation for a stressful work environment. So much so that management has presumed the only way to fill the ranks is to hire via H1-B and other manipulate processes that people join via a naive expectation. Shady, to say the least.

JoonBugle

• Current Hiring Ability:
  • Moderately effective in hiring, leveraging its brand and relatively better work-life balance, but still faces challenges due to a stringent hiring process.
• Hiring for Candidate Effectiveness:
  • Candidates show good effectiveness within the first 1-6 months.
  • Mixed effectiveness by 12 months, with around 70% retention.
  • Some hires leave due to the high expectations and pressure, but the work-life balance helps retain a fair number of employees. But also, one can’t deny the “large corp” or FAANG/MAAAN style bonus pay style which is often tens of thousands, or more, extra on top of base pay over the year.
• Street Reputation:
  • Thumbs up/down. Mixed reputation. While the company is respected for its better work-life balance compared to No Zama, the stringent hiring process and internal pressures are still points of concern.

LargeStone

• Current Hiring Ability:
  • Highly effective in hiring due to a balanced approach combining technical assessments and wholistic fit, and its mature, reputable brand.
• Hiring for Candidate Effectiveness:
  • High effectiveness within the first 1-6 months, as new hires integrate well into teams.
  • Retention is strong, with around 90-95% of hires staying beyond 12 months.
  • The shift towards a more wholistic culture has significantly improved long-term effectiveness and employee satisfaction.
• Street Reputation:
  • Thumbs up. Known for its balanced and supportive hiring process, leading to high retention and job satisfaction. The company is well-regarded as a positive place to work. It’s important to note a company, through a large concerted effort can change their street rep, as this company ~5-10 years ago could barely hire in their geographic area and was bleeding employees (their terminology at the time) faster than they were hiring new candidates.

Developer Consulting of Igor Gatekeeper

• Current Hiring Ability:
  • Struggles to hire effectively in many geographic markets due to its rigid and highly specific hiring criteria. Which does lead to a significant number of *remote* candidates that can be wherever.
• Hiring for Candidate Effectiveness:
  • Initial performance is high within the first 1-3 months due to the stringent code challenges.
  • Effectiveness tends to drop by 6 months, with a significant percentage of new hires leaving or underperforming due to the high-pressure environment.
  • By 12 months, retention is low, with around 65-70% of hires having left the company.
• Street Reputation:
  • Thumbs down. The company is known for its demanding and inflexible hiring process, leading to high turnover and a stressful work environment.

Atty Comms

• Current Hiring Ability:
  • Able to hire effectively in various markets due to its flexible and inclusive hiring practices.
• Hiring for Candidate Effectiveness:
  • New hires are generally effective within the first 1-6 months, with their broad skill sets contributing to diverse projects.
  • However, effectiveness and retention start to wane by 12 months due to inconsistent leadership and shifting project goals.
  • Approximately 60% of hires remain after 12 months, but many are dissatisfied.
• Street Reputation:
  • Thumbs up/down. Mixed reputation. While the hiring process is seen as fair and inclusive, internal management issues affect overall employee satisfaction and retention.

Starzy

• Current Hiring Ability:
  • Highly effective at hiring in their niche markets due to their strong community involvement and reputation for inclusivity.
• Hiring for Candidate Effectiveness:
  • Candidates are highly effective within the first 1-6 months, integrating well due to the supportive and collaborative culture.
  • Retention is exceptional, with around 80-90% of new hires staying beyond 12 months.
  • Many employees remain long-term, some even retiring from the company.
• Street Reputation:
  • Thumbs up. The company is highly recommended due to its supportive culture, strong community involvement, and high employee satisfaction and retention.

Cultural Scenarios Summarized

Through examining these organizations, it’s evident that the culture and leadership within a company significantly impact hiring effectiveness and employee retention. While a “Code Challenge” Culture may ensure technical proficiency, it can lead to high turnover and dissatisfaction. Conversely, a wholistic approach fosters a more inclusive and supportive environment, though it requires strong leadership to maintain consistency and direction. Ultimately, the key to a high-performing team often lies in removing barriers and empowering employees through thoughtful leadership. More detailed insights and recommendations will be shared in the upcoming articles. Stay tuned, and let’s continue the conversation!

More on that, more on all these topics in the near future. I’m always interested in your thoughts dear reader, so comment, subscribe, and let’s get a conversation going!

When dealing with BSON/JSON for data modeling, it’s crucial to adhere to certain best practices and leverage design patterns to ensure our data remains organized, consistent, and efficient. Here, we delve into these practices and patterns, starting with general BSON/JSON schema design and then focusing on MongoDB-specific patterns.

General BSON/JSON Schema Design Best Practices

Schema Design

Define a Clear Schema: Despite the flexibility of JSON/BSON, defining a clear schema helps maintain consistency and readability. Utilize schema validation tools like JSON Schema or Mongoose for MongoDB to enforce rules.

Normalize vs. Denormalize: Decide between normalization, which reduces data redundancy but can lead to complex queries, and denormalization, which improves read performance but can increase redundancy. Choose based on your application’s read/write patterns.

Field Naming Conventions: Use clear, consistent, and descriptive field names, following camelCase (e.g., firstName) for uniformity.

Document Structure

Subdocuments and Arrays: Embed related data within documents to keep them self-contained, and use arrays for lists of items. Avoid very large arrays to prevent performance issues.

Avoid Deep Nesting: Limit the depth of nested documents to avoid complexity and performance degradation. Aim for a flat document structure when possible.

Indexing

Indexes: Create indexes on frequently queried fields to enhance read performance, balancing this against the impact on write performance and storage.

Compound Indexes: Use compound indexes for queries filtering on multiple fields, ensuring fields are ordered based on query patterns.

Data Integrity and Validation

Data Validation: Implement validation rules to ensure data integrity, such as data types and required fields. Use libraries or built-in validation features of your database system.

Constraints: Apply constraints like unique constraints to prevent duplicate or invalid data entries.

Versioning and Evolution

Schema Versioning: Include a version field in your documents to manage schema changes over time. Implement migration scripts for updating existing documents.

Performance and Scalability

Document Size: Keep document sizes within reasonable limits to avoid performance issues. Split large documents if necessary.

Shard Keys (for sharded databases): Choose shard keys that ensure even data distribution and avoid hotspots. Adjust shard keys based on usage patterns.

Security

Data Encryption: Encrypt sensitive data both at rest and in transit. Use encryption libraries or built-in database encryption features.

Access Control: Implement role-based access control (RBAC) to manage who can read and write data.

Documentation

Document the Schema: Maintain clear documentation for the schema, including field descriptions and relationships. Keep this documentation updated.

MongoDB BSON/JSON Design Patterns

What is BSON? Scroll to the end of this post, I’ve added a description just for reference.

Approximation

Description: Store pre-calculated or approximate values to save space and computation time.

Practice: Use approximations when exact values are non-critical, like aggregated data or statistical summaries. Regularly update these values as new data arrives.

Example: Instead of storing detailed log data, store an aggregate count of log entries per user per day.

{
  "userId": "123",
  "logSummary": {
    "2024-07-10": {
      "count": 150,
      "errorCount": 5
    }
  }
}

Attribute

Description: Embed attributes or metadata within documents for additional information.

Practice: Use for adding context directly within the document, ensuring attributes are meaningful to avoid bloat.

Example: Add a createdAt timestamp and status field to a user document.

{
  "userId": "123",
  "name": "John Doe",
  "createdAt": "2024-07-10T12:00:00Z",
  "status": "active"
}

Bucket

Description: Group related data into a single document to reduce read operations.

Practice: Use for time-series data or naturally grouped data like logs. Balance bucket size to avoid overly large documents.

Example: Group sensor readings by hour into a single document.

{
  "sensorId": "sensor_1",
  "readings": {
    "2024-07-10T10:00:00Z": 20.5,
    "2024-07-10T11:00:00Z": 21.0
  }
}

Computed

Description: Store computed values to avoid repetitive and expensive calculations.

Practice: Pre-calculate and store frequently queried values, updating them when underlying data changes.

Example: Store a user’s total order value in their profile document.

{
  "userId": "123",
  "totalOrderValue": 1000.00
}

Document Versioning

Description: Maintain multiple document versions to track changes over time.

Practice: Use for audit logs or undo functionality, storing version metadata like version number and timestamp.

Example: Store previous versions of a user’s profile to track changes.

{
  "userId": "123",
  "versions": [
    {
      "version": 1,
      "data": {
        "name": "John Doe",
        "email": "john.doe@example.com"
      },
      "timestamp": "2024-07-01T12:00:00Z"
    },
    {
      "version": 2,
      "data": {
        "name": "John Doe",
        "email": "john.new@example.com"
      },
      "timestamp": "2024-07-10T12:00:00Z"
    }
  ]
}

Extended Reference

Description: Use additional metadata with references to other documents for more context or improved query performance.

Practice: Include frequently accessed information within the reference to avoid costly join operations.

Example: Embed user names and email addresses within order documents along with a reference to the user’s full profile.

{
  "orderId": "order_1",
  "userId": "123",
  "userName": "John Doe",
  "userEmail": "john.doe@example.com",
  "items": [
    {"productId": "prod_1", "quantity": 2}
  ]
}

Outlier

Description: Handle outliers by storing them separately to avoid skewing the main dataset.

Practice: Identify and separate outliers based on criteria, storing them in a dedicated structure.

Example: Store exceptionally large orders in a separate collection.

{
  "outliers": [
    {
      "orderId": "order_large_1",
      "total": 1000000.00
    }
  ]
}

Preallocated

Description: Preallocate space within documents to handle growth without frequent resizing.

Practice: Allocate space for fields expected to grow based on their maximum size.

Example: Preallocate space for a user’s list of friends.

{
  "userId": "123",
  "friends": [
    "friend_1", "friend_2", null, null, null
  ]
}

Polymorphic

Description: Handle multiple types of related data within a single collection by including type identifiers.

Practice: Store similar but distinct entities, including a type field for differentiation.

Example: Store both Person and Organization entities in a single contacts collection.

{
  "type": "Person",
  "name": "John Doe",
  "contactDetails": {
    "email": "john.doe@example.com"
  }
}

Schema Versioning

Description: Include a version field in documents to manage schema changes.

Practice: Handle schema evolution and migrations, including logic to support different versions.

Example: Add a schemaVersion field to documents.

{
  "userId": "123",
  "schemaVersion": 1,
  "data": {
    "name": "John Doe",
    "email": "john.doe@example.com"
  }
}

Subset

Description: Store only a subset of fields for certain use cases to improve performance.

Practice: Use when only part of the document is frequently accessed, creating a separate collection or sub-document.

Example: Store a lightweight summary of an article separately from the full content.

{
  "articleId": "article_1",
  "summary": "This is a summary of the article.",
  "fullContent": "See the full content in another document."
}

Tree and Graph

Description: Model hierarchical or graph-like data structures using specific patterns for relationships.

Practice: Use parent-child references for trees or adjacency lists for graphs, maintaining structure integrity.

Example: Model a category hierarchy with parent references, or a social network with adjacency lists.

{
  "categoryId": "cat_1",
  "name": "Electronics",
  "parent": null
}
{
  "categoryId": "cat_2",
  "name": "Mobile Phones",
  "parent": "cat_1"
}

By implementing these practices and patterns, we can design MongoDB schemas that are efficient, scalable, and maintainable. Each pattern addresses specific use cases and challenges, ensuring our data model aligns with our application’s requirements.

This is how we harness the power of BSON/JSON data modeling to create robust and flexible systems. Whether we’re building applications that require simple data retrieval or complex, highly scalable systems, these principles and patterns provide a solid foundation for success.

What is BSON?

BSON, short for Binary JSON, is a binary-encoded serialization of JSON-like documents. It extends the JSON model to provide additional data types and to be efficient for encoding and decoding within MongoDB.

What is BSON?

BSON retains the simplicity and human-readability of JSON while adding support for more complex data types such as:

• Integers (int32 and int64)
• Floating-point numbers
• Date types
• Binary data

BSON documents are designed to be traversed easily and efficiently. They are lightweight and performant, making them ideal for fast data interchange and storage.

Why Does MongoDB Use BSON?

MongoDB leverages BSON for several compelling reasons:

1. Rich Data Types: BSON supports a variety of data types that JSON lacks, such as Date and Binary data, enabling more sophisticated data modeling.
2. Efficient Storage and Retrieval: BSON’s binary format allows for efficient encoding and decoding, ensuring that read and write operations are fast, which is crucial for performance-sensitive applications.
3. Compactness: By encoding data in a binary format, BSON minimizes the storage overhead, which can lead to better utilization of disk space and memory.
4. Traversability: BSON documents are designed to be traversed quickly, making them optimal for the frequent and complex queries MongoDB handles.

By using BSON, MongoDB strikes a balance between human-readable formats and machine efficiency, enabling developers to build applications that are both powerful and performant.

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.

Different candidates come from diverse backgrounds with varying levels of access to resources, time, and prior experience with such challenges. A fresh graduate might have recently crammed LeetCode problems, while a seasoned developer might be more focused on architecture and design patterns, areas not typically covered in these tests. Thus, coding challenges often end up favoring those who have had the luxury to prepare specifically for them, rather than genuinely assessing overall coding proficiency.

Stress and Unrealistic Conditions

Let’s not forget the stress factor. Coding challenges are usually time-bound and conducted in environments far removed from a developer’s natural work setting. Picture this: you’re sitting in a sterile interview room or, more commonly now, in front of your screen at home, being watched via webcam. You’re racing against the clock, trying to solve a problem that might have little to no relevance to the actual job you’ll be doing. This high-pressure situation can cripple even the best of us, leading to performance that doesn’t reflect true capability.

Often, it simply does not – in any way – indicate on the job capability or performance. Not in a single way. In real-world scenarios, developers have the luxury to think, research, and collaborate. We use tools and frameworks that aren’t at our disposal during these tests. The forced isolation and lack of resources during coding challenges create an unrealistic and often hostile environment that doesn’t mimic the collaborative nature of actual software development.

Neglect of Soft Skills and Team Fit

Another critical issue is the focus on algorithmic prowess at the expense of other vital skills. The best developers aren’t just those who can write the most efficient code—they are effective communicators, problem solvers, and team players. They understand requirements, can negotiate technical debts, and have the foresight to design systems that are scalable and maintainable.

Coding challenges rarely, if ever, measure these attributes. A candidate might ace a complex algorithm but fail to work effectively within a team or communicate ideas clearly. By overemphasizing coding challenges, companies risk hiring individuals who are technically sound but lack the essential soft skills that contribute to a harmonious and productive work environment.

Exacerbation of Imposter Syndrome

Lastly, let’s talk about the psychological toll. Coding challenges can exacerbate imposter syndrome, especially among underrepresented groups in tech. When candidates repeatedly face these high-stress evaluations and come up short, it can reinforce feelings of inadequacy and self-doubt. The tech industry already struggles with diversity and inclusion; coding challenges, in their current form, only serve to widen the gap.

The Disconnect Between Challenges and Real-World Skills

One of the most glaring issues with coding challenges is the disconnect between what is tested and what is actually required on the job. Many companies fall into the trap of asking overly simplistic or academically focused questions—like manipulating arrays or building fundamental data structures. These tasks, while foundational, are not reflective of the daily work most developers engage in once they leave college.

In the real world, software development is far more complex and nuanced. It involves integrating systems, debugging, optimizing performance, and understanding user requirements. It demands a keen eye for detail, the ability to foresee potential issues, and the creativity to solve unique problems. Coding challenges that focus on rudimentary tasks don’t capture these critical skills. Instead, they test whether candidates remember concepts that are often just stepping stones in their educational journey.

This misalignment can lead to hiring the wrong people. A candidate who excels at solving textbook problems might struggle with the intricacies of maintaining a large codebase or collaborating on a multi-faceted project. Conversely, a highly skilled developer might falter in these artificial scenarios but thrive in real-world environments. By prioritizing these narrow assessments, companies risk missing out on talent that would be truly valuable to their teams.

Data Proving the Ineffectiveness

Empirical data and studies have shown that traditional coding challenges do not necessarily improve employee longevity or overall outcomes for the employee or the organization. According to HackerRank’s reports, while coding challenges are a popular tool for assessing technical skills, they often do not correlate with job performance or employee retention rates. Similarly, Deloitte’s extensive research into people analytics highlights that high-performing organizations focus on a more holistic approach to hiring, which includes evaluating soft skills and cultural fit, rather than relying solely on coding challenges.

Towards a More Holistic Approach

So, what can we do about it? It’s well past due that the industry has a big rethink on the approach to technical interviews. A focus on holistic evaluation that considers the complete picture of a candidate’s abilities. Pair programming sessions, take-home assignments, and situational judgment tests can provide deeper insights into how a candidate thinks and works, in spite of their inherent issues also. These methods are less stressful and more reflective of actual job scenarios.

We should also place greater emphasis on behavioral interviews to gauge cultural fit and soft skills. After all, a team’s success hinges not just on technical expertise but on how well its members collaborate and communicate.

The Concluding Summary

While coding challenges have their place, their current overemphasis during interviews can be toxic, and are often an indicator of exactly that within the culture itself. They shows signs that the developers’ aren’t setup to work in a wholistic way, and instead are mere cogs within the machine versus the higher functioning team members they should be setup as. They perpetuate a narrow view of what makes a great developer and can unfairly disadvantage many capable candidates, often dissuading the most experienced and capable – i.e. the A-tier – candidates altogether. By adopting more inclusive and comprehensive evaluation methods, stronger and more capable teams can be built to drive innovation and success.

It’s best to move beyond the binary success/failure paradigm of coding challenges and embrace a more nuanced, humane approach to hiring. After all, the goal is not just to find the best coder, but the best team member.

In the next post, I’m going to elaborate on the red flag indicators that the “coding challenge” culture is indicative of, and I’ll discuss the horrid results and side effects of this culture. I’ll also tell you why I like coding challenges, and how one can improve interviewing so you get better outcomes for all involved. So stay tuned and subscribe!

Data Lake vs. Data Warehouse: A Detailed Breakdown with AWS Offerings

When diving into the realms of data storage and management, two terms often come up: data lake and data warehouse. While they might sound similar, they serve distinct purposes and have unique characteristics. Let’s break it down, especially with a focus on what Amazon Web Services (AWS) has to offer.

What is a Data Lake?

A data lake is like a massive reservoir where you can dump data in its raw form. It’s designed to handle structured, semi-structured, and unstructured data. Think of it as a giant pool where data is stored as-is until needed for processing. These lakes are typically built on scalable storage systems such as Hadoop or cloud solutions, making them ideal for big data scenarios.

AWS Data Lake Offering: Amazon S3

Amazon Simple Storage Service (S3) is AWS’s go-to solution for data lakes. S3 provides virtually unlimited storage capacity, high durability, and availability. It’s designed to store any amount of data from any source, allowing you to dump raw data into the lake and then process and analyze it as needed. S3 integrates seamlessly with other AWS services like AWS Glue for ETL, Amazon Athena for querying, and Amazon SageMaker for machine learning, making it a robust ecosystem for managing big data.

What is a Data Warehouse?

On the flip side, a data warehouse is more like a neatly organized library. It’s optimized for storing large volumes of structured data, making it easier to retrieve and analyze. Data warehouses use schemas and ETL (Extract, Transform, Load) processes to structure data before storing it. This setup is perfect for business intelligence and reporting purposes.

AWS Data Warehouse Offering: Amazon Redshift

Amazon Redshift is AWS’s powerful data warehouse solution. It’s designed for fast querying and complex analytical operations on structured data. Redshift uses columnar storage technology and massively parallel processing (MPP) to deliver high performance for querying large datasets. With Redshift Spectrum, you can even extend your queries to data stored in S3, combining the best of both data lakes and data warehouses. Redshift’s integration with AWS services like Amazon QuickSight for visualization and AWS Glue for ETL further enhances its capabilities.

Key Differences

Let’s lay it all out in a chart to see the differences clearly:

Summary

In essence, data lakes are your go-to for handling large volumes of varied data types, offering the flexibility needed for in-depth analysis, data mining, and machine learning. They are the playgrounds for data scientists and engineers who thrive on processing raw data. AWS’s Amazon S3 stands out as a premier solution for creating and managing data lakes, offering seamless integration with various AWS tools for data processing and analysis.

Data warehouses, on the other hand, shine when it comes to structured data and optimized querying. They are the polished environments where business analysts and executives can quickly derive insights and make data-driven decisions. Amazon Redshift leads the charge in AWS’s data warehouse offerings, providing high-performance querying, integration with other AWS services, and scalability to meet enterprise needs.

Choosing the right solution hinges on your specific needs. If you require flexibility and scalability, go for a data lake with Amazon S3. If structured, high-performance querying is your priority, a data warehouse with Amazon Redshift is the way to go.

And there you have it, a comprehensive basic look at data lakes vs. data warehouses, with a spotlight on AWS’s offerings. Now, whether you’re diving into the raw depths of a data lake or navigating the organized corridors of a data warehouse, you’ll be equipped to make the best choice for your data needs. Keep shredding through the data jungle, and stay tuned for more insights!

Alright, so you’re gearing up for those junior software developer interviews, eh? It’s a wild ride, but with the right prep, you’ll crush it. Here’s the lowdown on what to expect and how to get ready.

1. The Initial Screening

Kicking things off, you’ll likely have an initial screening call. This one’s usually with a recruiter or HR rep. Think of it as a quick chat to make sure you’re not just a name on a resume. This call runs about 15-30 minutes.

What to expect:

• Your background and experience: Be ready to talk about your journey so far.
• Interest in the role: Why this job? Why this company? Have your answers ready.
• Basic technical knowledge: They’ll dip their toes into your technical pool to see if you can swim.

Some warnings to be wary of. Sometimes the recruiter will ask technical questions and they will not have a basis of why or what the question is about. They’ll often be super simple questions around some inane documentation or description of something, like “What is the method that starts a Spring Boot application in Java?” with a myopic answer like “The Spring Boot application is started with a main method.

Which of course is an overly simplistic answer and kind of a gotcha, and not always 100% true. But just answer these questions as simply, and with the most obvious answer you can think of. If you start talking about the attribute (@SpringBootApplication) on the class, that has the method main, that identifies and loads that functionality into the Spring Boot application then they’ll likely be confused and consider your answer wrong, even though you’ve just been more thorough of the true startup process of a Spring Boot application and its respective – fundamental – dependency injection capability.

2. The Technical Interview

Now they’ll start diving deeper. This part of the interview process is the real meat and potatoes but can also – generally speaking – be pretty easy if you’re appropriately prepared. The real key is, train and condition yourself to stay calm. I know, easier said than done, true, but it is truly the key to passing technical interviews.

I myself have been interviewing for decades at this point, and if I go into a technical interview stressed in any way, I’ll fail it. I can’t do coding problems if I’m stressed out ab out something, generally I need a solid 30-45 minutes just to get relaxed to really get into a good state of flow when coding and problem solving. Anything less and I too, after decades of this, am still a mess. My recommendation, do whatever you’ve got to do to figure out a way to step up to a technical challenge in a calm state of mind. You’ll whiz it if you can figure that out for yourself!

a. Coding Challenges:

• Real-time problem-solving on a shared platform.
• Questions will hit data structures and algorithms (think arrays, linked lists, sorting, and searching). This space is often the most common for junior devs, which is somewhat nice because you can pick up a text book on data structures or algorithms and just go through implementing them.
• Be prepared for language-specific queries, especially if the job demands C#, Java, or Python. Usually a team will want either the language they code in or they’ll ask what language your fluent in to write up the solution.
• Whatever coding challenge you are asked to write up, it’s important to keep in mind that just as important as the coding solution is your ability to describe verbally what you’re doing. This is one of the things that is really tough, and something that you should practice and become adept to.

b. Whiteboard Sessions:

• If you’re in-person, expect some whiteboard action. But don’t worry, it’s usually very hand wavy and open ended, the key is to make sure your ideas are verbally explained well and that you can write and talk through the solution your put on the white board at the same time. Again, the hardest part here is usually the talking and writing at the same time. You can do it though, get em’!
• It’s all about solving problems and explaining your thought process. Again, remember when you’re on a white board, you’re not going to compile the code, just aim for good pseudocode if you’re writing code and effective diagrams or listing of items to define and explain what you’re proposed solution is. Be prepared to have it picked apart and to change your mind too.

c. Take-Home Assignments:

NOTE: These days these are often red flags, in my next post I’ll detail why and how to identify free labor work farming and other nonsense that comes up with these types of assignments. Some are legitimate and the easiest that are identifiable are from companies that propose to pay you for the assignment.

• Some places might send you a take-home task.
• It’s a chance to show off your coding style in a relaxed setting.
• Follow instructions to the letter and test your code like crazy before sending it back.

d. System Design Questions:

• More common for senior roles, but you might see some basic ones. They’ll basically want to know, for example, how the web service or web site would be hosted in the grand scheme of an overall architecture. Such as, the web service would be in an AWS VPC and hosted via an EC2 instance, or just simply describe how you have built and hosted an existing example you’ve worked through in your learning.
• Be ready to chat about designing simple systems or components with scalability and maintainability in mind. Again, don’t get too worried about this, it could very well be as simple as “well if I’ve got one web server and need more throughput for internet traffic, I could run a bigger server.” The key is, just answer best you can and make it a collaborative conversation as much as possible.

3. The Behavioral Interview

Here’s where they see if you’re a good cultural fit. Soft skills and how you handle different work scenarios are under the microscope.

Common questions:

• Challenges in projects: Tell them about a tough project and how you nailed it.
• Learning new tech: Describe a time you picked up a new tool or language on the fly.
• Handling feedback: They want to know you can take critique and improve.

Pro tips:

• Use the STAR method (Situation, Task, Action, Result) to structure your answers. For Amazon this isn’t just a tip, it’s a requirement. You must answer in this format or you will fail the interview.
• Even if you’ve been so lucky as to never have had a bad experience working on a project, or with a team, make up some and imagine how you’d work through uncomfortable or difficult solutions. Have those ready to use as examples of how you’d at least propose or set forth on resolving difficult problems or conflicts.

4. Company-Specific Questions

Every company has its own vibe. They’ll have questions to see if you’ll fit into their world.

Examples:

• Why us? Show that you’ve done your homework on the company. For example, at Amazon you could talk about something you’ve heard that you find interesting and would like to work around, such as a document focused culture with doc reads and clearly defined meetings. For Microsoft talk about the team structure or open source involvement Microsoft has through Github, Azure, and their open source office. The TLDR – learn something about the company you’re interviewing with and be ready to talk about that being something attractive that made you want to interview.
• Products and services: Know what they do. This should go without needing to even state, but if you’re going to interview at a company, their entire public facing presence should be something you’re aware of as best as possible. In larger companies like Microsoft, figure out which part of the company the interview is for and learn about that specific part of the company, since it is impossible to know about all of the things Microsoft has going on.
• Staying current: How do you keep up with the ever-evolving tech landscape? This could be a list of resources you read, meetups you attend, videos (VLOGS, etc), or other means you use to keep up with whatever your career aims are.

5. Questions You Should Ask

Remember, it’s a two-way street. I can’t emphasize this enough, and will be writing far more details about how this is vital for interviews. Have questions ready to see if the company is right for you. But not just the company, but their strategy, the team, the individuals on the team. Be ready to ask plenty of questions and get some real insight into what they’re aiming for you to join and do, but also the things that will be necessary to do the job.

Good topics:

• Team structure and dynamics: What’s the team like?
• Growth opportunities: How can you level up in the role?
• Development practices: What tools and methods do they use?
• Role expectations: What’s expected of you in the first few months?

Final Tips for Success

Preparation:

• Practice coding problems: Regular practice keeps you sharp.
• Brush up on CS fundamentals: Know your basics inside out.
• Research the company: Understand their mission, products, and culture.

Communication:

• Explain your thought process: During coding challenges, talk through your logic.
• STAR method: Perfect for behavioral questions.

Stay Calm and Positive:

• Interviews can be nerve-wracking: Keep your cool and stay positive.
• Take your time: It’s okay to pause and think before you answer.

By knowing what’s ahead and preparing accordingly, you’ll walk into those interviews with confidence. Good luck, and go get that job!

Be sure to subscribe and I’ll be elaborating on this and all aspects of coder’s interviewing, life, and progress in one’s career as a coder! Happy thrashing code! 🤘🏻