Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 14 2021
Jul 14

We are excited to announce the creation of Palantir.net's Fellowship program, a wonderful opportunity for us to provide qualifying candidates with the chance to attend DrupalEasy's Drupal Career Online (DCO). The first two fellowships will be awarded for the Fall 2021 session, and the second two will be awarded for the Spring 2022 session.

Fellowships At A Glance

  • Award: Full scholarship to cover the cost of Drupal Career Online and need-based support stipends. Paid internship/junior developer position with Palantir.net, dependent upon level of expertise and capabilities upon graduation
  • Eligibility: Available to candidates with diminished industry representation and/or who have been discriminated against and marginalized
  • Requirements: All candidates must meet the background requirements, apply to, and be accepted to Drupal Career Online. Recipients must commit to a paid internship and/or junior staff position with Palantir.net
  • Additional Perks: To celebrate your graduation, you'll receive additional stipends, professional mentoring, and an opportunity to work here with us

Think this is the perfect fit for you? Check out the application process!

You can also read more about the fellowship program and how DCO provides its participants with a clear pathway towards a successful Drupal career.

Our fellowships were created to provide the foundational tools and vital resources necessary for each of our recipients to become successful professionals who will bring valuable and unique perspectives to the Drupal community. 

As a company that believes in fostering, cultivating, and preserving diversity, equity, and inclusion makes us - and the world - a better place, this fellowship program is one part of our ongoing efforts to proactively identify and remove systemic barriers to equality. 

Here at Palantir.net, we're more than just a group of web professionals - we're curious, independent thinkers with exceptional passion, initiative, and talent. And if you're still curious about us, we invite you to learn more about our CultureTeam, and Work.

Or, better yet, reach out to me (Rachel Waddick) directly at [email protected]. As an extroverted communications person, I can guarantee that I'd love to hear from you! 

Jun 10 2021
Jun 10

As a company that believes that the best outcomes are achieved when people are able to create and collaborate in open, diverse, and inclusive environments, we’ve spent the last few years strengthening Palantir’s commitment to being an equitable and just organization. We have evolved our compensation, performance, and reporting structures in an attempt to proactively identify and remove systemic barriers to equality, becoming less hierarchical and more agile. To date, these efforts have included:

  • Establishing an equitable compensation structure with defined salary levels that provide equal pay for equal responsibilities.
  • Instead of reporting to a manager, each person now has a P.O.D. (Professional and Organizational Development) team that provides facilitation and coaching in performance, growth, and development.
  • Creating a career grid that’s supported with a role-based structure that demonstrates what opportunities exist for advancement and articulates the skills and expectations for each level so that individuals and P.O.D.s are orienting learning and growth conversations around a standard for promotions and opportunities.

We know, based on our experience with the Drupal open source community, that diverse teams drive innovation and improve quality. As Drupal’s Values and Principles state, “the people who work on the Drupal project should reflect the diversity of people who use and work with the software.” We agree. And while Palantir is already one of the more diverse and representative teams in our industry, we are not yet where we want to be. We are committed to doing the work necessary to build a team that incorporates diverse experiences and strengths where everyone can bring their best selves to their work and make space for others to do so as well.  

Ironically, the tumultuous pandemic year brought tremendous stability to the Palantir team itself. Our internal commitment (which we nicknamed CODENAME Armadillo) ensured that there were no layoffs or salary reductions in 2020, which gave us individually and collectively the space to focus on what we needed to be healthy. We invested in our existing team’s ability to build the resolve and resilience we would need to reimagine and redesign what we wanted our next normal to be. 

Now as we re-emerge, we have begun adding to the Palantir team, allowing us to examine what has and hasn’t worked for us in our hiring process. Adding several positions in succession has given us the chance to experiment with this process as we seek to redesign a more effective, equitable and agile process. 

