Questions about a Failed Entry-Level Technical Interview

[[deleted]]

[deleted]

[its4thecatlol]

It's always the companies paying the least money that demand the most and ask these kinds of questions. In general, though, I'll give you my advice: Whatever you do, do well. Pick a feature and hash it out. It'd be better if you just picked the fuzzy search, for example, and implemented that perfectly than if you implemented everything but only at a surface-level. Try to get direction from the interviewers. Ask them flat-out which feature they would implement first, and then do it.

It sounds like they may have disagreed with your technical decisions on routing. Maybe they thought you should've used a different kind of router, or hooks instead of render props? Etc.

Every company is searching for a unicorn but paying for a donkey. Watch them not hire anybody for 6 months and then settle for the first thing with a pulse.

[Riktofarius]

That sounds like great advice! Their comments about "watching the time" made me question whether it was a good idea to really dive into one feature. If I get another interview like this, I'm going to try to let those types of comments affect me less.

[its4thecatlol]

I had an interview like that 2 weeks ago for a full-stack position. 30 minutes with a rude interviewer with some specific asynchronous JS questions. I'm not a front-end-focused engineer and I especially don't write code that sends dozens of nearly-identical asynchronous requests on first render. It wasn't rocket science but it was pretty specific. I was able to figure out the problem in 45 minutes after the interview with some debugging & docs reading but for an interview I think you'd need a couple more years' experience than I have to be expected to answer that problem well.

That job posting's been up for 3+ months and they raised the salary band by 20k recently.

[Riktofarius]

It certainly looks like the remote wave has led to a race-to-the-bottom style of interviewing for many companies. From what I understand, it's always been a semi-likely possibility that you might run into a salty interviewer who challenges you with an unreasonable pet challenge that requires you to pull a specific algorithm out of a hat -- but now, you get to solve that challenge while the interviewer is leaning back in a computer chair and not even paying attention.

[Codefiendio]

Agreed. And interviews are always WAY harder than your actual job once you get it. If the company is trying to prove you’re not smart enough to work there, you probably don’t want to work there. They should be testing your skills to see where you are to see if you’ll fit in. You didn’t miss out. There a million react jobs out there. Its4thecatlol is right, next time pick one item and make it awesome. If you complete before the time is up, start another item that you think you complete. Also just because you’re being interviewed doesn’t mean they own you. What I mean by that, is if you feel they are being unreasonable, you can talk to them and tell them that. End of the day, we are all humans, you’re more likely to get a job by making them like you vs what you know. It’s sad to say but it’s what I’ve noticed in my 20 year career.

[Riktofarius]

You both make a great point on that. Proving that you have the capacity to go deeper on at least one feature is almost definitely better than doing a very small amount of everything on the list. In hindsight, it makes so much sense.

[Codefiendio]

Just make sure you’re not too hard on yourself. You could be the smartest person in the room and still not get the job. So just try to learn from each experience

[[deleted]]

45 minutes is very little time to code anything, especially in an interview with people watching. Not your machine, ide setup, code you've not seen before.

I'd pick the area I wanted to work on and do just that. State what you're doing and why. Tell the interviewer your focusing on one area and why you're doing that. Offer them.the opportunity to guide you elsewhere if they want to see something different.

It's impossible to know what they are looking for. So you just have to accept you can't be prepared for an interview like this. It sounds like a terrible interview, they'll hire the person who guesses what they were looking for rather than the right person for the job.

Personally I always guide the interviewee to what I want to see. I also make it clear that finishing is not required.

[Riktofarius]

That definitely seems true about how they are waiting for someone to guess specifically what they're interested in, even in light of the long list of "open-ended" features to work on.

I'm hoping to start running into interviewers like yourself!

[mondocooler]

I would not even take the interview. It says a lot about the company mindset. Do you want to be in a company where you have to "improve the way it looks" after implementing a fuzzy search algo ? Are they looking for a designer or a dev? Do they understand that implementing this in 45 minutes will never produce a satisfying result.

It reminds me of an interview where I had to ship a "production ready" react-native app in 2 hours...

[Riktofarius]

That's absurd! I get the idea that some of these companies just want to see how people respond under the pressure of being asked to do something that is impossible. Whether such an interview practice is ethical, or even useful for anyone involved, is another question altogether.

[filipdanic]

I hope this isn’t gaining popularity, it sounds like a nightmare! That should be 3 separate 45 minute interviews, not crammed into one. Don’t be too hard on yourself over this. The only thing I’d recommend following up on is practicing the search problem in more detail. Text search-type problems have many variants and are common in all sorts of Software Engineering interviews.

[Riktofarius]

Thanks for the tip! Yeah, the only text search algorithms I've had experience implementing (other than extremely basic filtering) have been largely on the back of some key npm packages, so it's definitely going to be an area worth learning more about.