job interview - candidate questions

contrary to some ppl's opinion, job interview works both ways: employer checks if your knowledge meets expectations, you check if this job will be fun and creative. below is my personal list of questions i tend to ask, before accepting any job offer. recently i've decided to make a list out of these, since often, when i forgot about some parts, they came out not the way i expected… questions are important not to get disappointed on the first day. if the employer does not want to spare some time on answering this, it means that either you'll be just another “human resource” no one gives a damn about, or is hiding something. both cases you probably prefer to step back.

1. how will recruiting process look like?
   1. how many interviews?
   2. when need to go on-site?
   3. how long before getting the feedback?
   4. how detailed the feedback will be? crucial in case you fail.
2. working conditions:
   1. where is the office located? think about getting there and back on a daily basis.
   2. is there a place to park a car? even if you don't use car daily, sometimes it might still be needed – where will you park then?
   3. open space or separate rooms? i find open spaces noisy, which makes it impossible to focus on work – this in turn kills innovation.
   4. what's the dressing policy? not everyone's finding working “under a tie” acceptable.
   5. is there obligatory (long) lunch break? it's annoying when employer tells you when and how long you will be eating lunch. especially when you often don't…
   6. ask recruiter “why do YOU like your job?”. nice way of observing if your (potential) future coworker really enjoying work, or “just works here”.
   7. can get support to do any off-time projects? say: extra money for a hardware, a spare computation power at night, green light for open-source contribution, etc…
   8. have time for writing/creating publications? some employers allow to publish interesting materials in magazines. this means +1 for your surname and +1 for company's PR.
   9. have time for preparing conference talks? some employers support presenting skills of they employees during conferences. this means +1 for your surname and +1 for company's PR.
   10. who will you work with? seniors/juniors? any1 known in the industry? the best bet would be to get a job where you are the least experience in the team – this will ensure you to learn a lot! :)
   11. would you like to work with recruiters you just talked with? it is of a critical importance to work with with great ppl, that don't get in the way of innovation.
3. employment:
   1. how much? :)
      1. salary net/gross?
      2. bonus size and how often payed?
      3. tax break?
   2. is work time flexible?
   3. does work include supports, weekends, night shifts, etc… your time is the greatest resource you have – be sure not to waste it.
   4. is work from home possible? how often?
   5. is part time employment possible? money are not the top priority – in a long run, it's all about the time.
   6. can hire as an external contractor? B2B can be beneficial for taxes and when buying HW.
4. trainings:
   1. does employer ensure trainings?
   2. how often? how long? employer should provide at least few days training every year, as a “social minimum”.
   3. can go to a conference? sometimes on-site is the only option, so for instance ACCU-organized conferences are out of scope.
5. work tasks:
   1. what challenges shall i expect at work? if the tasks as too simple, you'll be bored to death…
   2. ask what could be your first 3 tasks (can be examples). what tasks you can get after 3-6 months? this will give you a nice overview on what can you expect on day-to-day basis.
   3. development? how much actual programming there is daily?
   4. software architecture? can you design or at least influence architecture?
   5. (S)CM? DevOps? who does configuration management? can it be influenced, if you see field for improvement?
   6. build management? the same as for SCM/DevOps.
6. project organization:
   1. is the market regulated (eg.: banking, medical devices, etc…)? regulated markets typically means a lot of paper work, waterfall-like processes and very formal approaches to everything. might be what you want, but be sure to make an informed decision here.
   2. how to introduce a change/fix/improvement? how long does it take? after proving this is work it with PoC or a fair discussion, this should be a nobrainer.
   3. how much time is dedicated to finding new solutions and redesigning old ones? many companies do not actually expect any change to come to their project. if so – R U N !
   4. what methodology do you use: SCRUM, RUP, SDLC+, none? are you sure you want to take part in project which main task is to produce documentation and/or meeting minutes?
   5. how do you document project? there are reasonable limits both ways – no documentation usually means no architecture and spaghetti code; tones of documentation usually means “programming in ms-word”. the right choice is probably somewhere in the middle
   6. is project local or multi-site? multi-site is not bad as such, but often means a lot of politics involved in your daily work. on the other hand you can exercise your language skills.
   7. who makes project decisions (which company site/location)? it's all about decision making. be sure your location have something to say.
   8. what is the policy is bug is found is open-source library? it's good to share – otherwise you'll need to maintain your “sneaky patch” forever…
   9. does company maintain any open-source projects or participate in any? again - openness for sharing.
7. technologies:¹⁾
   1. C++? (make sure decent standard version is used!)
   2. Linux?
   3. gcc? clang? what versions?
   4. boost?
   5. other open source libraries?
   6. which (distributed) version control system?
   7. docker?
   8. virtualization?
   9. big-scale/cloud solutions?
   10. what technologies company is proud of (either developing or using)? it tells a lot about who do they target to hire and what environment you can expect.
8. workstations:
   1. is linux installed locally? corporate environments are often abusing windows everywhere – even when it does not fit your job description.
   2. working locally or remotely? working on “very” remote machines may mean lags and latencies – not nice.
   3. what machine is there? will it be reasonable fast to perform your work? if you develop locally loads of CPUs and RAM is what you want! :)
9. toolchain and environment:
   1. is the project greenfield, recent or legacy?
   2. what's the code-base size (in KLOC)? bigger gets exponentially worse in legacy code. small may mean relatively new or redesigned project.
   3. is continuous integration used? what tools are used to implement it? CI is standard nowadays. but note, that having build server does NOT equals to having CI.
   4. is continuous delivery used? what tools are used to implement it? CD is a step towards from CI, needed to minimize human factors. having real CD usually implies good CI.
   5. have automated tests? no automated testing usually means tightly coupled architecture with tons of errors lurking in a code… usually legacy code.
      1. how many tests are there?
      2. how many KLOC for tests vs. KLOC for production? by the rule of thumb – 50:50 is usually nice.
      3. what is code coverage? though the % does not guarantee anything, decent % coverage may suggest ppl are really testing what they are doing.
      4. what types of tests are implemented (UT, MT, IT, ST)? which are automated, which manual?
   6. is there project documentation?
      1. is it up to date?
      2. who's updating it?
      3. how this documentation is done? usually its a good idea to keep it in VCS-friendly format, like LaTeX or asciidoc in the same repo as the code, so that it can be easily updated to track changes in the code.

last but not least, there is one important observation you should make. think about the questions/tasks you were given during the interview. how hard they were for you? were you able to answer all of them straight away or you had to think hard, maybe failed on some? the harder questions were, the better for you. recruiters usually ask about things and skills that are required for a given job. in fact experienced recruiters will often give you harder questions then the job in the end might be, as it is more risk to a company to higher underqualified employee, than to occasionally miss a good one. if you found questions hard, innovative and requiring creative thinking, there is a good chance you'll actually learn a lot there and not get bored. in contrast, if the interview was simple (or even trivial) – this is the way your job will probably look like. still interested? being overqualified for a job is boring on a daily basis and a step back in a long term. if your kung-fu is really the best around, who do you plan to learn from?