DaveDevelopment::Dave Marshall

In part two of this series, I discussed the technical know how I think will help get you your next PHP job. This part will discuss writing your Curriculum Vitae(CV, resume, etc.). There are a lot of contrasting opinions on this subject, I’ll make a few points, give you some further reading and you can adapt the opinions in to a top notch CV of your own. I’m no major expert and most of the recruitment I have been involved in has been for trainee developers, but these positions attract a high number of CVs, so I’ve seen a fair few.

Your CV does not get you a job

Your CV gets you an interview, your performance in the interview gets you a job. Your CV is a right of passage, this stage is used to filter out the wrong candidates.

Your CV should evolve like you

You should be continually evolving and improving yourself, your CV should continually evolve with you. I can’t see any reason why any two companies should see the same version of your CV. Every time you apply for a position, you CV should be tailored to suit the position. Cut out anything you think will not interest your prospective employer, embellish on what will interest them. You come across as a better candidate and you don’t waste their time.

Don’t stuff your CV with keywords/acronyms

Skills: PHP4/5, SOAP, XML, XSLT, JSON, AJAX, (X)HTML, CSS, RoR, MySQL, SEO, WAI, WCAG, MVC, XML-RPC….

These kinds of lists are great for getting your CV past an agency recruiter, but the actual employers would rather see a reasonable description of how you used 5 of those technologies. I try to briefly describe what I did and why I used those methods/skills/technologies.

.. Overcame performance issues due to large volumes of data by including caching, AJAX and moving some business logic to database triggers and stored procedures. (LAMP)

Besides, if you’re good, they’ll hire you and expect you to quickly learn the skills, technologies and methods they use.

Formatting and Proof Reading

I like CVs short, they take less time to read. One page is good, any more than two is bad. Keep it simple, spell check it, grammar check it, get people smarter than you to proof read it. Speaking of which, here’s my current offering, although it still needs a lot of work. I intend to try switching to plain text, ala Stevey, plus I recently got promoted so I’ve more work history to add. Comments appreciated.

Further Reading

• Manager Tools – Resume podcast
• Manager Tools – Sample Resume
• Steve Yegge on CVs
• Joel Spolsky – Getting your resume read
• Joel Spolsky – Sorting Resumes
• BCS CV Clinic

More in this series

• Part 1: Technical Skills
• Part 2: Soft Skills
• Part 3: Curriculum Vitae

PHPPositions UK is a simple job board, listing genuine PHP jobs, for genuine companies. No agencies.

I needed a little project to help get to grips with the Zend Framework, so I created a little job board specifically targetted at PHP jobs in the UK. It’s not finished yet, but it’s good enough to put up on the web.

Check it out, if you’re in the UK and on the lookout for positions, subscribe to the feed. Eventually I’d like to monetise the site, but that depends on it generating a large enough audience, so until that point I’ll be adding jobs manually, thus keeping up a fairly high standard of jobs on there.

In part one of this series, I discussed the technical know how I think will help get you your next PHP job. This part points out some of the soft skills that are required for software development, discussing reasoning and how to go about acquiring those skills.

Writing

Like it or not, PHP developers are going to have to write documents of some kind as part of their job. You need to produce clear and concise documentation, including but not limited to requirements specifications, design specifications, technical documentation, end user documentation and possibly evening marketing documents and copy depending on the size of your company. Three quarters of this post is about communicating in different forms, getting your ideas across on paper is the first step to being better than the average programmer. Joel Spolsky actually recommends programmers take a creative writing course.

Listening

The guys at Manager Tools had an episode on teaching people interpersonal skills a while back and they made the point that being a good speaker is great, as long as you’ve got something great to say. If you can’t listen to other people, you’ll never have anything good to say. That cast is worth checking out, the points made are easily applied to yourself rather than other people.

Another nice article, this one concentrates on the barriers we all face while trying to listen to people, read it and be concious of them. The first time you put them into practice might be an interview, which you can’t afford to mess up.

You’re going to have to listen to lots of people, people you report to, people who report to you and clients. The better you are at listening, the better you’ll be at your job.

Speaking