The Challenges: 

  • Workplace inequality often has its roots in hiring processes that prioritize privilege and connections over potential. Qualified candidates can be passed over if they don’t fit into patterns of what the company or those in a position to hire might have seen work previously.
    How might we create opportunities for truly interested candidates to demonstrate how they would be “culture adds”, rather than just looking for “culture fits”? 
  • In the past, Palantir’s hiring process was most successful if a candidate was already familiar with the company (and was even better if the candidate knew one of us well).  
    How might we create a scalable, equitable environment that allows everyone to experience the advantages of insider access to a Palantiri?
  • Palantir’s hiring process could be long, with three rounds of interviews (screener, team and CEO) all conducted by in-house team members with other primary responsibilities. That long duration created an unintentional slant toward those who already had jobs (as those who didn’t often took other positions while our process was still unfolding). 
    How might we accelerate the process, without compromising our ability to manage hiring in-house and involve the team?

Thinking about these questions, we have spent the last few months conducting a series of experiments designed to reduce bias in our hiring process. Here are some of the approaches we have found most successful in addressing the questions above in the initial gates of the process: the application and the initial screening conversation.

Anonymous Applications

Our efforts begin with the application stage. Our job postings include a salary range and are reviewed for gendered or biased language. When we receive resumes and cover letters, a team member who isn’t involved in the hiring decision anonymizes them, removing names, addresses, and education information that shouldn’t influence our hiring decisions. (There is software that will do this automatically for larger firms, but it doesn’t seem available to small firms and our HRIS system doesn’t yet offer this feature.)

Knowing that our process (and indeed our company!) works a little different and can ask a lot of our applications, we want to make sure that we’re making the process informative and valuable for them as well. To that end, we host a webinar that candidates can attend or submit questions for and watch afterward, if they cannot attend. During this webinar, they have the opportunity to learn more about Palantir and the position and may anonymously ask questions. Our hope is that this is a very safe and welcoming environment where they can begin to see what it might be like to work at Palantir.

A Conversation, not a Challenge

After the webinar, if a candidate chooses to continue pursuing the open position and Palantir chooses to invite them, they are invited to a video interview with our Employee Experience Manager and another team member. Prior to that interview, candidates are asked to share something that demonstrates a required skill for the position. 

For technical positions, they are provided with some sample code from a variety of languages and frameworks. The code samples we use are drawn from public code repositories and aren’t written by one of our team members. 

During the technical interview, the candidates are asked to choose one of the code samples and share any observations, experiences, or thoughts they may have about it. Unlike in a coding challenge, we don’t ask candidates to author code on a whiteboard, and there are no planted bugs or tricky logic to uncover in the samples we provide. The questions are scripted in advance and asked in the same order and same way for each candidate. 

The point of this exercise is to demonstrate the candidate's ability to abstract from the code level to talk about functionality, purpose, and risks. As consultants, we often need to talk about our work with both technical and non-technical audiences. 

For non-engineering candidates, we ask that they record a presentation on a topic about which they are knowledgeable and passionate, or that the candidate write, draw, or record a video about which Palantir value resonates for them. As we continue to hire people for additional roles, we will find ways for them to demonstrate their unique skills and point-of-view. 

During the first interview, the candidate can also ask questions and learn more about Palantir. If the candidate and Palantir both choose to move forward, the next interview is a team interview, followed by an interview with one of our CEOs prior to an offer being made. (Those interviews are largely unchanged from the previous hiring process.)

Preliminary Results

Our focus in this round of iteration has been on those candidate gating decision points where we are able to leverage antiracist, bias interruption research. As we engage in this process, we solicit feedback from the candidates about their experience and monitor the data at each stage (how many applications advance, are dropped or self-select out at each stage, etc.). Following each hiring cycle, we get together as a team to reflect on what we’ve learned and what experiments we might try in the next hiring cycle. 

So far, we have increased the number of applicants who were previously unknown to us (and vice versa). At each stage in the process, we have ended up with just about the expected number of candidates and overall candidate quality has been very high. The feedback we’ve received is that it is certainly an unusual process, but one that gives applicants (especially those unfamiliar with Palantir) a much better sense of us and our culture. 

