Recently, Susan Fennema, our Dean of Success, explained our 10-step process for recruiting new team members. For a development position, step 4 is to review a code sample. In fact, when we post a job opening, we ask:
Please do not apply if you cannot provide an unlocked sample of your FileMaker development.
We require an unlocked sample to assess your degree of proficiency and development style. It should be obvious; submit your best work. If you are concerned about confidentiality, then provide a clone with some sample data. We prefer to review a local file rather than connecting to a server because it is faster.
It only makes sense to prove your development skills for a programming position with a software company.
What We Look for in Sample Files
While no programmer is perfect, we are watching for the telltale signs of professional development. What does that look like? In a nutshell, it shows forethought. The code is created with consideration for the next person who will enhance it. Below are some of the things I consider when reviewing a sample from a prospective developer.
- Complexity – How many objects are in the file, especially the number of tables, fields, layouts and scripts? What degree of complexity can the developer manage?
- Naming Conventions – What are the naming conventions and are they consistently applied? Do they help another developer understand the code?
- Relationship Graph – Is the relationship graph well-organized? Does it make it easier or harder to comprehend the solution?
- Layouts – Does the file contain different types of layouts (data entry, list view, reporting, etc.)? Are they sensible pieces of a whole application?
- User Interface – Is the user interface attractive? Does it encourage a perception of quality from the average user?
- Scripting – Do the script steps demonstrate knowledge of the modern techniques? Is the developer using the latest features?
- Modularity – Does the scripting show an understanding of the concepts of dynamic, portable, and reusable code?
- Commenting – Are there any comments in the scripts? Do the comments make it easier to work with the solution six months from now?
- Developer Tools – Does the solution use custom functions or custom menus? Is the developer familiar with FileMaker Pro Advanced?
- Systems Integration – Is there evidence of integration with other information systems? What are the technologies–ESS, ODBC, PHP, XML, plugins, shell scripting, web services?
In summary, we want to determine if you are a budding professional developer or a cowboy programmer. We are willing to help you learn; however, we need to see potential to ensure you can serve our customers with excellence. If you are ready for the challenge, I encourage you to apply online. We do not promise the process will easy. We do promise it can be worth it.
Excellent! We’re in the recruiting process in our company. Your article is very useful. Thanks for sharing!
DD
Diego, thanks for stopping by. Glad to hear you found the article helpful.
How do you measure orderly complexity vs unnecessary TO’s and scripting?
I’ve been practicing rebuilding my old files with my current knowledge just to see the difference, and ended up with the cleanest graph I’ve ever had – essentially one TO per table.
So, “how many objects are in the file” as the way to measure a developer’s ability to handle complexity is probably not the best description, even with the other considerations listed.
Maybe the question should be: How can you tell the difference between elegant code/brilliant solutions vs a file that didn’t solve a very difficult problem?
(Of course, it’s rare for a developer to not trumpet his own elegance, but let’s say for the sake of argument that the only thing you know about the guy is his file, and he’s not available to answer your questions at the moment.)
Hey Brad, do not discount the number of objects in the file so quickly. I specifically mentioned tables not table occurrences. I agree less is more when it comes to the relationship graph. However, the number of base tables, fields within those tables and layouts are a good general measure of the degree of complexity. Of course, anything can be taken to an extreme. For example, I saw a file last week with 600+ layouts. 🙂
I suppose then you would define “complexity” based on the data model chosen by the developer? In an entity-attribute-value model, for instance, the actual table count might be quite low. But the fact that the developer chose a varied model to begin with would suffice for a complexity measurement perhaps?
I suppose the overall goal is to see how many concepts the developer was able to juggle at once. Once you figure out his or her data model, the actual determining factor – i.e., how many tables or whatever – will make itself known.
Brad, you are dead on. I am looking for concepts and how they were implemented. The EAV model is an advanced concept that few FileMaker developers have used.