When it comes to speaking, I find the most important rule is to know what you want to say. Sometimes we’re forced into situations where we have to act and speak on instinct, but these situations are the minority. Most of our speaking comes in the form of meetings and presentations, both of which are usually arranged in advanced. If they are arranged in advance, you should have time to plan what you want to say in advance and also what you want to get out of it. Even if things don’t go quite according to plan, the fact that you had a plan should have at the very least raised your confidence. Confidence can be quite a key factor when speaking, many things affect our confidence. For example, in my eyes an easy win is to look smart. If you look smart, or at least feel like you look smart, your confidence will be higher and the way you communicate will be better.

Time Management

Productivity is key, whatever you do. I’m a big fan of Getting Things Done and I use Remember the Milk to manage my tasks. LifeHacker has a nice article on GTD with RTM.

While not strictly a soft skill, without being able to give reasonable estimates for development work, you wont be able to manage your time effectively. Software estimation is exceptionally difficult, this book comes highly recommended, but if you want some lighter reading, I recommend Joel Spolskys Painless Software Schedules. That post actual says it is obsolete, but I don’t think it’s true, the Evidence Based Scheduling article takes things to another level, but the base techniques are still the same.

Influence

I’m part way through this book and I’m yet to put it to much use, but it’s a bloody good read. Being able to influence people comes in handy in all walks of life, selling software, recommending the latest technology to your boss or peers or convincing your boss you really need to go to ZendCon.

That’s it for now, I’ll be back with part 3 soon, which will be on writing your CV/Resume.

More in this series

• Part 1: Technical Skills
• Part 2: Soft Skills
• Part 3: Curriculum Vitae

After reading this thread, I thought I’d spend some time writing about what I feel are some measures you can take to landing a job in PHP. This first part is going to concentrate on the kind of technical matters I think any PHP developer should at least have knowledge of, if not some kind of experience. A lot of the subjects discussed aren’t specific to PHP, but the focus will be on PHP. It’ll be far from exhaustive (please feel free to flame, but constructive comments would be nicer) and there’ll probably be quite a few references to Joel on Software articles, mainly because I’ve read a lot of them and I can’t be bothered to research the topics further! There’ll be plenty of links to follow, plus the odd dead tree format recommendation.

Programming

This should be a no brainer. Lots of experience of programming in PHP, is not strictly necessary, a good programmer, particularly with experience of scripting languages or programming for the web should be able to pick up PHP in no time.

For someone who is basically a good software developer, learning another programming language is just not going to be a big deal. In two weeks they’ll be pretty productive. In two years, you may need them to do something completely different in a programming language which hasn’t even been invented.

- Sorting Resumes by Joel Spolsky

Most PHP applications are used in conjunction with an SQL database, predominantly MySQL, so you’re going to need some of this under your belt.

Some knowledge of PHP is essential. Be aware of the benefits, the caveats and if you’re interested, a little of PHPs history, some people really care about it. I think it definitely shows you are passionate about what you do or want to do. Maybe look to PHP’s future, research whats coming up in PHP 5.3, or whatever the next version is at the current time.

Software Engineering

Most PHP roles go beyond just programming, so a good sense of what’s involved in a full project life cycle should help you get that PHP job over the next guy. There are lots of processes and models available, but you don’t need to be familiar with them all. Get a good idea of the 7 stages of the traditional Waterfall Model and you should be able to apply the principles to most methods. They are:

1. Requirements Specification
2. Design
3. Implementation
4. Integration
5. Testing
6. Installation
7. Maintenance

I like UML for design and documentation, so worth knowing about even if you haven’t practiced it.

Libraries and Frameworks

If you are familiar with Object Oriented methodologies, arm yourself with the knowledge of PHP5’s OO capabilities. Once you’ve got that, get a handle of the vast array of PHP frameworks that are available. You don’t have to know them inside and out, just be aware of them and the benefits they give you. PEAR is a huge library of PHP code, check it out

Development Tools

There are plenty of tools available to aid and improve the development process, be familiar with as many as you can handle. I would insist on becoming familiar with, downloading and experimenting with subversion, or some other version control system.

Joel Spolsky has what he refers to The Joel Test. Later in this series, we’ll discuss interviews, and I will recommend asking at least one of these questions at an interview, so you need to understand what they all mean and why they might benefit a software development team.

