Inspired by https://www.interviewcake.com/article/python/coding-interview-tips I thought I could make a variant. We’re no longer talking about a coder and an interviewer, we’re talking about a solution provider and their client.
Sometimes you’ll get stuck. Relax. It doesn’t mean you’ve failed. Keep in mind that the client usually cares more about your ability to cleverly poke the problem from a few different angles than your ability to stumble into the correct answer. When hope seems lost, keep poking.
Draw pictures. Don’t waste time trying to think in your head—think on the board. Draw a couple of different test cases. Draw how you would get the desired outcome by manual effort. Then think about translating your approach into product.
Solve a simpler version of the problem. Not sure how to find the 4th most important demographic in the market? Think about how to find the 1st-most-important and see if you can adapt that approach.
Launch a naïve, inefficient solution and optimize it later. Use brute force. Do whatever it takes to get some kind of launch, traction, or engagement.
Think out loud more. Show what you know. Show what you thought might work and why it won’t work. You might realise it actually does work, or a modified version does. Or you might get a hint from the client.
Wait for a hint. Don’t stare at your client expectantly, but do take a brief second to “think”—your client might have already decided to give you a hint and is just waiting to avoid interrupting.
Think about the bounds on time and effort. If you’re not sure if you can optimise your solution, think about it out loud. For example:
- “I have to at least look at all of the items, so I can’t do better than market testing.”
- “The brute force approach is to test all possibilities, which is incredibly lengthy.”
- “So, because the answer will contain n^2n2 items, it follows that I must at least spend that amount of time.”
Thanks to Parker Phinney and Cake Labs. No intent to violate https://www.interviewcake.com/terms-and-conditions
If you are a video algorithm engineer, it’s likely that you spent years at university studying something abstruse in mathematics or particle physics. Or, perhaps, visual/mechanical reproduction systems.
When you take a commercial job working for a video encoding company, I enjoy reading your patent applications. I like seeing your standards-body submissions. It’s great seeing your names in the minutes-of-meeting for boards and committees. Sometimes, I get to meet you and shake your hand.
It’s even better when your submissions for a new video codec are not only accepted, but when they are endorsed and your peers start using the reference encoder components, the reference decoders, and when everyone uses the same videos to test compliance.
What’s hard is that this all takes years. Years! IBCs and NABs come and go, MPEG committees meet and disband, and time passes.
A provable, reference, standard for interoperability. And/or a set of parameters that others can go and innovate with. Products, systems, and even optimised circuits that map your math into personal enjoyment.
Codec is a portmanteau of coder-decoder or, less commonly, compressor-decompressor.
[ https://en.wikipedia.org/wiki/Codec ]
What hurts you, and the industry, is if someone decides there’s “a breakthrough” that is possibly based on a story.
Like, “Adams Platform“:
Investors who believed him ended up $27 million poorer. Despite the huge loss and the failure of the technology to work, no one has ever been prosecuted.
The Adams Platform technology could compress video by a ratio of a thousand to one, Mr Clark said. It could transmit full-screen, broadcast quality video over a standard phone line, he said. It couldn’t.
The claims seemed even more outrageous in the early 2000s, when broadband internet had yet to become the commonplace it is today. The potential seemed unlimited, and Mr Clark excited a huge amount of interest as well as a fair amount of scepticism.
It all amounted to nothing, and the company he floated on the ASX to exploit Adams Platform quickly folded after admitting there was no evidence the technology worked.
And like many others.
Now, if an amateur can download MediaInfo and look at a sample file that has been apparently encoded by a new codec, yet get all the encode parameters from the known codec x264:
[ http://www.videolan.org/developers/x264.html ]
……is it really new?
cabac=1 / ref=4 / deblock=1:-2:0 / analyse=0x3:0x133 / me=tesa / subme=11 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=7 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=1240 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
And if the same amateur can view this video in a standard player, without any decoder component installed, is it really a new codec?
New sounds great: new takes years.