Image "Scrabble - Resume" by Flazingo Photos licensed under CC BY-SA 2.0.

May 18 2021
May 18

Several of our clients manage multiple small sites for independent centers or groups within their organization. These sites often share an information architecture and key features like SSO integration and editorial workflows. They differ mainly in their content, and who manages the content for each site. They  are visually distinguished by logo and color, but share much of their page layout and components, meaning they can share a design system and theme as long as it provides a few options.

This group of sites can be run as Drupal "multisites", where multiple Drupal installations run on the same Drupal codebase and hosting infrastructure. A typical approach for setting up these sites would be either to install and configure each independently, using the same underlying code but re-creating the content types, taxonomies, and content management workflows for each -- or, to create one site and clone it. What this does is create multiple distinct Drupal sites that need to be updated independently when the content types or module configuration needs to evolve.

At this point you could consider building a Drupal "install profile", which lets you create identical new sites. However, the process for maintaining shared configuration after installation is to write update hooks, a tedious process compared to Drupal's config management.

Sharing base configuration

The approach we took instead was to share a base set of configuration -- the bulk of the Drupal config -- between all of the sites. This means that sites start from a complete set of features, including content type, taxonomy, and menu configuration as well as modules like SSO and workflow. A limited number of configuration items -- like the site name and 404 page, the logo and color theme settings, and others as needed -- are split out into site-specific config folders.

Not only do sites start from a complete shared set of features, but as features are added to the main configuration, each of the sites receive the new functionality at the same time.

Consider a case where you want to install a new module across all of the sites. For multisites set up with an install profile and independent configuration, you would need to enable and configure the module on each site independently. This would require careful attention to ensure the changes were applied on each of the sites, and verifying that you made exactly the same configuration decisions on each. When you discover that an option needs to be tweaked, you go back into each site and update it.

For multisites set up with shared config, you can install and configure the module once. The shared config will propagate the changes to each of the multisites. As you tune the module configuration, these changes too will go out to the multisites using straightforward config management processes -- no update hooks required.

Step by step

Here's how this works:

Set up

  1. Start by installing and configuring the first site
    1. Export the configuration to what will be the shared config directory
  2. Install Config Ignore, and configure it to at least ignore “system.site” (and probably “blocks.*”). Any other settings that vary across sites (ex: theme settings, colors, etc.) will also need to be added here.
    1. Configuration that is ignored will still be used when a new site is installed -- they act as "base config" -- but won't be imported again after installation
    2. If there's configuration that shouldn't be used as base configuration (often relevant for blocks), there are two options for making the Config Ignore workflow cleaner:
      1. Config Export Ignore will prevent certain configuration objects from being exported
      2. OR add a .gitignore in your config directory to exclude the files
  3. Install Config Split if there are modules that only need to be enabled on certain sites; when using Config Split, each site or group of sites will need their own split configuration directory.
  4. Now your config is ready for re-use.

Adding more sites

  1. Set up the scaffolding for a new multisite using the normal multisite set up process
  2. Make sure each multisite uses the shared config directory that you've created
    1. See Drupal's documentation on changing the storage location of the sync directory
  3. Install the new site from config when running install.php
    1. Using the web interface, select "install from config"
    2. OR using the command line, run drush si --uri=MULTISITE_URI --existing-config