Security

Security is often a big cause for concern in the PHP world, mainly because it’s not been handled correctly before. PHP is not insecure in itself, most vulnerabilities attributed to PHP are actually simply in softwares written in PHP.

Be aware of security issues in your code such as SQL Injection, XSS and CSRF. Also be aware of configuration directives that can affect the security of your PHP powered web servers.

Web Services

Understand what a web service is and some of the related technologies. PHP is ideal as a glue language, combining web services to consume single web services or create mash ups of several web services, but can also be used for providing web services.

System Administration

In my opinion, developers should be capable of administering the full stack they develop for, usually in this case, the LAMP stack. There can’t be many potential PHP developers out there who don’t have a spare computer or hard disk lying around that they can’t install Debian on and follow a simple LAMP installation tutorial. If you’ve not got a spare hard disk, download VmWare Player and a debian appliance

I think thats all I can think of for now, I’m sure there’s plenty I’ve missed. If there’s any technical leads, managers or recruiters reading, please pipe up with what you expect from your applicants. The next part in the series will focus on the soft skills required for banking that PHP job.

More in this series

• Part 1: Technical Skills
• Part 2: Soft Skills
• Part 3: Curriculum Vitae

I got promoted to my current position, Lead Developer, about eight months ago and I’ve recently been reflecting on what I think I’ve achieved and what I need to improve on, you can consider these posts thinking out loud. The role was newly created when I was appointed, we previously only had developer roles reporting straight to managers.

First, a little background on what we are and do. We are a small IT Department, working as a support team for a multi-disciplinary engineering contractor, including development of bespoke systems, mainly web applications. We’re currently trying to move all these sub-applications into one big application. We currently employ three developers and two trainee developers. The developers work full time on the main application, while the trainees work through training material and small projects to gain experience.

Trainee Developers

When I first got promoted to the position, the main change to my daily work was being mentor to the trainees. When I started as Lead Developer, we didn’t actually have any trainees, but were about to recruit. I was involved in the recruitment process, which was a good experience for me. I had actually asked my manager if I could sit in on a couple of interviews for experience before I got promoted, so I was interested in the aspects of hiring anyway. I did a little background reading on interview techniques [Recommended: 1, 2, 3, 4, 5], particularly regarding programmers and stuck to the technical side of things, allowing my managers to use their experience to judge the ‘people skills’. Things went pretty well, but I’m concerned I probably wont ever do it enough to get good at it. Having said that, I’d rather keep the staff we’ve got than get really good at recruiting.

I inherited a training programme and modified it only slightly, except for the module on working as a team, which I rewrote. The trainees work through the programme completing exercises and taking on mini projects along the way. It seems to work pretty well, but I haven’t given the actual programme any attention recently and should get it updated, to try and introduce some more modern development techniques.

The biggest problem I have, is not doing things for the trainees. Whenever they have a problem and ask for help, the temptation is to big up the keyboard and crank out the code they need. This would have benefits, the trainee gets decent code doing what they need and I can get on with my other responsibilities. The downside is, unless the trainee goes back and studies my code, they’ll never learn. Instead I need to take my time and coax the answers from the trainee and let them solve their own problems, albeit with a little provoking

Recently I experimented with our newest trainee, who came to us with little actual programming experience. For his first project, I gave him the choice of implementing it the slightly harder way, which would take him longer but hopefully he would learn more, or the quick and easy way, leaving the harder stuff until later on. Thankfully he chose the hard way and I set him off on his way to use the Zend Framework. I like the idea of this, I know a lot people find it difficult moving from procedural techniques to object oriented methods, so why bother learning the procedural techniques first? I gave him a pointer by showing him Akra’s superb tutorial and he went from there. On demoing the project to my manager, the trainee was asked “if the system was object oriented?” He replied “No”. He didn’t actually know he’d implemented the whole system, barring the view scripts and the boot loaders in object oriented PHP. At first I thought this was bad, thinking he hadn’t realised what he was doing the whole time, but maybe it’s just that he thought that was just the way things were done. I think this was a success and would be interested to hear how other companies introduce their trainees to frameworks and object oriented principles.

Part 2 – Software tools and methods