If you're promised a call with a startup VP and you get a junior manager instead, hang up!


📰 Update: Beware of Recruiting Spam!

The day after finishing this article, as I was closing out the dossier, I re-read the initial e-mail.

🤦 I had been fooled by a recruiting e-mail from Findem = findem.ai = linkedin.com/company/findeminc (to avoid any confusion). They spoofed the e-mail address of the employer's Vice President of Platform Engineering and had a Calendly account with her photo and the label "intro call".

Now I understand why a software engineer promoted to manager five months before was substituted without notice for what had been sold as a "chat" with a VP from a startup urgently trying to scale its cloud infrastructure.

The manager lied twice, claiming that the VP was sick that day and that he thought someone had informed me. In three weeks and three interviews, she never turned up.

The e-mail was formatted so you'd tap or click the Calendly link and not scroll much farther. The visible link text was the full Calendly URL. They'd customized the identifier portion to include the VP's first name and the company name, making it look real. The actual URL was a tracker, message-cb.findem.ai/t?i=ID4&u=CALENDLY_URL .

Way at the bottom was a link I hadn't noticed, with "Unsubscribe" as its visible link text. The URL was pub.findem.ai/pub/unsubscribe/ID1/ID2/ID3/ID4/CANDIDATE_EMAIL/SPOOFED_EMAIL where each ID is a 16-digit hexadecimal number and ID4 is the same in both URLs.

End of update



The Vice President of Platform Engineering for a consumer electronics startup e-mailed me in early July, 2025. The company's product is not only cloud-based but also cloud-dependent, continuously downloading large files. The company needs to scale a key infrastructure component. As with most consumer electronic devices, demand for the product peaks around Christmas.

First Interview: Where's the VP?

The first faux pas was a bait-and-switch. I'd been contacted by and invited to talk with the VP. When the scheduled day and time came, an unfamiliar manager popped up in Zoom instead. He claimed the VP was sick, and that he thought someone had informed me. (The company had my e-mail address, my phone number, and my LinkedIn username.)

I always look up the people I'll be meeting — their titles, what they studied, what they are passionate about. I get excited when a leader or a peer software engineer has a personal blog, open-source code contributions, even just an article on a company's engineering blog. Conversely, people who interview me know about my work from a concise, one-page résumé and from my GitHub portfolio.

The conversation with the manager was fine, perhaps leaning tepid. He said there would be a coding exercise and then a decision about another interview. I told him I'd be happy to participate as long as the exercise was relevant to the job. I said I'd decline a generic coding exercise, such as re-implementing Quicksort. That's not the sort of programming I do every day, and he would surely find other candidates who are much better at it.

I mused that in 20+ years of working on large relational database clusters, I'd never been given an SQL exercise. (Come to think of it, I did get one PostgreSQL exercise. I taught the interviewer about using table and column aliases to make complex JOIN queries easier to read, and about creating an index in descending order to optimize retrieval of the latest data. He taught me about his company's data model and its evolution. It was an exchange of knowledge.)

I added that in 12 years of working on AWS, I'd never been given a CloudFormation or Terraform infrastructure-as-code exercise, much less something sophisticated like an IAM policy-writing exercise. I've passed AWS's Security - Specialty certification exam three times. That's the one I don't study for. (Privacy is relevant to the kind of data handled by this consumer electronic device, and to the relationships between the users.)

The Infrastructure Engineering Manager assured me that the coding exercise would not be generic. It would be "easy", in fact. A manager who assumes people want something to be easy cannot have much confidence in them. That he said "easy" as if it were something positive tells me he's a manager who hasn't taken time to study human motivation, theories of learning, etc. Promoted in-place on the basis of longevity, is this the kind of manager whom you could rely on for career development?

In case the manager wanted to thoroughly evaluate my programming skills, I saved him a little time by sending links to four specific, short excerpts from my GitHub portfolio, each covering a different language or topic. The portfolio includes a product, mentioned over the years in an industry newsletter, and with real users. The history of bug fixes, feature enhancements, and documentation updates is public.

From analytics data or by the tenor of the questions in the next interview, I can tell whether a hiring manager examined my portfolio. If we accept the (false, especially in the US) premise that every hiring decision is critical and permanent, you'd think the decision would rest on something more informative than a contrived, 60-minute coding exercise.

Second Interview: Generic Code, After All

The company uses CoderPad. Though I'd used CoderPad in the past, I accessed the sandbox site a few days in advance to see what might have changed.

Another unfamiliar person, this time a junior Infrastructure Engineer, appeared. He sent the CoderPad link 4 minutes before the scheduled interview. CoderPad now supports built-in, browser-based videoconferencing. The problem? The sandbox hasn't caught up and doesn't let candidates test their camera, microphone, Web browser, and system permissions. I test my video and audio setup before any important Zoom meeting. The Zoom client provides audio and video previews. At that, less can go wrong because Zoom doesn't rely on a third-party Web browser. No CoderPad video from me, alas.

My would-be colleague dived right in without an opportunity for substantive introductions. Lo and behold, it was a generic coding exercise. I spent some years as a credentialed K-12 math teacher, so I know all about the pattern of hanging contrived scenarios on top of math.

In every company where I've worked, I've been drafted to conduct interviews. I'm very intentional about this. As a former teacher, I possess specific skills for evaluating people. Having administered coding exercises myself, I followed the practice of thinking out loud, to explain what I was doing and why. This interviewer seemed not to care; he just wanted code.

