The PHP Rountable podcast, hosted by PHP community member Sammy K Powers, has posted their latest episode - Episode #77: Tech Interviews for Self-Taught PHP Programmers. In this episode Sammy is joined by Frank de Jonge, Parker Phinney and Gayle Laakmann McDowell.

Self-taught PHP programmers, even those of us with decades of experience, would likely fail a tech interview in an epic way. If you've ever wanted to work for a big tech company like Google, Amazon or Facebook but have always been too nervous about the tech interview, this episode is for you.

We chat about what we need to do to be fully prepared for a tech interview. And maybe soon you'll be showing your friends how to reverse a binary tree on a whiteboard.

You can catch this latest episode either using the in-page video player or you can watch it directly over on YouTube. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

On the Checkpoint Research blog there's a recent post covering the recent critical Drupal bug, a.k.a. Drupalgeddon 2, and providing a deeper look into the bug and how the exploit worked.

Two weeks ago, a highly critical (21/25 NIST rank) vulnerability, nicknamed Drupalgeddon 2 (SA-CORE-2018-002 / CVE-2018-7600), was disclosed by the Drupal security team. This vulnerability allowed an unauthenticated attacker to perform remote code execution on default or common Drupal installations.

[...] Until now details of the vulnerability were not available to the public, however, Check Point Research can now expand upon this vulnerability and reveal exactly how it works.

The post covers the basic issue, a lack of input sanitization on Form API requests, and what versions it existed in. It then dives into the technical details, showing a proof of concept for the exploit and how an attacker might locate a place in the application to use it. It also looks behind the scenes at the code that handles the request and shows where the issue lies. The post ends with a look at "weaponizing" the exploit and executing whatever code you'd like on the server.

The Intracto.com blog has a post sharing some ideas and methods about how to rescue legacy code through refactoring. In it author Door Jeroen Moons shares from his own experience working with legacy applications and offers practical advice you can apply in your own legacy codebase to "tame the beast".

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He starts by defining technical debt and the idea of "code cancer", those shortcuts and hacks that are taken during development and slowly corrupt the quality of the code. He then covers one of the harder parts of refactoring - persuading the customer that it's an effective use of time. He also mentions replacing current code with quality code, making problems visible, working on the hard parts and code ownership. The post finishes up with mentions of testing for quality and functional assurance, creating reusable libraries and isolating and replacing things a piece at a time.

Matthew Turland has an interesting new post to his site sharing some of his own thoughts on how you can stay employable as a developer with some great suggestions both on the technical and personal side.

Following my post on changing jobs, I communicated with a friend who’s in the market for a job. His circumstances inspired me to write a post for a slightly difference audience. So, here’s some advice on remaining employable as a developer.

His suggestions touch on topics like:

• length of employment at one company (sometimes based on the type of company)
• the balance between being a generalist and fitting only into a niche role
• constant learning (and spending time "off the clock" doing professional development)
• networking with other people

There's a lot of good content in the post so be sure to give it a read, especially if you're a developer that's been in the same role for a while...

With another round of "conference season" and Call for Papers starting up, there's some timely advice from Lorna Mitchell with some suggestions about submitting a talk to the conference of your choice.

