Tag: interviews

Why I chose to build a framework at a 3-hour interview

I encourage the use of known frameworks over custom ones, but I decided not to use one when, at an interview, I had 3 hours to prove the technical aspects I’ve been talking about at the first encounter with the employer.

The task was simple: build a REST web service (using PHP and MySQL) and make some operations on a resource, and a small JavaScript client to interact with the service.

I felt that using a known framework for a basic task like this I couldn’t show too many principles I use when developing. It wasn’t the moment to build a production ready app, it was just to show I can DO what I KNOW.

So my 3-hour journey building a framework from scratch started. It had basic components like: Continue reading Why I chose to build a framework at a 3-hour interview

Hello, interviewe(r/e)!

An interview should be in both directions. Both the interviewer and the interviewee should have questions to ask, as you know, of course.

While the interviewer is expected to have any kind of questions and requests, I’ve seen most interviewees lack some things I always need from a company in order to get to know them better.

I’ve been on both sides, and I really consider that if you go to an interview, you should ask about the following, and I’m really happy when I’m asked about them:

  • Code. There is no reason for a company to refuse to show you code. 100% there is something that can be shown.
  • Frameworks. If they use custom frameworks, ask details on how they manage some basic situations: models, repositories, dependency injection, dependency manager/packages, events, and so on. And why did they need a custom framework?
  • Tests, build, deploy, devops.
  • Databases. Structure can tell you some things about the project.
  • Team. Is there anyone you will learn from? How many members are there in the team?
  • Loading/compile time in development. If it’s a browser app, ask to see a page refresh. If it’s a cli app (even more if it’s a long live app), ask to see how they reload.
  • Code versioning system.
  • Workflow. From specifications to release. How do they manage the whole process?
  • Critical situations management. What happens if something doesn’t go as planned: bugs in productions, servers crashes, people issues.
  • Hardware and software. Your working environment (desktop/laptop/ide) should be with you, not against you.

I’m not saying you should decline a company if they don’t satisfy you regarding all of the above. Just know them better and make the best decision for you.