Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 241-250.
Table of contents
- 241. What are partial indexes?
- 242. How to build a social network capable of handling 100,000 concurrent visitors and providing features like suggesting friends based on location, while ensuring fast performance? How should data be stored, and what principles should guide query construction?
- 243. What principle is violated in the code, and how can the code be improved?
- 244. You need to build an email link tracking server. What classes/layers/abstractions would you identify?
- 245. How would you implement a URL shortener, an image compressor/decompressor, a forum's latest posts parser mentioning a specific brand, and a price checker for products at competitors?
- 246. Design a parking lot using object-oriented principles
- 247. What is pub/sub messaging?
- 248. What is an Event-Driven Architecture?
- 249. What is SSO (Single Sign-On)?
- 250. What are DDL, DML, and DCL in SQL?
Unveil strategies for optimizing systems, delve into advanced architectures, and master SQL fundamentals in this comprehensive segment. Explore partial indexes and conceptualize a social network designed to handle heavy traffic while ensuring peak performance.
Identify code principle violations and propose improvements. Construct an email link tracking server, employ object-oriented principles to design a parking lot, and explore the realms of URL shorteners, image compression, forum post parsing, and product price checking.
Understand pub/sub messaging, Event-Driven Architecture, and Single Sign-On (SSO).
Develop a solid grasp of Data Definition Language (DDL), Data Manipulation Language (DML), and Data Control Language (DCL) concepts in SQL.
241. What are partial indexes?
Formal Explanation: A partial index is a type of database index that includes only a subset of the rows in a table, based on a specified condition. It allows you to create an index on a subset of data that meets certain criteria, which can improve query performance for specific queries without increasing the size of the index unnecessarily.
Simplified Explanation: Partial indexes are indexes that only cover a portion of the table's data based on a condition.
Detailed Explanation:
Example: Consider a database table named Orders with columns OrderID, CustomerID, and OrderDate. If you want to create a partial index for orders placed in the last year (OrderDate within the last 365 days), you can create the following index:
CREATE INDEX IX_RecentOrders ON Orders(OrderDate) WHERE OrderDate >= NOW() - INTERVAL 1 YEAR;
In this example, the index IX_RecentOrders only includes rows where the OrderDate is within the last year. This can optimize queries that involve recent orders, as the index covers only the relevant data.
Types of Partial Indexes:
Filtered Indexes: These indexes are created based on a filter condition. Only the rows that satisfy the condition are included in the index. Example: Creating an index for orders with a specific status.
Partial Indexes with Included Columns: Apart from the filtered rows, you can include additional columns in the index to cover more information. This is useful for queries that involve those included columns.
Code Example: Suppose you have a table named Products with columns ProductID, ProductName, and StockQuantity. To create a partial index for products with low stock (StockQuantity less than or equal to 10), you can use the following SQL query:
CREATE INDEX IX_LowStockProducts ON Products(ProductID) WHERE StockQuantity <= 10;
By creating this partial index, queries that involve low-stock products can benefit from the optimized index.
Please note that the provided code examples are in SQL syntax, and the actual implementation might vary based on the database management system you are using.
242. How to build a social network capable of handling 100,000 concurrent visitors and providing features like suggesting friends based on location, while ensuring fast performance? How should data be stored, and what principles should guide query construction?
The main components involved in this process would be:
Database: This holds all the user profiles and their information. A combination of SQL and NoSQL databases can be used here as per the need. SQL databases excel in complex querying and transaction reliability, while NoSQL databases are more suitable for storing large quantities of data or user-generated content.
Caching: Use caching mechanisms like Redis or Memcached to store frequently accessed data in memory. For example, store friend lists, recent posts, and suggestions in cache to reduce database load.
Sharding: Sharding involves distributing data across multiple databases or servers. You can shard by location, ensuring users from the same city are stored on the same shard. For instance, create separate databases for users from New York, San Francisco, etc.
Load balancing: Distribute network traffic across many servers to ensure no single server becomes overwhelmed. This can be achieved using tools like Nginx.
Search: Efficient search algorithms can be used to find people in the same city.
Microservices Architecture: To handle 100,000 concurrent users, a monolithic architecture might present limitations. Therefore, you could consider a microservices architecture, where each functionality of your application (like login, searching friends, news feed, etc.) is handled by an individual service. This way, even if one part of the website is dealing with heavy traffic, it wouldn't affect the overall performance as each service is independent.
CDN (Content Delivery Network): To speed up the delivery of static content, you can use CDN. CDN is a geographically distributed group of servers that provides fast delivery of internet content. This helps in improving website loading speed and overall user experience.
Queue System: For tasks that don’t need to be performed immediately, a queue system like RabbitMQ can be used. This can include tasks like sending an email, image processing etc. By deferring such tasks for later, you provide immediate feedback to the website visitor and improve the user experience.
API: Using API endpoints, you can fetch relevant data from database as per the requirements. RESTful APIs can be implemented for this.
In terms of data storage, a mixture of SQL and NoSQL databases could be effective. This is often termed as "Polyglot Persistence." For storing user profiles, relationships, and other structured data, Relational SQL databases like MySQL, PostgreSQL can be used. NoSQL databases like MongoDB, Cassandra are good at storing unstructured data like posts, user-generated content, logs etc.
When it comes to queries, efficiency is key in a high-load environment. Query optimization techniques such as indexing, query rewriting, denormalization should be employed. SQL provides the EXPLAIN command that outlines the execution plan of a SQL statement, which can help to spot bottlenecks.
This response is a surface level explanation of a very complex task, there are a lot more factors to consider when scaling your application to handle 100k concurrent users.
243. What principle is violated in the code, and how can the code be improved?
Code:
class Shape
{
public function __construct(public float $width, public float $height)
{
}
}
class Triangle
{
public function __construct(public float $radius){
}
}
class AreaCalculator
{
public function calculate(Shape $shapes): float
{
$area = [];
foreach ($shapes as $shape) {
if (is_a($shape, 'Square')) {
$area[] = $shape->width * $shape->height;
} else if (is_a($shape, 'Triangle')) {
$area[] = $shape->radius * $shape->radius * pi();
}
}
return array_sum($area);
}
}
Formal Explanation: The code violates the Open-Closed Principle (OCP) and Single Responsibility Principle (SRP). The AreaCalculator class is not closed for modification, as it requires modification when a new shape is introduced. Additionally, the AreaCalculator class has multiple responsibilities – it should not be responsible for both calculating areas and determining the type of shape.
Simplified Explanation: The code does not allow for easy extension to new shapes and violates the rule that says "software entities should be open for extension but closed for modification." Additionally, the AreaCalculator class has too many responsibilities.
Detailed Explanation:
Open-Closed Principle (OCP) Violation: The
AreaCalculatorclass should be open for extension to accommodate new shapes without modifying existing code. However, the code violates this principle by checking specific shape classes (SquareandTriangle) and calculating their areas based on their properties.Single Responsibility Principle (SRP) Violation: The
AreaCalculatorclass is responsible for both calculating areas and determining the type of shape. It should ideally focus on only one responsibility.
To improve the code and adhere to the principles, you can introduce a common interface or base class for all shapes and use polymorphism to calculate their areas. Additionally, you can separate the responsibilities of calculating areas and determining the shape type.
Code:
interface ShapeInterface {
public function calculateArea(): float;
}
class Square implements ShapeInterface {
public function __construct(public float $width, public float $height) {
}
public function calculateArea(): float {
return $this->width * $this->height;
}
}
class Triangle implements ShapeInterface {
public function __construct(public float $radius) {
}
public function calculateArea(): float {
return $this->radius * $this->radius * pi();
}
}
class AreaCalculator {
public function calculate(array $shapes): float {
$area = [];
foreach ($shapes as $shape) {
if ($shape instanceof ShapeInterface) {
$area[] = $shape->calculateArea();
}
}
return array_sum($area);
}
}
// Example usage
$square = new Square(4, 4);
$triangle = new Triangle(3);
$calculator = new AreaCalculator();
$totalArea = $calculator->calculate([$square, $triangle]);
By adhering to the Open-Closed Principle and Single Responsibility Principle, the code becomes more extensible and maintainable, with a clear separation of responsibilities.
244. You need to build an email link tracking server. What classes/layers/abstractions would you identify?
In order to build an email link tracking server, you would typically identify the following classes/layers/abstractions:
Web Server Layer: This is the front-facing layer that handles incoming HTTP requests from email recipients clicking on links. It routes requests to the appropriate handlers.
Request Handler: This component receives incoming requests, extracts the necessary information (e.g., the link clicked), and delegates the request to the appropriate part of the system.
Link Tracking Service: This service manages the tracking of link clicks. It records the click events, updates statistics, and possibly triggers notifications.
Database Layer: The link tracking service needs to store and retrieve data related to link clicks, such as which link was clicked, who clicked it, when, etc.
Notification Service: This service might be responsible for sending notifications to the appropriate parties (e.g., the email sender) when a link is clicked.
Analytics Layer: This component could process the collected data to generate analytics and reports about link clicks, user engagement, etc.
Authentication and Authorization: You might have classes or components responsible for ensuring that only authorized users can access certain parts of the system.
Logger/Logging Service: This could be used to log events and activities in the system for troubleshooting and monitoring.
Here's a simplified example of how these components might interact:
[Incoming HTTP Request]
↓
[Web Server Layer]
↓
[Request Handler]
↓
[Link Tracking Service] ↔ [Database Layer]
↓
[Notification Service]
↓
[Analytics Layer]
In this example, the request starts at the web server layer, then moves through the various components. The link tracking service interacts with the database to record the click event, and the notification service might notify relevant parties. The analytics layer processes data for generating reports.
Remember that this is a high-level overview, and the actual architecture and components might vary depending on the specific requirements and technologies used.
245. How would you implement a URL shortener, an image compressor/decompressor, a forum's latest posts parser mentioning a specific brand, and a price checker for products at competitors?
Here's how you could approach each task:
URL Shortener:
Create a database to store long URLs and their corresponding short codes.
Generate a short code (e.g., using base62 encoding) for each URL.
When a user requests a short URL, look up the long URL in the database using the short code and redirect them.
Example: User enters "https://www.example.com/very-long-url", system generates "bit.ly/abc123", and clicking it redirects to the original URL.
Image Compressor/Decompressor:
Use an image processing library (e.g., GD, Imagick) to compress images by reducing quality or dimensions.
Store compressed images and original dimensions in a directory or database.
Provide a mechanism to retrieve and display the decompressed image when needed.
Example: User uploads a large image, system compresses it and stores the compressed version, user later retrieves the original or compressed image based on requirements.
Forum Brand Mention Parser:
Use web scraping or API to fetch the latest forum posts.
Parse the content of each post to find mentions of the specific brand.
Highlight or store these posts for further analysis or display.
Example: System fetches forum posts, identifies posts mentioning "Brand X", and displays them separately.
Price Checker for Competitors:
Use web scraping or APIs to fetch product prices from competitors' sites.
Compare the prices with your own products and analyze the differences.
Provide a report or notification when significant price differences are found.
Example: System periodically checks prices of specific products on competitor sites, alerts you if your prices need adjustment.
Remember, these are high-level approaches, and each task could involve more detailed considerations such as handling errors, optimizing performance, ensuring data privacy, and complying with terms of use for scraping. Also, depending on the requirements, you might use different programming languages, libraries, and tools to implement these tasks effectively.
246. Design a parking lot using object-oriented principles
Here are a few methods that you should be able to run:
Tell us how many spots are remaining
Tell us how many total spots are in the parking lot
Tell us when the parking lot is full
Tell us when the parking lot is empty
Tell us when certain spots are full e.g. when all motorcycle spots are taken
Tell us how many spots vans are taking up
Assumptions:
The parking lot can hold motorcycles, cars and vans
The parking lot has motorcycle spots, car spots and large spots
A motorcycle can park in any spot
A car can park in a single compact spot, or a regular spot
A van can park, but it will take up 3 regular spots
class ParkingLot {
private $motorcycleSpots;
private $compactSpots;
private $regularSpots;
private $spots;
public function __construct($motorcycleSpots, $compactSpots, $regularSpots) {
$this->motorcycleSpots = $motorcycleSpots;
$this->compactSpots = $compactSpots;
$this->regularSpots = $regularSpots;
$this->spots = [
'motorcycle' => [],
'compact' => [],
'regular' => []
];
}
public function parkVehicle($vehicle) {
if ($vehicle instanceof Motorcycle) {
$this->parkMotorcycle($vehicle);
} elseif ($vehicle instanceof Car) {
$this->parkCar($vehicle);
} elseif ($vehicle instanceof Van) {
$this->parkVan($vehicle);
}
}
private function parkMotorcycle($motorcycle) {
if (count($this->spots['motorcycle']) < $this->motorcycleSpots) {
$this->spots['motorcycle'][] = $motorcycle;
}
}
private function parkCar($car) {
if (count($this->spots['compact']) < $this->compactSpots) {
$this->spots['compact'][] = $car;
} elseif (count($this->spots['regular']) < $this->regularSpots) {
$this->spots['regular'][] = $car;
}
}
private function parkVan($van) {
if (count($this->spots['regular']) + 3 <= $this->regularSpots) {
for ($i = 0; $i < 3; $i++) {
$this->spots['regular'][] = $van;
}
}
}
public function getRemainingSpots() {
$remainingSpots = [
'motorcycle' => $this->motorcycleSpots - count($this->spots['motorcycle']),
'compact' => $this->compactSpots - count($this->spots['compact']),
'regular' => $this->regularSpots - count($this->spots['regular'])
];
return $remainingSpots;
}
public function getTotalSpots() {
return [
'motorcycle' => $this->motorcycleSpots,
'compact' => $this->compactSpots,
'regular' => $this->regularSpots
];
}
public function isFull() {
return count($this->spots['motorcycle']) == $this->motorcycleSpots &&
count($this->spots['compact']) == $this->compactSpots &&
count($this->spots['regular']) == $this->regularSpots;
}
public function isEmpty() {
return count($this->spots['motorcycle']) == 0 &&
count($this->spots['compact']) == 0 &&
count($this->spots['regular']) == 0;
}
public function isMotorcycleFull() {
return count($this->spots['motorcycle']) == $this->motorcycleSpots;
}
public function getVanSpots() {
return count($this->spots['regular']) / 3;
}
}
class Vehicle {}
class Motorcycle extends Vehicle {}
class Car extends Vehicle {}
class Van extends Vehicle {}
// Usage example
$parkingLot = new ParkingLot(10, 5, 15);
$motorcycle = new Motorcycle();
$car = new Car();
$van = new Van();
$parkingLot->parkVehicle($motorcycle);
$parkingLot->parkVehicle($car);
$parkingLot->parkVehicle($van);
$remainingSpots = $parkingLot->getRemainingSpots();
$totalSpots = $parkingLot->getTotalSpots();
$isFull = $parkingLot->isFull();
$isEmpty = $parkingLot->isEmpty();
$isMotorcycleFull = $parkingLot->isMotorcycleFull();
$vanSpots = $parkingLot->getVanSpots();
echo "Remaining Spots: " . print_r($remainingSpots, true) . "\n";
echo "Total Spots: " . print_r($totalSpots, true) . "\n";
echo "Is Full: " . ($isFull ? 'Yes' : 'No') . "\n";
echo "Is Empty: " . ($isEmpty ? 'Yes' : 'No') . "\n";
echo "Is Motorcycle Full: " . ($isMotorcycleFull ? 'Yes' : 'No') . "\n";
echo "Van Spots: " . $vanSpots . "\n";
In this code, the ParkingLot class includes all the required methods:
parkVehicle(): Parks a vehicle in the appropriate spot based on its type.getRemainingSpots(): Returns the number of remaining spots for each type of vehicle.getTotalSpots(): Returns the total number of spots for each type of vehicle.isFull(): Checks if the parking lot is full.isEmpty(): Checks if the parking lot is empty.isMotorcycleFull(): Checks if all motorcycle spots are taken.getVanSpots(): Returns the number of spots occupied by vans (each van occupies three regular spots).
247. What is pub/sub messaging?
Formal Explanation: Publish/Subscribe (pub/sub) messaging is a messaging pattern in which senders (publishers) and receivers (subscribers) are decoupled. Publishers send messages to a central hub (broker), and subscribers express their interest in receiving specific types of messages from the broker. The broker then delivers the messages to the interested subscribers. This pattern is commonly used for asynchronous communication in distributed systems.
Simplified Explanation: Think of pub/sub messaging like a newspaper subscription. Publishers (like newspapers) produce content and send it to a central distributor (broker). Subscribers (like readers) sign up to receive specific categories of content they are interested in. Whenever new content is produced, the distributor delivers the relevant content to the subscribers.
Detailed Explanation: Let's consider a scenario where we have a pub/sub messaging system to notify users about new articles in different categories.
Publisher:
class ArticlePublisher {
private $broker;
public function __construct(MessageBroker $broker) {
$this->broker = $broker;
}
public function publishArticle($category, $title) {
$this->broker->publishMessage($category, $title);
}
}
class MessageBroker {
private $subscribers = [];
public function subscribe($category, $subscriber) {
$this->subscribers[$category][] = $subscriber;
}
public function publishMessage($category, $message) {
if (isset($this->subscribers[$category])) {
foreach ($this->subscribers[$category] as $subscriber) {
$subscriber->receiveMessage($message);
}
}
}
}
Subscribers:
class UserSubscriber {
private $name;
public function __construct($name) {
$this->name = $name;
}
public function receiveMessage($message) {
echo "{$this->name} received message: {$message}\n";
}
}
$broker = new MessageBroker();
$user1 = new UserSubscriber('User1');
$user2 = new UserSubscriber('User2');
$broker->subscribe('technology', $user1);
$broker->subscribe('sports', $user2);
$publisher = new ArticlePublisher($broker);
$publisher->publishArticle('technology', 'New Tech Gadgets Released!');
$publisher->publishArticle('sports', 'Exciting Soccer Match Highlights!');
In this example, the ArticlePublisher publishes articles to the MessageBroker. Subscribers like UserSubscriber subscribe to specific categories and receive relevant articles when published.
The pub/sub messaging pattern provides a flexible and scalable way to distribute messages to multiple subscribers without them directly interacting with each other or the publisher.
248. What is an Event-Driven Architecture?
Formal Explanation: An Event-Driven Architecture (EDA) is a software design pattern in which components of a system communicate by producing and consuming events. Events are notifications or signals that represent significant occurrences or changes in the system. In an EDA, components are designed to be loosely coupled, allowing them to react to events without having direct knowledge of each other. This pattern promotes scalability, modularity, and responsiveness in systems.
Simplified Explanation: Imagine a party where guests interact based on different activities. When someone arrives (an event), others may greet them, offer drinks, or engage in conversation. Each guest reacts to events without knowing everything about others' actions.
Detailed Explanation: Let's consider an example of a basic event-driven architecture in PHP, where a notification system sends messages to subscribers when new events occur.
Event Dispatcher:
class EventDispatcher {
private $subscribers = [];
public function subscribe($event, $subscriber) {
$this->subscribers[$event][] = $subscriber;
}
public function dispatch($event, $data = null) {
if (isset($this->subscribers[$event])) {
foreach ($this->subscribers[$event] as $subscriber) {
$subscriber->handleEvent($data);
}
}
}
}
Subscribers:
class EmailNotificationSubscriber {
public function handleEvent($data) {
echo "Sending email notification: {$data}\n";
}
}
class SMSNotificationSubscriber {
public function handleEvent($data) {
echo "Sending SMS notification: {$data}\n";
}
}
$eventDispatcher = new EventDispatcher();
$emailSubscriber = new EmailNotificationSubscriber();
$smsSubscriber = new SMSNotificationSubscriber();
$eventDispatcher->subscribe('user.registered', $emailSubscriber);
$eventDispatcher->subscribe('user.registered', $smsSubscriber);
$eventDispatcher->dispatch('user.registered', 'New user registered: John Doe');
In this example, the EventDispatcher manages events and their subscribers. Subscribers like EmailNotificationSubscriber and SMSNotificationSubscriber are notified when the dispatch method is called. This decoupling allows for easy addition of new subscribers and promotes modularity.
An Event-Driven Architecture enables components to interact asynchronously, making systems more flexible, extensible, and responsive to changing conditions or user actions.
249. What is SSO (Single Sign-On)?
Formal Explanation: Single Sign-On (SSO) is an authentication process that allows users to access multiple, usually related, software systems or applications with a single set of login credentials. With SSO, users authenticate once and gain access to various services without needing to log in separately to each system. SSO enhances user experience and simplifies management of user credentials.
Simplified Explanation: SSO is like having a master key that unlocks multiple doors. Instead of using different keys for each door (system), you use one key (credentials) to access all of them.
Detailed Explanation:
Let's consider an example of implementing a basic SSO mechanism using PHP.
Central Authentication Server:
class CentralAuthenticationServer {
private $userDatabase = [];
public function registerUser($username, $password) {
$this->userDatabase[$username] = $password;
}
public function authenticateUser($username, $password) {
if (isset($this->userDatabase[$username]) && $this->userDatabase[$username] === $password) {
return true;
}
return false;
}
}
Application Servers:
class ApplicationServer {
private $ssoToken = null;
public function __construct($ssoToken) {
$this->ssoToken = $ssoToken;
}
public function accessResource($username) {
if ($this->ssoToken !== null) {
echo "Accessing resource for user: {$username}\n";
} else {
echo "Unauthorized access\n";
}
}
}
Usage:
$authServer = new CentralAuthenticationServer();
$authServer->registerUser('user1', 'password123');
$user = 'user1';
$password = 'password123';
if ($authServer->authenticateUser($user, $password)) {
$ssoToken = md5($user . time());
$appServer1 = new ApplicationServer($ssoToken);
$appServer2 = new ApplicationServer($ssoToken);
$appServer1->accessResource($user); // Access granted
$appServer2->accessResource($user); // Access granted
} else {
echo "Authentication failed\n";
}
In this example, the CentralAuthenticationServer manages user registration and authentication. Once authenticated, an SSO token is generated and used to access different ApplicationServer instances without the need to re-authenticate. This simulates the SSO experience.
In a real-world scenario, SSO would involve more complex protocols like OAuth or SAML, but this simplified example demonstrates the basic concept of Single Sign-On.
250. What are DDL, DML, and DCL in SQL?
Formal Explanation: DDL (Data Definition Language), DML (Data Manipulation Language), and DCL (Data Control Language) are three categories of SQL statements used to manage databases.
DDL (Data Definition Language): DDL statements are used to define, modify, and manage the structure of the database objects like tables, indexes, and views. Examples of DDL statements include CREATE, ALTER, and DROP.
DML (Data Manipulation Language): DML statements are used to manipulate data stored in the database. They allow you to insert, update, and delete data. Examples of DML statements include INSERT, UPDATE, DELETE, and SELECT.
DCL (Data Control Language): DCL statements are used to control access to the data within the database. They grant and revoke permissions to users and roles. Examples of DCL statements include GRANT and REVOKE.
Simplified Explanation:
DDL: Creating and modifying the structure of database objects.
DML: Adding, updating, or deleting data in the database.
DCL: Granting or revoking access permissions.
Detailed Explanation:
DDL Example:
-- Create a new table
CREATE TABLE Customers (
CustomerID INT PRIMARY KEY,
FirstName VARCHAR(50),
LastName VARCHAR(50)
);
-- Modify an existing table
ALTER TABLE Customers
ADD Email VARCHAR(100);
-- Delete a table
DROP TABLE Customers;
DML Example:
-- Insert data
INSERT INTO Customers (CustomerID, FirstName, LastName)
VALUES (1, 'John', 'Doe');
-- Update data
UPDATE Customers
SET LastName = 'Smith'
WHERE CustomerID = 1;
-- Delete data
DELETE FROM Customers
WHERE CustomerID = 1;
-- Query data
SELECT * FROM Customers;
DCL Example:
-- Grant SELECT permission on Customers table to a user
GRANT SELECT ON Customers TO user123;
-- Revoke INSERT permission on Orders table from a role
REVOKE INSERT ON Orders FROM admin_role;
In this example, DDL statements are used to create, modify, and drop a table. DML statements are used to insert, update, delete, and query data. DCL statements are used to grant and revoke permissions on tables.
Previous articles of the series:
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 1-15.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 16-30.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 31-45.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 46-60.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 61-75.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 91-105.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 106-120.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 121-135.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 136-150.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 151-165.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 166-180.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 181-195.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 196-210.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 211-225.
Mastering the PHP Developer Interview: 100+ Technical Questions Answered. 226-240.