I've been a conference speaker for a lot of years now, which doesn't make me an expert but it does mean that people ask me for advice pretty regularly! With the Call for Papers open for PHP North West at the moment (awesome conference, first weekend in October, CfP at http://conference.phpnw.org.uk/phpnw15/call-papers/), I've taken this question a few times. Here's my advice in a nutshell.

She shares five tips that she feels can help you make for a better abstract and submission including writing it down before submitting and asking for peer reviews before hitting that submit button. She also links to a few other helpful resources that can provide even more tips to help you even once you've been selected.

The SitePoint Web blog has a recent post from Matthew Setter offering some helpful hints on working with other people's code. In it he shares suggestions ranging from the technical out to a bit more "learning oriented" to get up to speed on concepts and techniques.

Dealing with code created by other people is a fundamental skill for a developer. Give it a year and other people’s code could even be your own. Today I’m going to look at some of the best approaches for how to deal with other people’s code, read legacy code, effectively. It’s not an easy topic to cover.

He's broken it down into a list of several different topics, each with their own descriptions and links to tools or reading resources for more information:

• Interact
• Observe
• Run Tests
• Fix Bugs designed for Newcomers
• Find Available Resources
• Use a Good IDE
• Read Books & Blogs
• Contribute to Documentation
• Be Considerate

He puts some good emphasis on that final point, reminding the reader that it's not just years of experience that make for a better developer, it's more about skill.

If you're considering getting into the world of speaking at an upcoming PHP conference, Matt Frost has some advice for you to help you get started. It can be intimidating, so learn from some of his own experiences as a relatively new speaker in the community.

It's a very busy conference season in and around the PHP Community. [...] These conferences are such a blessing to those who are able to attend, the speakers know their stuff and are very open to sharing and talking outside of their sessions. But you're a smart cookie too! You've got ideas and thoughts and knowledge that other people would like to have, so how do you get in on this? I'm going to tell you how I got into it, your mileage may vary, but hopefully it helps.

He points out that submitting a talk and getting accepted is "a lot like the lotto" sometimes, that you can't win unless you buy a ticket (submit that talk). He looks at a few of the other common questions from beginning speakers - what do I talk about, how do I write an abstract and common first time speaking concerns.

There's no magical elixir that will land you speaking gigs at cool conferences. Everyone that speaks, from the seasoned pro to the up and comer, has worked extremely hard to not only put the talks together; but acquire all the knowledge necessary to give the talk in the first place

On 7PHP.com today they've posted the latest in their series of community interviews, this time with Maarten Balliauw, a technical evangelist with JetBrains, maker of the popular PHP IDE PHPStorm.

In this edition I talk with Maarten Balliauw who is the technical evangelist at Jetbrains (the php ide PHPStorm is one its product you can recall). @maartenballiauw is of those few programmers who is indulged closely with both PHP and .NET worlds - meaning this interview will also have questions on both worlds. I now invite you to learn from his experience and get to know his personality.

They talk some about Maarten's background in PHP, some of the "good" and "bad" he sees in the language and some of the tools he uses daily to get his development done. There's also some suggestions of resources, tools and frameworks he finds useful. There's also a big chunk of the interview dedicated to his current work with JetBrains and some of his previous work with Microsoft and related technologies.

On SitePoint.com's PHP blog today there's a recent post looking at technical debt - what it is, how to locate it and how to help mitigate (and prevent) it in the future.

On the one hand, technical debt refers to the quick and dirty shortcuts we take and the effect they have on future development. On the other hand, technical debt is also about the things that we don’t do, such as not commenting our code, not developing documentation, not doing proper testing, etc.

They're looking at things from more of a financial standpoint than a development view, but some things are similar between them. Having some technical debt is almost unavoidable, but having a lot is a bad thing. They discuss how it relates to the quality of the product/codebase and three strategies for dealing with debt:

• Don't ignore it
• Triage it correctly and realistically
• Impose a debt ceiling and schedule regular time to work on it

Giorgio Sironi has a new post to DZone.com today about some of his experiences with Behat, a behavior-driven development testing tool written in PHP. It uses the Gherkin language syntax to define its tests.

I had the occasion to try out and adopt Behat for a particular need in our projects at Onebip. Here is my recount of the experience from a PHPUnit contributor and invested person.

He starts off with a list of situations where he doesn't think that Behat is a good fit for testing including testing of a single object and acceptance tests where comparing the response from more than one test is needed. He suggests that it's more useful for verifying high level business rules than anything. He talks some about the shift they made to using Behat and some of the benefits they found in its use. He finishes up the post by looking at the technical side and includes a warning about letting the size of the FeatureContext file get too large.