---
# System prepended metadata

title: Technical Interview

---

# Technical Interview
**name: Antonio Ferraro**

My SQL server
NATO: Delphi, performance of maritime sensors, file based databank
4.5 year

Glans (NATO) - team of 4 persons
3 year manager - data links (positions of military, radio frequency)
C - JAVA 2006 - no framework from outside, web-based, radio, several European countries, full success, JIRA
in 2015 - move to Den Haag
2019 - 6 months for Lampiris, accounting, JAVA optimisation
IntelliJ, JIRA, gitlab, PostgresSQL
training and testing from NATO again
2020 - with Corona take a break
2020 - Vivid Consulting - Python, Data Science, courses in R (John Hopkins University)
VLIZ - EuroBIS - record of maritime observation, MySQL


_This document should not be followed like a script._

## Useful knowledge
* Python
* Flask
* OIDC
* SqlAlchemy
* Docker
* Git / GitHub
* GNU/Linux

## General Questions
* **ICEBREAKER**: Tabs or spaces?
>
> A silly question to put us all at ease.

* Are you comfortable with a junior engineer, or someone you consider a junior to yourself, reviewing pull requests that you submit?
>
> Antonio is a very experienced engineer (a long time in industry). How will he react to
> e.g. James asking him to make changes on a PR?

* Are you comfortable with open-source "bazaar" style development? What does this mean to you? How would you increase your comfort enough to tackle the project?
>
> The project he will work on has no requirements but will instead rely on communication with the
> scientist, Alex, and James. How does Antonio want to approach this?

* You mention that you spent most of your career in NATO SSSB program. Including in a leadership position.
    * What was your greatest or proudest achievement there?
    * Why did SSSB switch from C to Java?
    * Why did you leave SSSB?
> I am especially curious why he left SSSB. Why they're no longer employing him as a consultant?
> What was his real level of involvement. Technical or managerial? Did he make technical decisions?
> On what did he make those technical decisions? Did he mentor people?
> Was he involved in writing production code or was he QA only?

* Have you worked in or would you be comfortable working in an "Agile" environment?


## Technical Questions
We can safely assume this candidate has basic Python knowledge.

* What version(s)/implementation(s) of Python do you have experience with?
>
> CPython? Pypy? Micropython? Cython?
> This question is for the interviewer, sets the stage for the remainder of the interview.
 
* If you see something that you don't recognise as Python, what do you do?
>
> Example, is the following code "correct" and if so, what does it do? If not, correct it.
```python
x: dict[str, int] = {'a': 1} | {'b': 2} # Python 3.0 type annotation, Python 3.9 dictionary union
if (y := x.get('b')) is not None: # Python 3.8 walrus operator
    print(f"{y} {x.get('b')}") # Python 3.6 f-strings
```
> This question is a gauge of their experience with Python.

* Do you have experience with development in containers? Docker?
>
> This is a project specific question and does **not** disqualify someone
> with no experience. MSV is deployed with rudimentary docker and there 
> is a development container.
> A good answer will elaborate on the pros/cons of development inside a
> containerised environment.

* What are your thoughts on _Test Driven Development_?
>
> Provides the interviewee with an open question for them to elaborate on
> a topic that greatly overlaps with their previous experience.

* You have some experience with GitLab and GitHub. How do you feel about the automation system these services provide?
>
> Again, overlapping with their previous experience and expertise.
> Opportunity for them to elaborate on their knowledge. How would they set it
> up? When should automation run? What should automation run (unit tests,
> integration tests, end-to-end tests)? Experience with CD? How much
> automation should be in deployment?

* Was "Eurobis-QC" the first "real" Python project you? What got you interested in Python?
>
> Gives the interviewee an opportunity to elaborate on their experience with
> Python. If they don't mention themselves ask about teaching their son.

* Which tool do you prefer to use for package management in Python projects?
>
> This gives us insight into his level of Python ecosystem knowledge. Does he
> use a package management tool? Is he familiar with Pip and Setuptools
> (used in Eurobis-qc)? Virtual environments? Pipenv? Poetry? Conda? 
> Why does he prefer a tool?
> Would he be willing to use a different tool? Under what circumstances?
> Being opinionated can be a good thing.

* What are your thoughts on object-oriented programming in general, and specifically as it appears in Python? Do you prefer inheritance or composition? 
>
> Very open question. Gives the candidate the opportunity to display their
> general knowledge of the topics (coming from Java) and their specific
> knowledge of Python. Also potentially shows their human character.

* How important is documentation to you? When should documentation be written? By / for whom?
>
> An important aspect to software development. Especially as a consultant.
> A good answer will emphasise the importance of documentation for "users"
> throughout the lifecycle. Look out for nuance.

* Could you contrast the ORMs you've used (Hibernate, Django, ?SqlAlchemy?)?
>
> Has he used a Python ORM?
> Is the interviewee familiar with Django and SqlAlchemy ORMs. Hint provided
> for their past experience with Hibernate in Java. Possible follow up
> question: would you use an ORM in a new Python project, and under what
> conditions?

* What are your thoughts on the following "Best Practice" advice?
    1. Use tuples instead of lists because they're faster.
    2. Use `while 1` instead of `while True` for infinite lists because the former is faster.
> This candidate is experienced. I expect them to have a bad attitude towards
> "best practices". I also expect them to say that hunting performance,
> especially micro-performance like the above advice is about the worst
> thing a developer to do. An extremely good response would be that they're
> both probably wrong or to ask under what circumstances they would be right.
> Follow up: if you were interested, how would you verify performance? Leads
> into a question about performance testing: when, why, how?

## Practical (if there's time)
* Code review on [Eurobis-QC](https://github.com/lifewatch/eurobis-qc)