crackerjackmack

In an example. NoopTelemetry would be some type of empty class not dependent on mock (I've used a meta class a singleton in this case, but whichever, could be a module just the same). To test, you'd pass in a mock object to telemetry and check that a both timer_start and timer_stop are both called with the correct function name.

In your main or context, you setup your application with the needed pieces.

  def main():
     context = {'telemetry': StatsClient(....)}
     start(context)

  def start(context):
      algo_5(1, 4, context['telemetry'])

  def algo_5(param1, param2, telemetry=NoopTelemetry):
     telemetry.timer_start('algo_5')
     ret = param1 / param2 ** param2 # whatever
     telemetry.timer_stop('algo_5)
     return ret
  
  def test_start():
    context = {'telemetry': MagicMock()}
    start(context)
    # more testing.

  def test_algo5_math():
    ret = algo5(4, 5)
    assert 78  # maybe?

  def test_algo5_telemetry():
    mm = MagicMock()
    algo5(1, 1, mm)
    assert mm.timer_start.called_with_args(['algo5'])
    assert mm.timer_stop.called_with_args(['algo5'])

Some general advice I've given multiple junior developers over the years, you probably aren't a junior but most likely applicable to the advice you are seeking. These were passed down to me by other developers. Other HN folk will have links to literature but hopefully my advice will give you a precursor.

* testing - write your functions small enough to be readable, but not so small their abstractions are meaningless (because you have to test them all)

* testing - don't reach into your code's modules and mock. Instead use dependency injection with non-testing defaults

* code review - It shouldn't be personal, if it is are you reading it wrong or are they attacking you personally?

* code review - when referencing style complaints ask for reference material. Don't get caught in cyclic-pedantic style war between lead devs.

* code - your code should be environment agnostic, if you have environment/context specific things to do, pass along a environment/configuration dict or make a global config singleton. As long as your code depends on that you can write code more discretely.

* code - personal preference but try to not nest your loops too deeply, when you can use itertools.

* code - if you can help it, try not to mutate dicts/objects in place while in a loop. Makes testing a difficult.

* code - exit early if possible, test for failures instead of nesting your entire function inside a single `if`. Helps identify the bad inputs faster as well.

Above all, remember code isn't perfect. It's a tool to get to an end goal. If you aren't solving for the end goal you aren't solving the right problem. At the end of the day, you are employed to build a product and that product needs to perform it's job. (that isn't a pass to write super shitty code)

edit: formatting

Netbooting isn't new. Insecure netbooting isn't new (ala netboot install USB's per distro). Wrapping it up into a cohesive service is and it's awesome.

Going signed CA wouldn't be hard to do in this case at all, it's just part of the build process actually but only gets you to to a trusted PXE+menu system. After getting into the PXE menu a system could still hijack the upstream kernel/initrd files.

Even freebsd netinstall (aka not limited to linux installers) is just http/ftp without any package signing. The whole ecosystem probably needs to mature some more in regards to verification that won't break downstream projects such as this.

As an interviewer I would be checking first for competence over most other things. The reason is that PHP itself is a landmine language that has grown up organically. I'm not hating on PHP, just stating current state of the language. (Python is full of it's own gotcha's for example)

Knowing the gotcha's of the language is important, but a competent developer also understands patterns and disciplines.

For example, it's often times that DRY is perverted into a framework that obfuscates that actual work being done and makes not only the code untestable but also debugging a nightmare. It'd okay to repeat yourself as long as it provides clarity over obfuscation. But when is too much repeating too much? How would you fix it? Refactor? Rewrite? This perversion isn't exclusive to PHP at all.

On the PHP front, in addition to frantzmiccoli's great questions I would add the following: - have you installed and used xdebug? - you ever done code profiling with xhprof ?