I know it’s a widely explored topic, but after a row of bad interviews I would like to spell out what I think it’s necessary to a decent job interview.
A little premise
I work in the interface development department of a big company, and I interview web designers, interface developers, frontend developers and sometimes assist my co-workers in other web related interviews
The first thing: character
The first and most important questions (IMHO) I ask are open questions about what the candidate thinks about some technology (or anything, really). Sometimes I ask about something that is universally known ad bad, ugly, or old. You can’t know how many persons reply “I like that” thinking that if I asked then it interests me. No no no no. The worst mistake.
If you don’t like something, say it. Even if the interviewer might disagree (but if he has skill, hardly will defend an old / ugly / old matter). First you must have character and skill and if something is wrong you must stand for your opinion.
I don’t want to work with someone that doesn’t have an opinion. Continue reading
Recently we decided it was time to write better css and optimize a little, and we did choose compass and the scss syntax as the tool.
The project i’m workin on is organized with a very big css/ folder with a css for every page, a couple css for the common classes and some css files with fixes for certains nations (I’m speaking of Russia, China and Japan, where we have different fonts and all the spacing changes); it is also deployed with continuous integration on several test environments and the production cluster.
In the past we did try a conversion to less, but it was unsuccessful, mainly because the less syntax is not compatible with css so we needed to restyle every page (a lot).
We planned a lot on how to introduce the scss files and after several tries we noted that:
- it was unnecessary to rewrite a single line of css: the scss syntax is superset of css
- we did not need to convert scss file live and cache them – at the beginning we could source control both
Once all the interface developers were the loop and motivated (pretty easy ;-), we decided to migrate in steps, to make the transition easy:
- Copy the css folder to a new ‘sass’ folder and rename (batch rename) all the files to .scss, commit and celebrate. This is the core action to introduce sass.
- Modify the continuous integration script to recompile all the css during the build/deploy task: this way we could remove the css file from versioning and avoid unnecessary merges
- Modify the above script to deploy the generated sprites: we keep them on different servers and we decided it was not a vital step, so we separated from the second. Continue reading