Updating sites

  1. To make a change across all sites:
    1. Edit any site
    2. Export configuration -- this will update config in the shared config directory
    3. Check the changes into your repository
    4. Import config on the other sites
  2. To make a change that will only affect one site (this change will live in the destination/prod environment only)
    1. Make the change on the one site, locally
    2. Add the config to Config Ignore and export the configuration
      1. Both the Config Ignore settings and the changed config will be exported!
      2. Commit the changes to Config Ignore, but NOT the config file that you're ignoring
      3. You may want to add the specific files to the .gitignore so they don't accidentally get checked in and used as base configuration on new sites
      4. Note that the Config Ignore rule won't prevent the new configuration from being imported unless it is present BEFORE the new config is present
    3. Deploy the Config Ignore changes
    4. Make the desired change on the prod site
    5. If you're ignoring an entire class of config (like all block configuration), you only need to do this the first time you set up the Ignore
  3. To update core or modules across all sites
    1. Managing updates across multisites follows the standard process -- update the shared codebase and then run the update hooks on each site individually<
    2. Config that is changed by a module update only needs to be exported once

Making Multisites Easy

There's always a balancing act between the specific needs of one website among many, and the stability and maintainability of a single codebase and feature set. Creating a family of multisites is a great way to isolate editorial responsibilities, allowing divisions or centers independent control of their content and navigation; sharing the code AND configuration between these sites allows sustainable maintenance and iterative feature rollouts.

Airstream Ranch by Carlyle Ellis Photography/Human Quotient, licensed under CC BY-NC-ND 2.0.

Mar 10 2021
Mar 10

As we move into the vaccination phase of the COVID-19 pandemic, health systems are facing a new challenge: effectively communicating about vaccine availability, eligibility, and scheduling. For many systems their website is the primary - and sometimes only - channel of communication about vaccination.

This is a content strategy challenge: how should we structure the patient journey to prioritize quick answers to top patient concerns while enabling visitors to drill down to get more information at any point?

We just teamed up with Loyola Medicine to update their COVID-19 pages, and in this post we’ll walk you through the before and after.

Before

Screenshot of Loyola's COVID-19 information page from the start of the pandemic

At the start of the pandemic people had a flurry of questions: What is COVID-19, what are the risks, what are the symptoms, how can I protect myself, when should I seek medical help, how do I get tested, what does this mean for patients who need non-Covid medical care? 

Loyola’s original COVID-19 page shows a patient journey focused on demonstrating immediately that Loyola can answer all of those questions. The tabbed interface at the top of the page helps visitors quickly find and click on the tab that matches their need.

After

Screenshot of Loyola's COVID-19 information page with vaccine information

Right now, the question that is driving the majority of patient inquiries about COVID-19 is: how do I get the vaccine? This is a much more task-oriented goal than the early need for accurate information, which means that the patient journey can be radically reshaped to prioritize vaccine scheduling steps and streamline the rest of the content.

The new Loyola COVID-19 landing page leads with the primary call to action question: Are you an active Loyola patient or not? Visitors who are active Loyola patients are directed to MyChart to register, visitors who are not active Loyola patients are directed to registration through the city/county/state.

By making the first patient “doorway” a path to vaccine registration, Loyola is addressing the top priority of the majority of their visitors. However, some visitors are still looking for other COVID-19 information, and that content hasn’t gone away - it’s simply been deprioritized. A visitor scrolling down the page can still quickly and easily find clear, bold links to more detailed information about symptoms, prevention, Loyola’s safety precautions, vaccine safety, and how to care for someone who is ill.

How We Did It

Creating and publishing this new page took five business days as a routine part of the ongoing strategic services and managed support we provide to the Loyola team. There was no need to spin up a new project or team because we were leveraging their existing Drupal 8 platform and design system.

This page was built using a content type designed to enable Loyola Medicine to reorganize their page-level content strategy as priorities change. This template is a flexible landing page: it has a hero image, space for body copy, and then a big field that you can use to mix and match a wide range of visual components. 

With this template the Loyola Medicine team can build pages that look really different and deliver against different page-level content strategies without having to route new page development through Palantir or other support vendors. In this case, they brought us on to speed the new page along, but going forward they can adjust it themselves.

Extensible platforms like the ones we’ve built for Loyola Medicine, HonorHealth, and Baptist Health South Florida enable marketing teams to optimize their patient journey as the realities on the ground change.

Photo by Ivan Diaz on Unsplash

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web