As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My company is looking for a new web developer and we are eager to find someone that would be efficient as soon as hired and capable of making quality code. I will have to take interview and I would like to give them an assignment, so I can see
their general programming skills
if they are able to use CSS
the general quality of what they product
and probably so much more
The only problem I don't have good ideas of what to give to them. Some of the candidate would probably be working in some other company so it should be something like 8 hours work at maximum (like one week end) but it should be complicate enough to show their skills.
So far I was thinking :
a contact manager
a CD/BOOK manager
a blog ?
guys if you have some ideas opinions, please share!
Also the assignment would be in PHP using the Zend Framework, so it has to take in the calculation candidates might not be so experienced with the framework.
I don't think you should give them such a long "test". In my opinion if you want to do something like this, make it a simple 5-20 minute application. Perhaps a small address book manager that stores name/number and maybe 1-2 other fields. But nothing too complicated. And tell them that it only needs simple styling to look "ok" but nothing fancy is required. If it were me, I really wouldn't want to do "homework" for an interview.
I'm an experienced software developer who would fit your description, and I'd walk away from the interview the moment I was asked to do any unpaid work that would take more than an hour. Only the desperate and/or inexperienced are going to bite on something like that, and neither of them are going to be able immediately contribute on your project.
Ask them to send a code sample
If they don't have a code sample they've cleared with previous employers, ask for a personal code sample
Google them and find the kind of stuff they've produced vs. what they've sent you
Ask for a technical reference, and ask the reference what kind of work they've produced
Hire them on a contract-to-perm/part-time contingency basis. If, after two weeks, they're not living up to your expectations, end the contract with no hard feelings either way.
I don't think many of these answers are from the employer side of the relationship. Writing a function on a whiteboard gives me a tiny glance at someone's potential, and essentially no real picture of efficiency. There's always a chance that they've memorized a really cool way to reverse a string in place and remove duplicates from a list and count the bits in a byte because those questions are all over the internet.
I've had interviews with people that turned out to be nothing but posers (I guess liars would be a better term for it), so I think it's incredibly important to have some kind of tangible piece of work. I'm not saying 8 hours, but it gives you a few better hints:
How is it packaged - a zip with a build? Or a text file pasted into an email.
Is there any documentation?
Is there a sensible algorithm or is it brute force?
Are there objects or is it a whole mess of static gunk in one class?
We're hiring Software Developers that need to be able to design as well as code -- the probation period should not be the first time a person writes more than a method for you - by the time an ass is in a seat, you've spent a lot of money just to find out they get lost trying to write a method with business value.
I'll admit that people can fake it on assignments (this is usually, but not always, pretty easy to flush out in a post-assignment interview), I've had far more success hiring people with good code assignments than hiring people with a great resume and great interview.
If the job isn't important enough for someone to spend a couple hours writing some code (which we ostensibly love to do anyway, right?), then I'm glad they wouldn't do it, because I wouldn't hire them.
It would probably be better to have them write some code on a white-board in person than a take home assignment. You can learn a lot more about the candidate that way, such as how efficiently he/she solves problems and thought process.
Giving them a take home assignment doesn't really give you a clue as to how efficient they are. You could have two candidates, both of whom turn in the exact same thing, yet one of them did it twice as fast. You would have no way of knowing.
I have to agree with the other answers: if an interviewer asked me to do a take home assignment that was too long, I wouldn't do it.
As others have written, asking people to do so much work for free is insulting.
Assuming you can find some victims, how confident are you that you would be able to objectively esatblish which one produced a better finished article?
Why are you so obsessed about the Zend framework? I would much rather employ someone with a solid understanding of programming, good problem solving and communication skills than someone who can only demonstrate competence with a very specific set of tools - presumably tools where you already have a strong skills base.
Indeed one of the things I look for in candidates is what new knowledge and interpretation they can bring and how it might complement the existing team. I would even value good knowledge of procedural, OO and non-procedural programming alongside knowledge of HTTP over specific skills in PHP.
When I interviewed candidates for PHP programming posts, I had a carefully prepared PHP script (about 1 page full) which was lousy with bugs and bad style (using register globals, calls to header after output started, functions which are not called, using numbered instead of associative arrays, function args in the wrong order, using computationally expensive functions when simpler ones would have surficed....) which only used common PHP function calls and gave them 30 minutes (with access to a internet connected computer) to identify what was wrong with it.
This also meant that they could carry out the test in controlled conditions.
I would hope it was evident to the candidates that this was exclusively a test of their abilities rather than anything I might profit from - and debugging code is a lot harder than writing code.
C.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been a PHP/MySQL developer for a number of years now, but unfortunately have only worked with small projects up until now. I'm starting a new website now that is very complex and I'm starting to get confused with the workflow. I'm not sure which parts to take care of first, as they're all fairly intertwined.
I'd love to know how some of you manage your workflow for a new website. I'm working independently, so it'd be easier to explain without multiple developers involved. Also, I'll be using the CodeIgniter framework, so it'd be great to have the workflow involve the MVC model, which should actually make the workflow easier.
After some searching, I came across this helpful diagram:
However, I'm not too sure what falls into each category. Here is a general rundown of what I understand so far. Please feel free to correct me when I'm wrong or when there is a better option.
Planning
Make sure you have clear goals for the project: What do you offer, and for whom? How will it be helpful for others? Etc
Sitemap
List all the pages and sub-pages that are going to be on the site.
Wireframes
Go through your whole sitemap and make a rough sketch of every single page. (How detailed should you get?) You can use pencil and paper, or programs like Axure or Mockingbird.
The next major category in the workflow chart is content, but I'm not sure what this involves. Is it all the text on the website? Database structure? Something else?
Artwork
The actual design/template of the website. Is this really the right place for this, though? I would think that the coding and functionality is more important, and make the design after that.
Coding
This step seems to all-encompassing, and I'd think it needs to be broken down. Is the database structure made first (or was that done in content, after the wireframes?) Do I make the outline for all the functions for each page in the sitemap? Do I just create all the necessary controllers and make comments of which functions I'm going to put and where? Do the models go after the controller outlines, or vice versa? When do I start filling in all the controllers and models?
Constant testing is involved to make sure your code works properly.
Content Population
Would this include the view files in the MVC framework? In other words, all the data that the controllers and models provided?
Final Testing
Make sure everything works in all browsers. Making tweaks and changes here and there. Go all out with numerous "what if" cases.
Production
Site goes live.
Conclusion
The above is what I understand to be an organized flowchart of the steps in developing a complex website, but my understanding could be greatly improved. What should be changed? I could use all the suggestions possible. Thank you.
EDIT: Someone here mentioned "agile development"--from what I'm reading thus far, it doesn't actually have a structure. Correct me if I'm wrong. As I commented on that answer, is it really possible to develop in such a way for complex sites, such as Amazon or Ebay? The workflow process, in my un-knowledgable opinion, should have a clear plan, or else there would be no focus in the project.
FINAL EDIT: Although this question was closed, I'd like to add some info for those that may find this later. I found the following workflow useful: http://www.webassist.com/free-downloads/tutorials-and-training/web-dev-workflow.php. A PDF of the general workflow: http://assets.webassist.com/how-tos/Short-Dev-Checklist.pdf. Agile development can also be used of course, but this could be a good starting point for those that don't know where to start. I may add additional workflows and examples here as I find them.
The R&D world is moving towards agile development, where you don't do so much planning and write everything down from start to finish, but rather do small iterations and make small changes so that you always have one clear goal in front of you, and you can adjust your direction as your understanding of the requirements improves (real ones, based on user feedback, not estimated guess work based on what you think the customers will want/use)
I suggest you research Agile development, and Lean startup methodologies, it changed the way I build online services, and will make you much more efficient and productive.
I can tell you that my online service went live about 2 days after I started coding. That does not mean that you open it to real users right from the beginning, but you can get immediate feedback from the real world instead of keeping it all on your dev machine until you're "ready to go live".
Agile development is definitely a good idea for websites (as, typically, the coding is both relatively easy and independent). The main point about agile is that it allows for changes, and it also allows for adjusting for "it took longer than expected to do Feature B, so C and D will be delivered in another iteration". As you are probably aware, planning larger projects can take a lot of effort, and is almost always longer than you'd expect. With agile, you do each bit as a "vertical slice" - meaning anything done should contribute something useful to the product, all the way from adding a ling on the front-page [or wherever it belongs] to adding the code to handle it and the database model to store/retrieve relevant data.
I'm pretty sure that you still need to do a fair bit of planning for a large site with lots of pages, and lots of database tables, etc. But as long as you have a reasonable grounding in general website/database design, Agile methods will let you design "walking skeleton" (somethig that works in the basic concept, but need more meat on the bones to be a working product). Then you flesh out the sketch with more features, each feature is "complete" in itself, and adds something the customer needs. That way, you always have something you can deliver to the customer after each workitem is finished.
I'm also convinced that Amazon or Ebay has A LOT more than 20-30 tables. I work with a site called www.planetcatfish.com, and it is MUCH smaller and simpler than Amazon or Ebay, and it has 25 tables (besides the phpbb tables for the forum, which is also used for the site specific user functionality). And that was written over many years, using mainly php, a little javascript and a fair bit of mysql inside the php code.
TheZuck's answer is good and very helpfull so I'll just add some of my own experiences, which doesn't necessarilly mean that you'll go through the same thing, and probably won't if you have half a mind for business (which is what I'm lacking. :S).
Content has always been a problem with my clients, so I'd say get them working on that early! If you're working with a copywriter I guess thats not a problem. But there should be some sort of penalty for not delivering the content to you in time.
It is also worth noting that your clients will only really start thinking about their website once they start thinking about the content. Expect to hear about them wanting some changes when they've started working on it.
If you're clients are small businesses, then they tend to not understand what it is that actually takes time. Even though agile development is really nice I believe that this will be hard to implement towards small businesses since they don't have very much money to work with and will probably want a fixed priced for a finished product. And if it's fixed they'll just get pissed if they've used up all their time or whatever it is that they've paid for without giving them a finished product (working deliverable, is not the same as a finished product!).
Clients tend to be IT-illiterate, sometimes to the extreme. Count on you having to put some or quite a lot of time into explaining "obvious" things to them.
Don't overestimate yourself and your abilities, since this will probably mean that you'll charge less than what is actually reasonable. A quality website should cost money, but I for one will understand if you charge to little, you know just to get a few clients.
I realise that this isn't really an answer to your question but I hope it will help somewhat.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
One of my freelancer friend work with wordpress, he knows basic php, but does not working in core php program. During his work he take sample code from Google and then edit that code and use on his client project. It always works and he says he could understand most of the language. Because he works in basic level of c,c++,java,html,css,php. His motto is -- work and learn though it takes much time.
On the other hand, another my friend learn php from very basic and want to be a core programmer. His motto is -- first learn then work with less time.
I am just confused what can i do. If everything is possible from Google after learning basic php then why i learn php very deeply. Is it good to code myself whether all type of code is available on internet?
I think that skill level is tied to compensation. The better skills you have, the more valuable you are. A lot more people can take some PHP code off the Internet, changed it up and make something work. However, a lot fewer people can build architecturally sound and solid software solution to some problem.
It all depends on what you want, if you want to be a top notch software developer, then you should have an attitude of one and try to improve all the time. If you want to get buy and make some money tweaking WordPress sites, fine. A lot of people do fine with that.
I am not exactly sure what kind of answer you are expecting, but I can tell you this:
I have been working for more than 10 years as a programmer, and I am STILL learning every day with every new project, and even though google is a great help and the kind of info you get there is just incredible, it still doesn't replace your own knowledge and programming skills. Every example you can find on google will still need tweaking and that is where you will NEED to know what you are doing.
I think the point is this: If you are going to work making small websites, charging $10 / hour and just doing basic contact, signup and data forms, then forget about learning php deeply, your friend is right to learn as he goes. And in this case, you should dedicate your time to learn other very important skills like databases, SEO, mobile compatibility, etc, those will give you a greater opportunity to get more customers and projects.
However, if you intend to become a serious programmer and work in large projects, charging 3 or 4 times that amount, then forget about small websites and learn deep programming logic that you can apply in any kind of language or situation.
In the end, there is not right or wrong path, it just depends of your own goals and needs.
I'm using Drupal a lot right now for large e-commerce websites that connect to in-store POS systems. There is no way I would be able to just take code from Google to create these websites. Sure, I can "borrow" simple snippets from documentation; however, on a professional project... this doesn't get you far.
If you want to create an unsecured website, waste 90% of your time on simple bugs that someone with basic knowledge could fix instantly... then sure go the lazy route.
it depends on your objective. If your objective is to "learn PHP", then you should definitely learn how to use the language, etc. that way you can make things on your own, rather than having to google things on how to do it.
Googling for solutions is okay as well, however, if you don't know how the code runs, or understand how it works, you won't be able to change it on your own to make it work with what you are trying to do. That is the benefit of understanding the language; you can take existing code, and modify it to make it better or work for you.
To apply correct solutions you need to understand how they work, and what are limits for the particular solution, be able to adopt such solution to the problem. It is like if you would build from cubes - when you are child, you need only basic gravitation rules, but if you want to build really big tower from same cubes you need know more physics and maths, and possible, to choose another construction units.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am about half way through coding my own Php Content Management System from scratch, but now I am nearing the end of coding new features and making it look good and am now being faced with the big issue of security. I know little about the security side of Php except the fact that it is very vulnerable with SQL injection etc. Let's just say my website was going to have loads of user generated content and be like facebook, is that something one person could secure by themselves or am I better off paying someone to do it for me? if so, anyone know how much that would cost?
Any feedback would be greatly appreciated.
Update:
Any opinions on http://www.incapsula.com ?
With so many mature PHP CMS systems available, the only reasons I can think of for writing one of your own would be as an exercise (to learn something), as a challenge (to see if you could), or if you needed some specific feature that the existing ones didn't have. Even if you did want a special feature, I'd still look at extending an existing CMS rather than writing one from scratch - many of them cater for modules and / or plug-ins.
Pros:
It is fun to build your own CMS.
You will learn a lot. It might be the best way to learn PHP, since you will have to deal with a lot of different aspects of it.
Cons:
Your first CMS will always have a "funny" design.
You will have bugs and security holes (but most of the times, people will not notice the security holes). ;)
You will have to spend (much) more time on your CMS than what it would take to build the site with an existing CMS.
Conclusion:
Of course you shoud build your own CMS! You are not a real PHP programmer if you never have built your own CMS.
Is it worth it?
Completely up to you. I'd say it depends on what your goals are with this CMS (generating revenue, just for fun, etc) It's nice to be able to show someone and say "I made that from nothing!"
The only start up costs would be your domain name and monthly web hosting (unless you hire people.) $1.18 annual for a godaddy domain, $8 for hostmonster hosting.
Security's a big issue yes, but maybe that shouldn't be the deciding point in doing what you want or not. There's alot of documentation on stackoverflow and others regarding the subject that could help you.
I've recently created a CMS from scratch with no prior knowledge of anything beyond basic HTML. It's rewarding in many ways and you may even find yourself going down a programming career path.
I think it'd be better to learn how to protect your system. Securing php systems is actually not that big a deal, considering you were able to code your system from scratch.
Just remember, to prevent sql injection: always escape user input entered to the database, mysql_real_escape_string() usually does the job. And use htmlentities() before displaying the content in html pages.
Read on securing your PHP and you'll save yourself the trouble of paying someone to do it, plus it'll help on other projects.
Trust nobody - especially anonymous people! Therefore inject into you mayor asset some safe data. Seems rather wise strategy
Why make your own CMS? Drupua, wordexpress. Jomala might do with some tweaks?!
Yes it is worth making a CMS from scratch. Because you have/only have the features that you only need. Which makes the script less extensive and fit your needs like an Armani suit. Let's consider Wordpress as an example, when your site gets terribly big you would need to terribly tweak it. It has alot of features, and some of them you might not need. The pro if using already-available ones is the community finds the script's bug/holes for you and all you need to do is just update the script.
As for the security part, you can try to find the holes by yourself or hire someone of which their rates may vary. But you might not want to entrust your script to others unless they're trustworthy.
I'm just about to finish a marathon 9 month project-- a web app with over 70k lines of code. Problem is I hardly used comments, never used javadoc, and never kept any good documentation of any kind. (oh the guilt!! :) )
I now need to focus on the non-technical aspects of my business and pass this giant off to a programming team for maintenance and new features. So what can I do...what are the most useful comments/documentation to write? What's the best strategy for retroactive documentation? (Are there books on the subject?)
PS. Thanks for your months and months of help Stack Overflow. I barely knew HTML a year ago. You got me through it all!
70K lines isn't all that large. It might be larger than projects you typically work on, but at least it's not so large that one person can't understand most of it. That's probably what got you into trouble in the first place. It wouldn't kill you to go through each file and write a few sentences about what the class does.
70K lines is way too large to foist upon someone, or some team, without some sort of explanation of what it does and why. Take pity on your poor underlings (and reduce the man-hours that they'll waste scratching their poor heads) by at least writing a road map that explains in detail what the project does, how it's organized, which parts are important for performance or to meet requirements, which parts need work. If you had any written requirements for the project, those should be included.
I'd imagine that before you make your team work on this undocumented pile of code you plan to at least sit down wit the team members for a day and give them an orientation. Write down everything you'd want to tell them during that orientation. Give the team that document and some time to read it before you really do meet with them. Now you can use that day with them to refine the document by answering their questions. Ensure that the answers make it into the next revision of the document. Let your team's first task be to fix the problem you created. That'll help them get ready for the time when they do start implementing new features.
Be available to answer questions from the team for the forseeable future. Create some sort of system for organizing and preserving the information you provide. A wiki seems obvious, but you also want to make sure that new questions get noticed and answered quickly. A defect tracking system could work well. So could some sort of Q&A format like SO.
Change your attitude toward documentation. Learn from your mistake, change your ways, and encourage/insist on people spending time to document what they do. Try to make documentation as automatic as possible by connecting your defect tracking system and your version control system. Give your people the resources they need to produce useful documentation. Put someone in charge of documentation.
I tend to do just as you do, retroactively comment, if I comment at all. However, when I do, I try to document mainly my custom functions & classes, and important parts of my code. I note things such as:
Required Parameters
Return values
Explanation of the function
The best thing to do when commenting is think about what'd happen if you suddenly disappeared and couldn't explain your code. What would the developer who took over need to know and understand. Obviously, you shouldn't have made your code too abstract either (aka, only using variable names such as $x, $y, $z unless appropriate).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We're looking for someone to help us enhance & maintain our high-quality, php-based prototype of a transactional web app. Ideally, who can communicate well, and do both front- and back-end web development (as well as smart/gets things done, etc.). Among other more general things, I've been using this question:
Given this:
$foo = array(1, 3, 7);
write a function (on this whiteboard) to sum the values of the array.
It seems trivially easy to me, but has caused a couple of deer-in-the-headlights situations, which always makes me feel like a villain.
I've read a number of posts here and there (including both Joel's and Jeff's) saying that how candidates think, design skills, passion, etc. are more important than any specific technical skill, and I agree with that. Also, I can see that programming at a whiteboard is a little unrealistic. OTOH, this seems so basic to me that I'm inclined to see it as a fine first-pass filter between front-end devs (who know their way around html, css, and how to copy-and-paste a js function or two), and people who can really code. Thoughts?
A touch more info: I'm open to all sorts of answers: array_sum, a for loop, a foreach loop. Heck, if they want to write an ArraySum class, that would be overkill, but just fine. Using javascript, or another language would be fine, if they're more comfortable with that. Even attempts with minor errors would be ok, but I've had a couple of complete freezes, so I just wanted to sanity check myself.
I would consider that much too easy of a question, personally. If someone asked me that question in an interview I'd probably be busy trying to figure out what the "trick" was, because it's so simple.
I think it's fine for weeding out the absolute worst programmers, but make sure that you don't have one particular "right" answer in mind and refuse to accept anything else. For example, don't only accept "use the array_sum() function" as the correct answer, where it's really just a test to see if they know the function exists.
I mention this because my fiancee once had a programming interview where she was asked how she would reverse a string. She gave several different algorithms that would accomplish it, with the interviewer telling her that she was wrong after each one. She finally gave up, and he (disapprovingly) told her that she should have just used the String.Reverse() function.
Don't do that. Please.
in my opinion, the question is perfectly valid, and tells a bit (not a lot, but an important bit) about the candidate, depending on how much time you invest in it. just tell her that it's not a trick question beforehand, that it's really, really as simple as it appears, so she doesn't spend to much time thinking about the pitfalls and to minimize the deer-situation. throw in you do that just as a measure to filter out the people who apply for a programming without actually knowing anything about it but hoping they get hired anyway by pure luck (if they know how to code but are just nervous, that should take a bit of pressure away). let them code, but don't focus if there is a $ missing or if the <?php tags are present or not.
if she provides array_sum or sum_array as an answer almost doesn't matter, especially if the language in question is php (but if two candidates are equal otherwise ... i can't even remember the last time i had to use this function). and the use of an auto-completion and syntax-coloring (with predefined keywords) IDE vs. a dumb text editor matters a lot in this hindsight. in this case ask for an alternate, handcrafted solution.
if i was in the position of asking that question i wouldn't ask for the right solution, i'd ask for ways that come to her mind how this problem could be solved, what pitfalls could arise in special cases. try to find out what she knows about programming, not what she knows about php. try to find out about intelligence, problem solving and creativity. altought experience matters a lot even when it comes to bang out code fast, it's not a constant.
the solutions i'd provide, the pros/cons and what it tells about me ...
built-in array_sum (very fast and definitley not buggy, but inflexible): i have a bit of experience with traditional php projects
for/loop constructs (good enough, reinventing the wheel. but can be used if there are different objects than numbers. pros: everybody will understand it): i can solve simple problems if there are no predefined copy&pasteable solutions
array_reduce (with an offering to implementat array_reduce, if the interviewer wants to see it): unusual for a php programmer, so it seems i have knowledge and experience outside of the php sandbox
an ArraySum-Object (with an ArraySum::add($value) method that keeps all values stored but caches the sum): i'm used to at least some of the oop-principles
function () { return 11; } (with the disclaimer that this is a joke solution, but valid): i have (albeit crude) programmer-specific humour - a sign i'm personally interested in programming outside of work ... some interviewers who are programmers (but not hackers) might interpret this as a willingness to use dirty hacks as placeholders (aehm) if time constraints are too tight
a recursive solution would be nice. i can probably solve a bit more complex, algorithily problems too and most likley know my way around simple trees and data structures
recursive divide and conquer: bonus! i know even more about algorithms.
try to get as much as possible out of this question (if time permits). in the end you'll know a little bit about programming capability and a lot about experience (altought not necessarily PHP specific).
i'd choose this question over letting the candidate write out quicksort - a very specific question about knowledge almost never needed in the web dev world - any time.
disclaimer
the question is useless when ...
the interviewer is not a programmer. forget it if a hr-guy is doing it
there's a very tight time constraint when interviewing. then the result is almost random anyway.
additionally, who are you looking for? if you need a cheap grunt coder, even a simple question like this should work. if you need quality and experience, don't waste too much time on it (but do it anyway).
No, it isn't too hard. If someone doesn't understand the concept of a loop or how to iterate through an array, they're not qualified as programmers. I'd also want them to know that there's a built-in function for that (array_sum()), or at least where to look for it.
You might want to take a look at The Five Essential Phone-Screening Questions, although you'll probably have to rework them a bit to suit your needs.
My own view is that there is a limit to the kind of toy questions you could ask for programming on a whiteboard. At best, these are simply toys that are often circulated on online forums and your candidates will memorize.
Most PHP developers created visible websites - you could see their work.
To me, a much better question would be to give him a complicated piece of your own production code and have him explain what it does or how it can be improved, etc. Most of the time will be spent doing maintenance anyway, better get an idea on his code reading skill, not just code writing.
Short Answer: No
Edit: Just to clarify I don't think this is a hard question at all. Regardless of the language. As others have posted, even if they can't get the syntax correct, the should at least be able to write it out in a reasonable pseudocode.
Long Answer:
I often ask interview questions I expect the candidate to miss. One could classify them as too (hard|vague|open-ended), but I am not really looking for an answer. I am looking to see the following:
Do they try to answer the question? Some people just give up immediately
How do they approach the problem? Even if they go down the wrong path are they generally making good assumptions and asking good questions?
How well do they maintain composure under stress? The question is designed to be hard, and therefore will be stressful. Do they panic, remain calm, withdraw, talk it out, etc...?
Are they able to find the solution if I give them hints and pointers? Or how well do they listen, and do they assimilate new information quickly?
Occasionally I am surprised with a candidate who is whip-smart, and just codes up a quick and elegant solution. Those are definite keepers. But I also find good candidates by people who miss the final solution, but are clearly thoughtful, logical, and given enough time would eventually solve the problem.
no, it isn't too hard, but it may cause people to panic if they do not exactly remember the syntax (though if you specifically ask for a php dev, then they should at least remember some syntax). Ask for pseudocode instead, if they still cannot do the question then there is a problem :)
If your applicant can't write a simple for loop and some addition on a whiteboard, you absolutely don't want them touching your code. Even as a front-end developer, they'll be using for loops all the time to output lists, table rows, image galleries and the like.
This is the type of basic thing you ask on the phone before bothering to bring a candidate in house.
There are a couple of standard things I ask every programmer about: Do a select on two tables to give a sum of a column in the second table, delete records from one table based on values in a second, difference between an object and a string as a method parameter, and a couple of html/css related questions.
Within 5 questions I can weed out 90% of the candidates before I even see them. The rest of it is going to boil down ideology.
My favorite would be:
while ($foo && $sum += array_shift($foo)) continue;
This question may be better improved by providing the documentation for the array() function, because if they don't know what it is, they could very easily look it up themselves in a job.
It's not too hard. If they cannot answer that question, they obviously cannot code their way out of a wet paper bag. I would definitely not hire such a person for any kind of development work.
Question is, how could you improve your recruiting process to avoid interviewing these candidates in the first place? Sounds to me like you're not screening your applicants enough before inviting them in for a chat.
If you can't write code to sum an array (in whatever language you prefer) I don't know what you can write. What on earth do you think someone could contribute to your project if they can't write code to do that question?
Actually, this questions seems kind of... easy.
I suppose writing it on a whiteboard makes it more difficult, though.
This question should be easy for people that have programming experience, but I'm guessing you may be getting a lot of designers that picked up PHP by copying/pasting code snippets in place.
Maybe you need to update your job listings to make them more programming centric and avoid web design terms.
No, it's not hard. What you've discovered is that there are a lot of "programmers" out there who can't program - they can memorize, they can copy and paste, but they don't actually understand what they are creating (in most cases they seem totally unaware of their lack of understanding).
This lack of understanding becomes painfully obvious when they are asked to write something simple from scratch - writing just the glue code, without all the complex stuff that they'd normally just grab as code snippets and then shift around until the compiler stops complaining.
In general you want to avoid these people like the plague, as they will consistently produce buggy code and will not understand why you or your customers think it doesn't work.
Jeff wrote about this a few years ago: Why Can't Programmers.. Program?
To be honest, I would like to think that if a person applies to a programming position, he or she will probably have the relevant skills on their resumes. Why not ask simple problem solving questions instead if the position doesn't require some sort special skills in the language in question? I was once asked how many pizza stores there are in my country. They were interested in checking how I approached the problem and weren't really interested in how awesome I might be in the relevant programming language. I think that was a good way to go about it. Am I awfully wrong in thinking that?
Edit: Or is it very common that people fake their resumes?
(I think the array_sum($array) method, as part of PHP, will do the job.)
The question really is trivial. Although there is enough space for error in a stressful situation but summing up an array should be easy enough for anyone with basic programming skills in any language.
It would take a dunce to muck up an interview with a question like this. The question is not too hard, it's actually very lenient.
It depends on what you're trying to ask. Are you screening their ability to recall syntax? Or are you looking for best-practice methods in dealing with array functions? If it's the first case, your question is fine.
On the other hand, if you're trying to see how well a person actually understands code, and knows implications based on how something is structured, the question is good, but instead of requiring them to write a line by line function, invite a discussion on how they would do it, and what would be some considerations with their answer. Why not do it via method B?
IME, asking for rote memory responses (syntax recall, port numbers, etc etc) tells you some aspects of an individuals ability, and sometimes need to be asked. But more important is digging into their problem solving abilities.
I don't see why anyone would have any problems with that. (Assuming that they are developers) And yes, programming at the whiteboard is unrealistic but that is a trivial question which any developer should be able to solve.
I had a deer-in-the-headlights moment wondering what the trick was!
Anyone applying for a programming job will know how to add integers together (one way or another, even if it's in a loop), so I'd skip it and find something more challenging....but not so confusing! :)
I've done interview recently for PHP position. I've been asked to write simple function on paper (of course not as simple as your example).
Anyway, when I've done that function (some 6 lines of Python code), interviewers where
pleased. They told me, that there are lot of ppl unable to write any code without IDE, and this small test serves to filter them out.
As for your example — it's just to simple. Especially if you accept array_sum() as an answer.
I wouldn't believe that there are such "programmers" out there, if you'd asked me a few years ago. But what has been seen cannot be unseen. I've witnessed firsthand people who make a living out of programming websites and know nothing about programming. They just copy and paste other people's code around, until they get it running. And you wouldn't possibly believe how their income level fares compared to their "skills" (yeah, income level does not directly relate to skills but it still freaks me out).
Yes, you are sane and those people do exist. And what you are doing is one of the useful filters for filtering "pragmatist script copy-pasters" (or others) from real coders. Of course, unless you want copy-pasters (they can accomplish some simple tasks! -or more complex ones but with unbelievable code-) in which case such an interview question is really hard for them.