When it came time to optimize my solution, I discussed the improvements I'd like to make. I pointed out that the optimizations couldn't be completed in the 10 minutes remaining. The interviewer suggested that I write pseudocode, as if I had forgotten how to program in the final minutes of the interview! Whether expressed orally, in written English, or in Python, the revisions required careful thought about edge cases. Time pressure and careful thought are incompatible. He brought up time complexity as if it were new to me, when all along I'd been talking about the dilemma of whether to expend computational effort during the data input phase or during the data retrieval phase.

The interviewer invited me to ask questions about the job. By then, we had 1 minute left. When I prepare to interview someone, I write down predicted end times for each question so I can keep track of time and make sure the candidate gets a chance to ask questions at the end. Or, I entertain the candidate's questions at the beginning, using the information discussed to streamline the interview questions. My impression is that this employee was greener in his collaboration skills than he realized.

I completed my optimization and e-mailed it, even though the interviewer had insisted that follow-up work would not be evaluated. To his credit, the manager did consider, and compliment, the result.

Third Interview, Second Thoughts

Almost instantly, a third interview was scheduled, with the manager. This was better-planned. I was invited to select a scenario from my work experience and share the outline in advance.

I received a templated rejection e-mail a week after the third interview. The job was still posted on the company's Web site.

Rejection doesn't bother me, but two things puzzle me about the whole experience:

  1. Who was the elusive Vice President of Platform Engineering? Despite the enthusiasm she'd expressed in her introductory e-mail, she never replied to me, and she never joined an interview. The manager mentioned that the infrastructure team comprises three people, including himself. We're not talking about a big engineering department.

  2. How does the company intend to scale a critical infrastructure component in time for Black Friday (the start of the Christmas sales season), using the complex, high-risk technique they've chosen? In the most optimistic world, the new person could start in mid-August. Presumably, changes are frozen in mid-November, a week before Black Friday. This leaves 3 months for design, development, functional testing, load testing, and deployment/conversion. Work has to start soon.

Yes, I was willing to humor the company by spending time on a generic coding exercise and a scenario-based third interview, but all along I'd been:

  • researching the features of their device and their app,
  • trying to put bounds around usage and computational demand to see what could have caused the resource exhaustion problem they'd encountered (they hadn't found a cause)
  • reading consumer reviews to learn what users liked and what features they were asking for (my theory is that the infrastructure component in question needs to be scaled not only to support high usage but also to permit the addition of new, user-requested features), and
  • checking the latest developments in the field, vis-à-vis the chosen scaling technique.

This "startup" interviews like a big, slow-moving company, but without luxuries like a large engineering staff, vast computational resources, and plenty of time. I think like a startup person, eager to sign a non-disclosure agreement, understand the needs, and propose one or two solutions for the company to accept, adapt, or reject.

Public Clues About the Business

Sometimes it feels like a curse to be a software engineer with an MBA. I see past the marketing slogan, the innovative technology, the beautiful product. I'd like to believe it all, but what do the numbers say, and how did other, similar examples turn out? My opinion is that this company is a moribund startup, one that has been around for years without an obvious "exit".

The company sells its consumer electronic device for just over $130 on Prime Day and Black Friday. I'll assume that the company receives $120 of revenue per unit, after "free" shipping and some returns. (Apparently, returns these days are abandoned and written off, or sold in lots for pennies on the dollar.)

The brand depends on a consumer products review outfit. That site is pay-to-play, demanding "kickbacks" affiliate marketing contributions. Whatever the contribution amount and the share of sales covered, this erodes average revenue per unit.

The product is popular, though not popular enough to merit disassembly videos and bill-of-materials blog posts. Based on FCC filings, the hardware consists of a logic board equivalent to a Raspberry Pi 3B from 2016 (retail price $30; cost unknown, but I'll assume $15, a rule of thumb for electronics being half the retail price) and a medium-size but high-quality display (I can't be sure, but I'll assume a cost of $75 to $100, based on display price lists I found).

The company also sells a large model at 2 to 2½ times the price. Amazon product pages put units "bought in past month" in the hundreds, compared to thousands of the medium-size model.

Though the device is sold in some European countries, product images show a custom power supply and a barrel jack. At least the input is 5 Volts; supporting USB power input might be as simple as changing factory tooling. I didn't get a chance to ask about plans to comply with this European Union requirement.

No subscription is needed, or offered. As long as the user keeps the device plugged in and online (it stops working if it's offline), costs accrue to the company. Each sale creates an obligation to provide:

  • unlimited cloud storage;
  • unlimited data transfer in and out of the cloud provider's network (for users to upload their data, and then for the device to consume the data); and
  • security updates and bug fixes for:
    • the device's firmware,
    • an app, and
    • server-side infrastructure.

There is also customer support, though that seems to receive negative reviews. (Reviews of the device itself are overwhelmingly positive.)

Given the potentially tight unit margin, where is the recurring revenue to support these costly, ongoing obligations?

Had I been chosen, I would have joined because the scaling problem interests me, and because I have the skills to help them solve it. Those factors motivate me more than an elusive financial windfall. In my opinion, there isn't much money there. Is the business model a Ponzi scheme, in which revenue from new device sales covers the cost of servicing devices already sold?

Whether you got the job or not, please share a positive interview experience by commenting on the LinkedIn version of this article!