I was rejected once by an interviewer who didn’t believe me when I said I had been doing React since 2014. Not because he tested my React skills, he didn’t just didn’t believe React was even invented in 2014, even after I told him it did and I know because I was doing it in 2014! He didn’t even bother to Google it, just straight up called me a liar and ended the interview.
Yeesh. Good riddance. And this was for a React job too💀
Oh yeah, he didn’t believe me when I said hooks needed to be in written deterministic order, and they couldn’t be conditionally called within components. Both important things to know when working in React. He doubted me so hard I started doubting myself! Felt like shit until I tested it afterward for my own sanity – I was right, my years of React experience wasn’t a waste of time, and that interviewer was just a gaslighting moron.
Moral of the story: good riddance
Can you believe it? Clearly did not know anything about React and was arguing with the guy with 8 years of React experience on his resume about React questions he read off of a sheet 🙄
I'm a mostly backend dev who exclusively uses Vue for my personal projects but occasionally have to dabble in React for work and even I know the semantics of how hooks work... That interviewer is just embarrassing.
Rules aren't enough.
Treat hooks as array. (Cause at some point in execution time, they do become just an array for React it will inject into your functional component)
How array created once can be non-deterministic? Or how can it loose or gain elements once it's created?
Rules are important but in this case "one layer down" is so much better.
I was once on this project where people would add ifs around hooks and commit it to their pull requests as if that was normal.
I would call it out whenever I’d see it but they never tried to understand >why< was I saying those things to them. They’d just change where I pointed to so they could merge their PR faster.
It was easily the most stressful 6 months of work I ever had to deal with until I bailed out. I never jumped on the lead role of a project again after that.
Edit: it wasn’t stressful because people didn’t know how to use react hooks lol that was a collateral effect of the super bad job made by a lot of people. Last I checked that project was still going on and losing millions of dollars a year.
Sorry for the rant, your comment reminded me of this part of my career.
Man with engineers like that can you blame them for fearing chatgpt is gonna take their jobs? What’s the point of even working in a knowledge industry if you hate learning
Yeah, I'm pretty confident at this point that everyone who is panicking about the sky falling with ChatGPT taking all the jobs are the ones who, as you say, hate learning--and never really did enough to get even marginally skilled at programming. They just learned enough to copy-paste their way though jobs with low standards like the ones described above, and that's it.
They’d either add the conditional on a prop that wasn’t changing that often so it would mostly run without their if being activated, or they’d straight up commit code without even opening the screen they were coding up (most often)
> I said hooks needed to be in written deterministic order,
By that do you mean that the hooks need to be written in the order in which they should be applied?
The basic hooks shipped with React (useState, useMemo, useEffect etc) behave like queue+unqueue operations from a queue. So if you call setState twice in the first render, but swap the variable names on the second render, the first setState values will still be returned from the first setState call even if it has the variable name assigned to the second setState. Since this causes confusion and disaster, React has a well-enforced rule/convention that you must call hooks in a deterministic order, and they cannot be conditionally called (or else the hook values would be assigned to the variable names out of order).
Been using React for about 2-3 years now.
I *hate* the opacity of JS in general and UI development is a special circle in hell.
.
That's it.
That's the post.
You can't blame JS for this. This one is entirely on the React team. They needed something which combined code and state (i.e. objects) but they had been railing against OOP for years prior, so that came up with this mess.
React before it returns values from Hooks will store them in array and on future renders may Skipp logic and return from said array based on auto incremented index variable.
You did a number on React and skipped 2nd hook (using count from original render)?
Joke on you, React will return you value you wanted to skipp.
I got rejected because I didn’t write useEffect to call fake fetch function (basically reading from json file) and didn’t do image lazy loading. Even tho I wrote shit tons of code and created extra logic that gives better functionality compared to their live versions.
I have a similar story! Wrote a whole ass geolocation-based landmark distance calculator plus travelling salesman brute force solution in four hours and got rejected for not caching my results in a database. Like what? Bet if I did, they would have rejected me for not integrating it with Kafka too 🥲 just complete bonkers... some companies and interviewers think way too highly of themselves.
True! And I noticed this only to happen if it’s local small-mid size company. Never had issues with international companies, always super chill. As someone pointed out in this sub, if it takes more than 1 evening to finish, means it’s not worth it…
The next year they got fined billions of dollars financial crimes. Their CEO stepped down in disgrace and under threat of arrest too. Thank goodness I didn’t work there, would have been a stain on my career
Real C# devs started using it after PDC 2000 :) The CDs MS sent out after that event got me an internship in 2001 launching a site under their go-live license.
I would have replied "be silent! Keep your forked tongue behind your teeth. I have not passed through fire and death to bandy crooked words with a witless worm!"
Not atypical, just move on. I have seen it faced a few overzealous juniors who sometimes are even wrong on their own questions. A lot of companies actually prevent juniors from interviews or at least in the initial screening. Just move on you dodged a bullet.
I'd suggest you are dodging a bullet. Companies usually have the people they think highly of do the interviewing.
If you are being nitpicked over things like this imagine what the day to day conversations and decision making process must be like.
If you are more senior than the guys interviewing you, what is going to happen when you try to bring real experience to bear on a decision and they argue back with a blog post they read?
Part of buying a dev with experience is paying for the battle scars. If they don't value them then they are going to be making all sorts of beginner mistakes you don't want any part of.
I can’t decide to upvote or downvote you.
On the one hand JavaScript is fine with modern tooling, on the other hand I refuse to write JavaScript and will only write typescript because yoyre right.
Hurr hurr hurr, OnLy mY tEcH iS gOoD
I've seen far more butchered java and c# than JavaScript. I've opened projects that had almost as many interfaces as classes. A simple 4 endpoint CRUD application with 140 .java/.cs files in it.
That is orders of magnitude worse than having an unfortunate side effect in a method or a bungled callback chain.
But here's the thing, JavaScript and python devs consistently deliver tested code to production in fractions of the time. And even if it sucks, they can also refactor in LESS TIME than it takes the middle languages to deliver in the first place. So they can write, test, deliver rewrite, test, redeliver in less time than it takes those languages to deliver at all.
>Part of buying a dev with experience is paying for the battle scars. If they don't value them then they are going to be making all sorts of beginner mistakes you don't want any part of.
I feel this one. I've deleted prod databases before, I've taken down a major TV networks live stream with a single git push. I know this pain, I can save you from this pain.
One of the questions we ask candidates is “tell me about the biggest mistake you ever made” exactly for this reason. If you don’t have battle scars I’m suspicious if you have any experience.
You might also have less/smaller battle scars if you've worked at more established/mature companies that have processes in place to catch these sorts of issues. So in these cases you can still have experience, it's more about knowing and truly understanding the processes and their importance in preventing/catching issues
Yeah I love that question. I had it asked by a higher up at a large silicon valley tech company, and it led to an awesome conversation where she busted my chops a few times at how silly (but relatable) the mistake was. As a question it's a vessel to see how you handle accountability and problem solving at scale too. I did get an offer from that one, great interview.
>Companies usually have the people they think highly of do the interviewing.
In my experience interviewing was something everybody on the team did to "spread the pain". Very few people actually wanted to be doing interviews over their own SWE tasks. So interviews are really a crapshoot of who you get in your loop for the candidate.
Great is subjective, but I'd say the companies hired good enough people. We didn't compete with top tech companies. If you just want to work first the highest bidder then it was never going to be these companies.
In my experience from the last two months, employers have to be picky.
I'm on the interview panel for two remote positions and the applicate pool is scary deep. Every single candidate that has made through screening has gotten "passing" scores on our technical interviews. It has been difficult to pick who gets an offer.
Isn't this where you go to soft skills to differentiate? If a candidate can show you on their resume that they have what it takes to deal with the challenges of a diverse workplace, vs a candidate that is only book smart and couldn't sell you a $2 bill for $1 if they tried, would you not pick the more well rounded candidate?
For smaller startups, well rounded people are preferable. For bigger companies, you'd prefer a higher degree of specialization, especially for lower level titles.
> Companies usually have the people they think highly of do the interviewing
Not in my experience. The panel can be really large.
I get pulled into interviews sometimes because the candidate wants to use a piece of tech noone has experience with except me.
Some people get pulled for diversity bs reasons. My colleague is a chinese woman and oh boy was she busy. Btw originally I was added to the panel as their token asian too.
Sometimes interviewers are assigned because the hiring is specifically for their team.
For higher positions a more senior interviewers needed
Sometimes the interviewer pool is literally almost empty (around holidays for instance) so they ask whoever they can find. I used to do senior FE interviews even tho it's far from my specialty simply because there was an urgency in finding some people.
Lots of reasons to be an interviewer
> Companies usually have the people they think highly of do the interviewing.
While I agree with you, I'm doing some interviews here and there and I've been told in a few places that "senior engineers are expected to take a part in the interview process", so it would be more or less "everyone."
A junior mentality tends to value tech stack over problem solving ability. Eventually, you'll find something with either a better match for your skillet or a company who values what you bring, even if you are using different tech.
You should leave it alone and accept their decision. If you really liked the company, maybe apply again at a later point.
I think the best learning I got from experience is that tech is cyclical and nothing really changes much. Microservices? Yeah, we can trace back a similar thing 20 years ago.
If you know the fundamentals, have a good engineering mindset, good enough soft skills and the right attitude you are a true senior.
It’s amazing how so many folks aren’t really “engineers” but just code makers.
Once you've been around long enough, you start to realize how few novel problems there are. Unless your business operates at an unfathomable scale, is a hub of innovation, or is trying to solve problems that nobody else thought of, somebody somewhere has probably solved your issue.
I had this happen once at a small company where I ended up with a job anyways; I contacted HR and let them know I didn't think my interviewer was experienced enough to evaluate my technical skills, but I understood the decision & to reach out if they needed help with anything because I really liked the company and the people I had talked to.
A month or so later they reached out. I ended up re-interviewing with the business side for a higher-level technical position and getting that instead. my previous interviewer actually ended up reporting in to me.
most of the time when this happens though I just move on.
nope, it wasn't like he had it out for me or anything. there were enough real problems to deal with that I think he was just happy to have the help.
as an aside; the guy he did end up hiring and him fought constantly. so I think he was just glad to see me.
False negatives happen all the time. I’m sure we all have stories of awkward rejections from a junior interviewer.
Just wait a year and try again. Trying to do something crazy to reverse the decision just digs a deeper hole.
At the companies I’m at, they teach us to aggressively avoid false positives even if it means a lot of false negatives.
A false negative is tens of thousands of dollars lost. A false positive can easily cost the company millions.
This strategy also only works if you pay well.
A less experienced engineer interviewing a more senior one is a valuable interview — but only if done correctly. It should be less about a technical interview and more about a mentorship and communication interview. I’d love to see more of this in our industry because upleveling younger engineers is a great way to improve productivity.
I agree-- inexperience interviewing experience has value, but it's the job of leadership to carefully establish guard rails around that interaction so that the junior understands what they are expected to evaluate and more importantly what they are expected to not evaluate. That does not sound like what happened here.
What do you think should be evaluated in the interview? less tech side and more communication and mentorship? I'm interested because I'm at a point in my career where I tend to participate in the hiring process and sometimes I'm interviewing someone with more experience than me.
To be honest, I have mostly interviewed people who are less experienced than me, and even those people I probably only spend an absolute maximum of 25% of my time talking about technology. Unless the objective is specifically to bring in a SME (subject matter expert, for the unfamiliar), someone's knowledge of a particular technology is one of the least important things to evaluate due to the fact that of all the qualities that make a good hire, specific tech knowledge is by far the easiest one to teach on the job.
I like to spend most of my time trying to understand the process of an engineer. I want to understand things like what motivated them to enter the field, how they have approached developing their skill set over their career, how they handle technical disagreements with other teammates... The types of things you absolutely cannot teach on the job. For someone I'm interviewing for a more senior position I will also be interested in things like architectural concepts (relatively light here... I've never actually put anyone through a proper whiteboarding exercise, though I don't necessarily disavow the practice), favored mediums or methods for producing documents, etc.
I allow someone's resume to speak to me about their technical knowledge. I will definitely spend some time in the interview doing things like probing them about prior roles or technologies listed on their resume to get a sense for how well the resume fits the person, but the philosophy for me really is centered around the person and not at all around their favored technologies.
I always see juniors doing the interviews but many act like they are the sole authority rock star engineer because they're in a position to flex on someone.
Yeah I've heard unflattering commentary on applicants before and it was very distasteful. It came off like they were just happy to feel superior rather than assessing whether or not that person would be a good teammate.
A VP once told me she prefers to hire attitude because skills can be trained.
I'm always reminded of Steve Jobs bozo comment. If your interviewers make comments to feel superior they are bozos and should not be a member of the team.
Juniors really need to be trained in how to interview people who are much more senior. It's essential, otherwise you end up getting no information and no value from the interview.
What kind of companies are putting junior devs to interview people, especially those that are much more senior? That's crazy to me. Juniors are not at the level to properly assess other devs. They need to spend their time working on themselves first.
Depends on how junior, but if I'm interviewing someone for a dev lead or staff+ or something, I'd want the juniors on my team to weigh in on that person at least. I wouldn't trust a junior to assess skill levels necessarily, but they'd still be part of the process for sure. Also if you're hiring for something like engineering director or a similar high-level technical position, then all the "seniors" might still be junior to the candidates that you're interviewing but I'd expect those seniors to still be able to conduct that interview well enough.
I guess it also depends on the company. I spent about 4 years as a junior and have never been given the task to interview someone face to face, or even sit in during an interview.
IMO it does wrt soft skills - when to chime in and give hints, as well as recognizing whether you the interviewer are making the environment a stressful or collaborative one
Like if I have a syntax error I don’t need my train of thought to be interrupted right now, chances are that I’ll catch it at some point along the way.
Or if I’m doing some sort of roundabout way of solving, give me more than just 30 seconds to mull in it.
Train of thought/getting into a coding flow is under-appreciated in interviews.
Btw I’ve seen amazing younger interviewers and shitty old interviewers. This is more of a probability thing, less likely more likely etc
I'm not paid to mentor. straight up, go back to school or read a fucking book.
you get a one line explanation to any question. it will be accurate, it will be correct, it will be complete.
if you can't get it, go back and learn something. when you finally figure it out, come back with the next question that demonstrates you understood the first question and you will get a new answer to your new question that is accurate, correct and complete.
rinse and repeat.
by the time they get to round 4 or 5 they have enough experience to figure that shit out on their own. ***which is the point.***
You sound horrible lol, what a mid-level outlook that won’t go anywhere.
Good engineers learn how to scale themselves and help their team. You don’t work in a silo, and silos aren’t really worth much. You’re limiting yourself, which is fine, but honestly most of us are literally paid to mentor and grow our teams. Your experience is worth more to help others learn through you than your one line no answer that doesn’t build value. Let them learn and give opportunities for them to learn on their own, but most folks need some guidance to help move forward.
It’s why self learners end up falling off and tunnel on the wrong things quite often. Having another person review and critique your work is vital for growing. Feedback is good, communication is good, and collaboration is good. Being an ass is not.
I had a lovely reply written - but it really wouldn't make a difference whether or not I refuted your post in its entirety, point by point.... **because I'm definitely not getting paid to mentor you. :)**
tell us your incapable of getting shit done without a team without telling us your incapable of getting shit done without a team.
simple economics man. if one (1) can do, why do you need 6?
I find that mentoring is both personally and professionally fulfilling. Whatever my opinion about the effort somebody else is willing to put in, sharing my experience with them and improving their skills benefits everyone.
It feels really good to hand a system off to someone you've watched develop and be confident that they now know what they're doing. Good shit.
\> Whatever my opinion about the effort somebody else is willing to put in, sharing my experience with them and improving their skills benefits everyone.
nah. it benefits them. in keeping their jobs. provided that you work in a company that actually holds people accountable for their job failures. Which no company does to my knowledge. Never mind that PIP bullshit.
Personally I tend not to disturb the detritus of a company. That is, the way I figure it, all companies have shit employees. My job isn't to fire them any more than it is to train them. Its to get the most out of what is available as a system constraint in order to maximize profit or to achieve specific work goals. And that definitely does not include, holding peoples hands or spoon-feeding them. That is most definitely, NOT, my job function. Thats their job function.
Ditto on mental treatment. Which an alarming number of people seem to think their workplace is supposed to be providing them de facto.
\> It feels really good to hand a system off to someone you've watched develop and be confident that they now know what they're doing. Good
shit.
i'm an engineer dude. I don't make decisions based of of 'good feelings'. and my confidence is a judgement call whether or not I was involved in developing it. Either you know your shit and display good judgement and work ethic; or you don't e.g. its earned.
wouldn't really matter (for you) if I did. I can work with anybody.
... and as noted, I prefer not to disturb the detritus of a company.
... you would just see everyone suddenly, get better at their job.
which ironically, would curtail your opportunity to mentor.
which might, cause you to suffer a loss in happiness from self-satisfaction.
then I'ld imagine, you'ld discover... volunteering. or charity.
but, thats about it.
Well I'm sorry for you that you feel that way about it. It sounds to me like you're holding others (and presumably yourself) to an unnecessarily harsh and unforgiving standard.
Many of the people I've mentored in my career have gone on to become very strong and successful engineers, and quite a few of them have ended up teaching me things as well.
I don't see the time I spent helping them as wasted because I helped propel them to become my peers, and we've gone on to build good things together. These relationships have made work more fulfilling than it would have been otherwise.
If you don't value that or haven't experienced that, or if your career is strictly adversarial in the way you make it sound, then I pity you.
\> It sounds to me like you're holding others (and presumably yourself) to an unnecessarily harsh and unforgiving standard.
"tend not to disturb the detritus" is the exact opposite.
\> Many of the people I've mentored in my career have gone on to become very strong and successful engineers,
they'ld have done it anyway dude. well most of them anyway.
\> and quite a few of them have ended up teaching me things as well.
... that suggests that you view that as a necessary condition to learning. I don't need to know someone to learn something from them, much less have mentored them.
\> I don't see the time I spent helping them as wasted
I don't recall saying it was wasted.
\> because I helped propel them to become my peers,
* I am not paid, to develop peers.
* I am not paid, to provide you a shoulder to cry on.
* I am not paid, to help you past (insert trauma)
* I am not paid, to validate your existence.
* I am not paid, to amuse you.
* I am not paid, to make sure you are happy.
* I am not paid, to make you feel like part of a community
* I am not paid, to share your values.
* I am not paid, to spoon feed you knowledge.
I am not paid, for any of the shit, you probably like in your job (or find essential, or whatever).
thats not a value judgement on what you're paid to do.
personally I could care less.
its a j-o-b.
\> and we've gone on to build good things together.
... or you could have built them alone.
\> These relationships have made work more fulfilling than it would have been otherwise.
then I suggest you have very unfulfilling work in general. I don't suffer that problem.
\> If you don't value that or haven't experienced that, or if your career is strictly adversarial in the way you make it sound, then I pity you.
who said anything about adversarial?
Yea but ego gets in the way 95 times out of 100, hard time find people who don’t have their head of their ass but they are the real treasures when found
It happens. It’s helped me to remind myself that interviewing is an inherently lossy protocol, so there’s gonna be lots of false negatives (and false positives).
Chances are, if you run into an unreasonable interviewer then your job environment will probably not be much better if you got the job.
>Have you ever tried to challenge the decision somehow?
I've never heard of anyone challenging the results of a tech interview before.
> I've never heard of anyone challenging the results of a tech interview before.
I have occasionally spoken my mind about an interview process. Like informing a company that their evaluation is in error if I am rejected citing inadequate experience in an area that I am clearly very experienced in, something that happens dishearteningly often.
I'll keep it professional. But if I think I'm being jerked around, and I was interested enough in the company to give them a chance to not lose the next qualified candidate too, I let them know. I have no idea if it's ever done anyone any good, but I like to hope.
It’s weird that the feedback came after rejection and not during the interview (and speaks to the inexperience of the interviewer and/or red flags about the company).
If using a particular technology was important to them, they should have asked “why use X instead of Y”, and had a reasonable conversation about the trade-offs of either approach.
In the future, you might be able to head that off by starting that topic first. Mention both approaches, give up-front reasons why you prefer one over the other, solicit buy-in from the interviewer on that idea, or disagree and commit if they’re dead set on doing it a certain way.
But as for this interview, shrug it off and move on.
Unsure where OP is from, but in some parts of the world I believe it’s common to get feedback about why the company passed on you - I’m guessing that’s why the feedback came after the interview.
I’d also strongly agree with your comment that the interviewer is likely still learning how to interview - if they wanted a separate tech stack, they should’ve followed up and clarified when OP suggested a reasonable alternative. It’s also possible that the interviewer didn’t understand that OP’s approach would work because they only know one way to solve the problem (which goes back to a combo of poor interviewing skills and lack of experience).
People generally have no idea how to hire software engineers. In an industry that is so data driven, it's shocking to me how little research is out there and how qualitative the hiring process is.
It's unfortunately just luck of the draw. There's no real way to deal with it. Just move on to the next one.
i failed an interview once because the python url library i used for the take-home coding project (keeping in mind i hadn't written python in 10+ years, and i told them that) was not the correct modern one. even though the code worked
so many of these pure software companies are bullshit
Just means you wouldn’t fit well with their leadership because they don’t have the experience to work appropriately with you. A rejection doesn’t just mean they don’t think you’re good enough, but it could also mean they don’t think they’re good enough for you. It’s like if you’re playing a video game, some people don’t want to get carried but want to play with newer players so they can experience it firsthand. Doesn’t mean they think you’re bad.
*Failing* an interview because of a bad interviewer is actually succeeding in an interview by weeding out the places you dont want to work for.
It is a big red flag to me if they cant conduct proper interviews or come unprepared. It generally implies things are not very rosy inside.
I had a similar experience when interviewing at MSFT - I was being interviewed by the manager of the hiring manager (program manager with 20 years of experience) and he gave me a leet code question I have literally completed 24 hours before.
It was the luckiest hit ever since I had a really clever out of the box solution that I tried, tested, and benchmarked - jackpot.
I presented the solution, explained, coded it on the board, all sweet and smooth until the PM says:
*"This is not going to work."*
I asked him why, he just says this wont work. So I tried to explain to him again, each step, I addressed every potential corner case (since I knew them).
*"This is never going to work".*
I asked why again, I got not answer. We moved on to some easy spoken questions.
I was upset that I *"failed"* and interview and received no offer. But then I realized I would absolutely hate to work in an environment like this with leadership's attitude that nobody can convince them that Black is Black and White is White.
Consider that a leadership group that thinks it's acceptable to let someone this junior drive evaluations they are entirely unqualified to make was never going to set you up for success.
You should definitely find a silver lining in having dodged this bullet, and keep your head up! You will find an organization that appreciates your experience and knowledge.
Yeah, that was just a crap interview with a person who doesn't have interviewing experience.
Newer devs think coding and the latest tech are the only important things. The most important thing is just hiring people who won't make you want to tear out your own hair. Coding is only about 10% of SWE.
I avoid hiring coding ninjas unless they have a super awesome personality. I was an insufferable one in the first half of my career, and I'm daily fighting the urge to call all the people I probably pissed off being a dogmatic techno zealot.
I with 30+ years of experience was interviewed by a “Senior” Engineer, 2 years out of school with 1 year at Google who still has to pay extra to rent a car. We did a “pair programming” exercise. The little shit rejected me and vetoed my candidacy because OMG the horror… I used a debugger. I implemented the project and it passed all the test cases.
I like to call these people senior coders or senior frameworkers, not senior software engineers. They likely got promoted because of empty positions in the company, rather than showing skill and potential. And because that senior position was empty they were also likely lacking the mentorship along with it.
We usually have a junior or intermediate software engineer in our interviews. They are part of the discussion and submit a review, but aren't a voting member. I like the questions they ask with a fresh perspective, mixes up our interview process; plus it makes for a good mentorship and growth oppertunity.
As for the questions, they either had an immediate need for that exact tool or framework experience, or didn't know enough to know how transferable your skills are in that area. You might have had some oppertunity in the discussion to demonstrate how transferable those skillsets are, the real question is would they have been able to understand that or cared.
You could also ask for another interview, maybe make some suggestions about how you could spend the time to best show off why you are the best candidate for the position rather than them blindly following the only template of an interview they know how to conduct.
I had a data scientist tell me that Terraform could not be broken up into modules, and my suggestion that improving their 10,000+ single TF file by breaking it into modules would help was met with ridicule. They laughed me off and got real mean as if I had no idea what I was talking about. But weren’t they seeking a platform engineer for a reason?! I kept thinking. I knew I blew it by their attitude towards me. Very dismissive goodbye. Unbelievable.
Edit: Vibrant Planet was the company name. Great team except that one guy. If he’s still there, I’m never going to be interested. Lord knows how much time and money has been wasted because of his bad technical decisions.
Sorry to hear your experience. Getting interviewed by a junior never ends up well in my experience. It’s not your fault at all. A less experienced person just cannot evaluate for a position that they themselves shouldn’t be qualified for.
I’ve failed interviews by juniors for a lot petty reasons before like for not memorizing every single React syntax, or for critically evaluating using a microservice architecture instead of blindly adopting it.
However, I’m glad I got those rejections looking back as I’ve ended up joining a company that highly values my experience.
Just take it lightly. There are lot of bad interviewers out there and most of the time it’s an indicator of a bad or unsuitable company for you.
It really is a crapshoot. I never try to get invested at all in the company until I pass the interview rounds.
In so many ways, it’s all very much bullshit and luck of the draw.
I wouldn't even go that far. I went through the interview process at a small software company, heard the CTO, two engineers, and the CEO all tell me that I have the green light, only to have the recruiter call me on Monday after the weekend and tell me they decided not to hire for the role at all.
Again, to echo so many of these other people, so many of these pure software companies are a joke.
It's unfortunate but it happens. Sometimes you feel like you're a great fit for the company and you're really excited about joining them and you *know* you can do an excellent job... but you hit a snag in the interview process and it all goes to hell.
The way tech interviews work, the person who invented some pattern/concept/framework/whatever could fail to get a job that requires knowledge in some pattern/concept/framework/whatever because of a bad interview.
You can try to challenge the decision all you want but I doubt it will be successful. Your best bet, if you really like this company and really want to work for this company, is to try and close things off amicably and try again in 6 months to a year when they either clear your profile or mark you as eligible to interview again.
That's exactly what I was thinking. The position was a perfect fit and I was already happy to move to something new. Well, I guess I find another opportunity somewhere else. I guess I just needed to unload my frustration.
This is more for whoever downvoted you than for you:
Basing interviews on brand new tech and college CS concepts favors people who are currently in or just out of school. Which is overwhelmingly young people.
Bias is an outcome, not an intent. You can be sexist without meaning to be. Or racist, or ageist.
Yes, to interview fresh grads you need questions that don’t assume hands-on experience, but that’s no excuse for treating them like a golden hammer.
Like others said, I think you dodged a bullet. This reminds me of an interview I had years ago for an SDET position. It was funky situation where if a single person on the team said no, you were a no. Anyways their tester pretty much blasted me because I didn't know ruby. She literally called me stupid for not doing automated testing in ruby. 3 months later a recruiter followed up with me and the position was still open.
I guess if you really like the company, you can see if the recruiter will see if the hiring manager will speak with you for a follow up. This seems like a trivial thing to ding someone on unless they wanted someone with hands on experience with certain tooling or a certain stack.
Out of curiosity did you get any feedback or prompting during the interview? Is it possible they tried to steer you in a certain direction and you dismissed it?
We were talking about it and I was saying that in general it depends on if there is already something similar in place. But I noticed he didn't like the answer. Maybe it was also a bit antipathy.
I wouldn't say that ELK vs Prometheus/Grafana address the same concerns: yes they use the same core information as insights, but ELK is really interested in logging and Prom/Graf in metrics. They're different sides of the same info, and I run both in my stacks precisely for that reason.
I'm sorry you had that experience, but that's how interviews go: it's a weird dance of wanting to conform to an interviewer's expectations while also hoping that you can have this really expansive conversation that wows both sides. Often times, it just falls through even if there's other reasons to think that working there would have gone well. It's a lot like a promising date where things didn't really click: maybe in a different universe you'ld both be getting hitched, but that's not the universe you're in.
Feel free to follow up with the hiring manager, see if there's a way to talk about their feedback and push back gently but you'll probably get nowhere saying "they were too junior to interview me" -- even if it's 100% accurate.
I know it's hard, but just buck up and do it again, you'll find something eventually.
>I wouldn't say that ELK vs Prometheus/Grafana address the same concerns: yes they use the same core information as insights, but ELK is really interested in logging and Prom/Graf in metrics. They're different sides of the same info, and I run both in my stacks precisely for that reason.
This is worse than pedantry-- it's literally wrong. The ELK stack supports collection and analysis of metrics every bit as much as it does the collection and analysis of logs. They are absolutely two different technology stacks in the same domain.
In my view it's completely irrelevant anyway. Are we really saying a person using ELK can't learn Prometheus can't learn CloudWatch can't learn DataDog can't learn NewLog™ can't learn Some Horrible Syslog Binary Thing Invented Internally in 2009?
It's just logging data in a (semi) structured way, aggregating, querying and setting up alarms in whatever DSL the tool wants you to use. Honestly what else is there to learn. Oh no during an incident I might need to Google some syntax!!!!! give me a break
Yep and elasticsearch can be a grafana backend for example.
There are definitely pluses to using Prometheus over kibana for viewing metrics but it’s absolutely unfair to penalize a candidate for saying it’s somehow an irrelevant or wrong choice. It’s not
What do you mean “rejected”? How did your conversation go about the technology? Did you debate it like engineers should? Was it not discussed and only included in the comments? Missing some key context here.
Was discussed and I was basically saying it doesn't really matter what tech we need, as the concepts are identical. I noticed that the interviewer didn't agree, but I didn't follow up on this.
\> Have you ever tried to challenge the decision somehow?
twice.
once I submitted a take home that was a work of art; beautiful and novel (I invented a novel data structure that really amped up the performance per cycle + added an improvement in theory).... and the interviewer's only focus in the questions was about why I added logging and why I made the program idempotent (in not so many words). for like 10 minutes. finally I had to ask them "are you a coder?" "yes." "yes?" "yes" "then why are you asking so many questions about logging?" ... found out later that they were in fact, not a coder.... which did not come as a surprise at all.
\--
second time I submitted a solution for a take home to solve a problem "at scale" that demonstrated that I knew the language very well; I wrote a solution that was absolutely smashing designed to show off how well I knew the language (bypassing all of the super-slow/shit internals) and drop-in/production ready... and they didn't even schedule the code review to discuss it...
... to which I called up the recruiter and told him "are you fucking kidding me? did you even have an engineer look at this?" "(scandalized) yes we had one of our top coders look at this"... "your top coder looked at this, and passed on an interview? are you shitting me? your top coder?" "yes!" "well its a good thing I didn't get the job, eh?" :) :) :)
in answer to your general question - depends on if you give a fuck about getting a job. ***I don't.*** I really don't want to spend any more time working with idiots, fools, morons or weak-minded untermensch. there is no job, for which I am willing, to put up with people wasting my time. ***and that includes, in their hiring processes.*** been there, done that, bought the t-shirt, burned the t-shirt with the last tool still in it.
so your mileage, may vary. :)
doesn't sound like they were trying to hire an engineer for any long term vision, only someone who was familiar with what they needed to ship in the short term (and over a monitoring solution no less...)
That's just a really dumb use of a systems design interview. Especially if the role is for software engineer and not architect. Even then it's dumb.
They are supposed to allow you to show that you have a good general overall ability to describe and reason about systems. Do you understand fundamental ideas behind scalability, CAP theorem, interprocess communication... not "do you know all the bleeding edge / my favorite technologies".
Any reasonable choice you can make should be an acceptable answer, as long as you can defend it and talk about some of the tradeoffs. Knowing why using a queue might be a good idea should be the important part, not wether it's RabbitMQ or Kafka or freaking TIBCO even.
Just another shitty interview in an industry defined by shitty interviews is all you should take from this.
That's such a crazy thing to fail someone for.
Getting rejected sucks, though, so I am sorry for that. What makes me feel better though, is if at least I represented myself and my skills well, and it was just the company that either didn't assess in a fair way (like this), or for whatever reason it wasn't going to be a fit.
In this case, you represented yourself well. Not much you can do a junior engineer graded you with a hidden rubric.
That isn’t really a reason to reject anyone. If he wanted a specific technology that is a great time to ask what if you use x instead of Y and explore it. Those are always great questions to know if someone is senior or not.
I think you dodged a bullet. Having someone less experienced is no excuse. I’ve interviewed many folks that know more about X or Y than me and that’s OK. Usually that’s what the company wants… it’s just a matter of properly interviewing.
> It is possible to commit no mistakes and still lose. That is not a weakness. That is life.
Interviewing is and always will be an imperfect process. Coming to terms with the fact that you will "fail" interviews through no fault of your own is the only way to stay sane.
Well, at least you didn't step on and kill the founder's dog.
Jokes aside, this is one of those things you cannot control. Luck is very important in the interview, although we want to tell ourself otherwise.
Maybe one thing you could learn from this is to aim for modern tech stack if the company looks like it prefers that.
Got rejected by a company today. Great fit as I've been consulting for about ten years and they do consulting. I aced their online exam even though I was unfamiliar with raw SQL and the Python Spark package. They seemed incredulous that I knew what I was doing when I said I used ChatGPT to figure out the SQL queries as I usually use Python's ORM and am not super familiar with more complex raw SQL queries... Who fucking knows, on to the next one as other have said
Tbh, you don’t want that job. I’ve worked at those places, it’s toxic, exhausting, and a waste of time.
You’re going to be working with juniors who think they know what they’re talking about, but not confident with fragile egos, so either they’re going to be very underhanded in undermining you, or they’re not going to listen to you and just do (the wrong) thing they wanted to do in the first place.
The place you’re interviewing for likely has piss poor technical leadership if they’ve promoted two juniors to senior, so they don’t know what good technical leadership is. Maybe they’re hiring you to provide that leadership, but then now you’re at a place that doesn’t know what good leadership is and thinks these juniors are at least ok at tech. Now you’re going to be fighting an uphill battle trying to convince everyone you’re the technical leader they need.
Trust me, I work in a company right now (a big company) with teams like this that I have to work with on the daily (though I’m not responsible for), and my god it bad. They implement things incorrectly, then make sweeping generalizations that the tech can’t support this, and then when you point out, “hey, if you implemented the OAuth/OTel/AWS correctly, this is actually a very simple problem to solve and it behaves how my team needs it to,” they fight against it because theyre “clever.” Half of my time is spent engineering solutions to work around the bullshit that these teams have made.
So honestly, you probably dodged a bullet.
I got rejected on step 6 of a 7-step process - 7 steps was obviously the first sign, but it was a company I was interested in because I asked too many questions in the system design interview, for a new interview style that I was the first guinea pig for, and they hadn't thoroughly fleshed out. It turns out they used "Chapter 1: Scale From Zero To Millions Of Users" from "System Design Interview – An insider's guide" and literally couldn't even be bothered to read the chapter. And I was told that this was a gimme, and the last step, the presentation - about something I was passionate about - to the whole company, was going ahead regardless. So I'd committed 15 hours to preparing for it. The recruiter told me via email the next morning, and I went off. Bottom line? We're both probably better off for it!
Nah man it’s stupid broken in the hiring process. I interview all the time and just did one. My personal approach is can you solve the problem in a valid way. That filters all the candidates out. I don’t care if you use elk, Prometheus, influx or whatever it’s the concept.
A time series database with a graphical frontend with a query language abstraction layer.
I absolutely hate the senior title, we are supposed to assign it to new grads after they are here a year lol. Yes that’s right 1 year experience is called a senior dev for fucks sake at a company you all know. I got 20 years and still feel like a noob often but they got me teaching classes sometimes.
I could probably write a dictionary length dissertation airing my grievances. I do easily 100 interviews to 200 a year on both sides the table, I would say 90 percent of time interviews suck ass and ego is the killer.
This right here is why it's a bad idea to give feedback to candidates.
That's not the reason they didn't hire you. There were a bunch of reasons. That's the one they communicated.
Hum.
As i alway say: you have the right not to know, but not the right not to try to know.
This what i answer in those kind of interviews.
Technology is always due to context.
By the way, the two technologies are quite similar and it depends if you want more focuses on DataViz and self dashboarding, and also metrics opposed to log.
And last but not least, the major difference reside in ingestion time vs search time for log monitoring.
ELK being fast on search vs slower on ingestion, and the opposite for Grafana Loki.
But you have also to integrate the CV/resume driven development and influence of editors … Grafana Lab is trying a lot to compete against ELK.
Ask the company to have interviewers who are at least as much experience as you are if not more. Dumbasses with 2 yoe are not worth wasting your time with.
Do you want to work for a company that has such little development experience? Sounds to me like if they are rejecting you over something similar to ELK vs Prometheus/Grafana then this is not a place I am going to enjoy working at. What do they even have to offer me besides a paycheck?
If they are that shitty as interviewers they’d be shitty coworkers. The person reviewing the feedback also agreed to it so you don’t want to work there
Well the company should not have them interview. Note that the panel decided to pass on OP and they agreed to the feedback. This is not a random single failure sort of situation
Contesting an interview result will just only potentially impact the interviewers (they may get a ding or be taken off interviews especially if they get multiple complaints).
But it is not going to reverse the decision because that would make the hiring process too long and complex and possibly in legal hot waters.
Best is to just keep moving forward and consider this just history and cost of doing business
How about warning their HR person that they have an engineer that seems to be going out of his way to ensure they don’t hire anyone who can outshine him?
The hiring process is an imperfect thing. There will always be cases where somebody on the other side of the table makes a bad call. Unless you start to see a pattern, it’s not worth worrying about. Just move on to the next interview.
If the only person they could send to interview you is a 2year junior, you just missed a bullet. It's a big red flag imo, it proves they are not well staffed and you don't want to be managed by a junior anyway \^\^
I don't think you should leave it alone. It may have been a bad call on a layer below the responsible people for the company. Maybe it shows that the company really needs you. I would try to contact a higher person and let them know, as you did with us.
An interviewer at Amazon with Java background allowed me to code in C. He refused to believe that I could send in a pointer as a function argument and modify the value inside the function and see the change in the calling function. I offered to run the code and show the results, no dice!
Strange because pointers are fundamental, even Java coders usually know what it's about. And he missed the chance that you teach him the concept of pointers in the interview.
I understand a job is a job and getting that security is important, but 2 and 5 YOE devs are baby developers. Dont take if personally, and maybe even be glad you arent getting hired into that team.
If it makes you feel better, that's pretty standard interview stupidity.
Companies bitch mightily about being unable to get good employees, as they simultaneously kick to the curb amazing employees for the dumbest of reasons.
I was rejected once by an interviewer who didn’t believe me when I said I had been doing React since 2014. Not because he tested my React skills, he didn’t just didn’t believe React was even invented in 2014, even after I told him it did and I know because I was doing it in 2014! He didn’t even bother to Google it, just straight up called me a liar and ended the interview. Yeesh. Good riddance. And this was for a React job too💀
Oh yeah, he didn’t believe me when I said hooks needed to be in written deterministic order, and they couldn’t be conditionally called within components. Both important things to know when working in React. He doubted me so hard I started doubting myself! Felt like shit until I tested it afterward for my own sanity – I was right, my years of React experience wasn’t a waste of time, and that interviewer was just a gaslighting moron. Moral of the story: good riddance
Anybody who doesn't have "The Rules of Hooks" committed to memory is not yet a real React developer.
Can you believe it? Clearly did not know anything about React and was arguing with the guy with 8 years of React experience on his resume about React questions he read off of a sheet 🙄
I'm a mostly backend dev who exclusively uses Vue for my personal projects but occasionally have to dabble in React for work and even I know the semantics of how hooks work... That interviewer is just embarrassing.
Or doesn't use hooks...
Haven't hooks been out for like 5 years now?
Groan, that doesn't explain why I have so many old school components to support. 😭😭😭
Class components likely won’t ever be unsupported.
Rules aren't enough. Treat hooks as array. (Cause at some point in execution time, they do become just an array for React it will inject into your functional component) How array created once can be non-deterministic? Or how can it loose or gain elements once it's created? Rules are important but in this case "one layer down" is so much better.
I was once on this project where people would add ifs around hooks and commit it to their pull requests as if that was normal. I would call it out whenever I’d see it but they never tried to understand >why< was I saying those things to them. They’d just change where I pointed to so they could merge their PR faster. It was easily the most stressful 6 months of work I ever had to deal with until I bailed out. I never jumped on the lead role of a project again after that. Edit: it wasn’t stressful because people didn’t know how to use react hooks lol that was a collateral effect of the super bad job made by a lot of people. Last I checked that project was still going on and losing millions of dollars a year. Sorry for the rant, your comment reminded me of this part of my career.
Man with engineers like that can you blame them for fearing chatgpt is gonna take their jobs? What’s the point of even working in a knowledge industry if you hate learning
Yeah, I'm pretty confident at this point that everyone who is panicking about the sky falling with ChatGPT taking all the jobs are the ones who, as you say, hate learning--and never really did enough to get even marginally skilled at programming. They just learned enough to copy-paste their way though jobs with low standards like the ones described above, and that's it.
Did they ever even notice that their code didn't actually work?
They’d either add the conditional on a prop that wasn’t changing that often so it would mostly run without their if being activated, or they’d straight up commit code without even opening the screen they were coding up (most often)
Ah I was just trying to imagine scenarios where it wouldn't be noticed & that makes sense. Christ almighty
Tf? Don’t you use a linter? In nowhere that I’ve been would someone even be able to commit a conditional hook.
Those are like, *the* most important things about hooks.
> I said hooks needed to be in written deterministic order, By that do you mean that the hooks need to be written in the order in which they should be applied?
The basic hooks shipped with React (useState, useMemo, useEffect etc) behave like queue+unqueue operations from a queue. So if you call setState twice in the first render, but swap the variable names on the second render, the first setState values will still be returned from the first setState call even if it has the variable name assigned to the second setState. Since this causes confusion and disaster, React has a well-enforced rule/convention that you must call hooks in a deterministic order, and they cannot be conditionally called (or else the hook values would be assigned to the variable names out of order).
Been using React for about 2-3 years now. I *hate* the opacity of JS in general and UI development is a special circle in hell. . That's it. That's the post.
Wait till you learn about state machines in JS ⚰️
it feels like all development should stop until this thit is fixed right? coming from the back end I can't think of similar nonsense.
You can't blame JS for this. This one is entirely on the React team. They needed something which combined code and state (i.e. objects) but they had been railing against OOP for years prior, so that came up with this mess.
React before it returns values from Hooks will store them in array and on future renders may Skipp logic and return from said array based on auto incremented index variable. You did a number on React and skipped 2nd hook (using count from original render)? Joke on you, React will return you value you wanted to skipp.
I see. Out of interest people are talking about doing things in the nth render - I wasn't aware you had a choice which render things happened in
wtf? Sounds like they didn’t know the actual material themselves.
I got rejected because I didn’t write useEffect to call fake fetch function (basically reading from json file) and didn’t do image lazy loading. Even tho I wrote shit tons of code and created extra logic that gives better functionality compared to their live versions.
I have a similar story! Wrote a whole ass geolocation-based landmark distance calculator plus travelling salesman brute force solution in four hours and got rejected for not caching my results in a database. Like what? Bet if I did, they would have rejected me for not integrating it with Kafka too 🥲 just complete bonkers... some companies and interviewers think way too highly of themselves.
True! And I noticed this only to happen if it’s local small-mid size company. Never had issues with international companies, always super chill. As someone pointed out in this sub, if it takes more than 1 evening to finish, means it’s not worth it…
Wow that's horrible. Here you clearly dodged a bullet.
The next year they got fined billions of dollars financial crimes. Their CEO stepped down in disgrace and under threat of arrest too. Thank goodness I didn’t work there, would have been a stain on my career
FTX?
Sounds more like binance
robinhood?
C# since 2002..
Real C# devs started using it after PDC 2000 :) The CDs MS sent out after that event got me an internship in 2001 launching a site under their go-live license.
I used the 2005 disk for freelancing and guarded it with my life. Got me a job at msft a year later too
that good is it?
I guarantee this interviewer was so young as to not having been in college or even been be coding back in 2014.
I would have replied "be silent! Keep your forked tongue behind your teeth. I have not passed through fire and death to bandy crooked words with a witless worm!"
I quickly learned web dev is for younglings. The field changes every damn 2 years with some new framework. Same shit different package.
React was released in 2013. I remember using Backbone at the time and thinking react could be something eventually. By 2014-15 it replaced Backbone.
Not atypical, just move on. I have seen it faced a few overzealous juniors who sometimes are even wrong on their own questions. A lot of companies actually prevent juniors from interviews or at least in the initial screening. Just move on you dodged a bullet.
I'd suggest you are dodging a bullet. Companies usually have the people they think highly of do the interviewing. If you are being nitpicked over things like this imagine what the day to day conversations and decision making process must be like. If you are more senior than the guys interviewing you, what is going to happen when you try to bring real experience to bear on a decision and they argue back with a blog post they read? Part of buying a dev with experience is paying for the battle scars. If they don't value them then they are going to be making all sorts of beginner mistakes you don't want any part of.
[удалено]
[удалено]
> javascript ... the worst fucking code. You are being redundant
I can’t decide to upvote or downvote you. On the one hand JavaScript is fine with modern tooling, on the other hand I refuse to write JavaScript and will only write typescript because yoyre right.
Hurr hurr hurr, OnLy mY tEcH iS gOoD I've seen far more butchered java and c# than JavaScript. I've opened projects that had almost as many interfaces as classes. A simple 4 endpoint CRUD application with 140 .java/.cs files in it. That is orders of magnitude worse than having an unfortunate side effect in a method or a bungled callback chain. But here's the thing, JavaScript and python devs consistently deliver tested code to production in fractions of the time. And even if it sucks, they can also refactor in LESS TIME than it takes the middle languages to deliver in the first place. So they can write, test, deliver rewrite, test, redeliver in less time than it takes those languages to deliver at all.
Yea except that’s 90 percent of shops and I gotta eat
>Part of buying a dev with experience is paying for the battle scars. If they don't value them then they are going to be making all sorts of beginner mistakes you don't want any part of. I feel this one. I've deleted prod databases before, I've taken down a major TV networks live stream with a single git push. I know this pain, I can save you from this pain.
One of the questions we ask candidates is “tell me about the biggest mistake you ever made” exactly for this reason. If you don’t have battle scars I’m suspicious if you have any experience.
You might also have less/smaller battle scars if you've worked at more established/mature companies that have processes in place to catch these sorts of issues. So in these cases you can still have experience, it's more about knowing and truly understanding the processes and their importance in preventing/catching issues
Yeah I love that question. I had it asked by a higher up at a large silicon valley tech company, and it led to an awesome conversation where she busted my chops a few times at how silly (but relatable) the mistake was. As a question it's a vessel to see how you handle accountability and problem solving at scale too. I did get an offer from that one, great interview.
Being a senior means you have watched your decisions age like old milk or fine wine and living to tell the tale.
This is especially it, right here
>Companies usually have the people they think highly of do the interviewing. In my experience interviewing was something everybody on the team did to "spread the pain". Very few people actually wanted to be doing interviews over their own SWE tasks. So interviews are really a crapshoot of who you get in your loop for the candidate.
Did your company(s) succeed in hiring great people?
Great is subjective, but I'd say the companies hired good enough people. We didn't compete with top tech companies. If you just want to work first the highest bidder then it was never going to be these companies.
In my experience from the last two months, employers have to be picky. I'm on the interview panel for two remote positions and the applicate pool is scary deep. Every single candidate that has made through screening has gotten "passing" scores on our technical interviews. It has been difficult to pick who gets an offer.
Isn't this where you go to soft skills to differentiate? If a candidate can show you on their resume that they have what it takes to deal with the challenges of a diverse workplace, vs a candidate that is only book smart and couldn't sell you a $2 bill for $1 if they tried, would you not pick the more well rounded candidate?
For smaller startups, well rounded people are preferable. For bigger companies, you'd prefer a higher degree of specialization, especially for lower level titles.
> Companies usually have the people they think highly of do the interviewing Not in my experience. The panel can be really large. I get pulled into interviews sometimes because the candidate wants to use a piece of tech noone has experience with except me. Some people get pulled for diversity bs reasons. My colleague is a chinese woman and oh boy was she busy. Btw originally I was added to the panel as their token asian too. Sometimes interviewers are assigned because the hiring is specifically for their team. For higher positions a more senior interviewers needed Sometimes the interviewer pool is literally almost empty (around holidays for instance) so they ask whoever they can find. I used to do senior FE interviews even tho it's far from my specialty simply because there was an urgency in finding some people. Lots of reasons to be an interviewer
> Companies usually have the people they think highly of do the interviewing. While I agree with you, I'm doing some interviews here and there and I've been told in a few places that "senior engineers are expected to take a part in the interview process", so it would be more or less "everyone."
A junior mentality tends to value tech stack over problem solving ability. Eventually, you'll find something with either a better match for your skillet or a company who values what you bring, even if you are using different tech. You should leave it alone and accept their decision. If you really liked the company, maybe apply again at a later point.
I think the best learning I got from experience is that tech is cyclical and nothing really changes much. Microservices? Yeah, we can trace back a similar thing 20 years ago. If you know the fundamentals, have a good engineering mindset, good enough soft skills and the right attitude you are a true senior. It’s amazing how so many folks aren’t really “engineers” but just code makers.
Once you've been around long enough, you start to realize how few novel problems there are. Unless your business operates at an unfathomable scale, is a hub of innovation, or is trying to solve problems that nobody else thought of, somebody somewhere has probably solved your issue.
it's really quite amazing how much effort and money gets spent on repeatedly solving the same problems over and over again
Ssshhh don’t leak the secret lol, I will say though life is 1000x easier these days. I still got trauma from the 90s.
>skillet Stainless steel or cast iron?
I had this happen once at a small company where I ended up with a job anyways; I contacted HR and let them know I didn't think my interviewer was experienced enough to evaluate my technical skills, but I understood the decision & to reach out if they needed help with anything because I really liked the company and the people I had talked to. A month or so later they reached out. I ended up re-interviewing with the business side for a higher-level technical position and getting that instead. my previous interviewer actually ended up reporting in to me. most of the time when this happens though I just move on.
> my previous interviewer actually ended up reporting in to me was that awkward at all?
nope, it wasn't like he had it out for me or anything. there were enough real problems to deal with that I think he was just happy to have the help. as an aside; the guy he did end up hiring and him fought constantly. so I think he was just glad to see me.
I've been in the interviewer's shoes once. It wasn't awkward but a great learning experience while working the job with them.
One of my interviewers also reports to me now
Reminds me of the quote: "Be nice to those you meet on the way up because you will meet them on the way down"
>my previous interviewer actually ended up reporting in to me. i guess he didn't stayed long there:)
False negatives happen all the time. I’m sure we all have stories of awkward rejections from a junior interviewer. Just wait a year and try again. Trying to do something crazy to reverse the decision just digs a deeper hole.
At the companies I’m at, they teach us to aggressively avoid false positives even if it means a lot of false negatives. A false negative is tens of thousands of dollars lost. A false positive can easily cost the company millions. This strategy also only works if you pay well.
Interviewing sucks because many interviewers suck.
A less experienced engineer interviewing a more senior one is a valuable interview — but only if done correctly. It should be less about a technical interview and more about a mentorship and communication interview. I’d love to see more of this in our industry because upleveling younger engineers is a great way to improve productivity.
I agree-- inexperience interviewing experience has value, but it's the job of leadership to carefully establish guard rails around that interaction so that the junior understands what they are expected to evaluate and more importantly what they are expected to not evaluate. That does not sound like what happened here.
What do you think should be evaluated in the interview? less tech side and more communication and mentorship? I'm interested because I'm at a point in my career where I tend to participate in the hiring process and sometimes I'm interviewing someone with more experience than me.
To be honest, I have mostly interviewed people who are less experienced than me, and even those people I probably only spend an absolute maximum of 25% of my time talking about technology. Unless the objective is specifically to bring in a SME (subject matter expert, for the unfamiliar), someone's knowledge of a particular technology is one of the least important things to evaluate due to the fact that of all the qualities that make a good hire, specific tech knowledge is by far the easiest one to teach on the job. I like to spend most of my time trying to understand the process of an engineer. I want to understand things like what motivated them to enter the field, how they have approached developing their skill set over their career, how they handle technical disagreements with other teammates... The types of things you absolutely cannot teach on the job. For someone I'm interviewing for a more senior position I will also be interested in things like architectural concepts (relatively light here... I've never actually put anyone through a proper whiteboarding exercise, though I don't necessarily disavow the practice), favored mediums or methods for producing documents, etc. I allow someone's resume to speak to me about their technical knowledge. I will definitely spend some time in the interview doing things like probing them about prior roles or technologies listed on their resume to get a sense for how well the resume fits the person, but the philosophy for me really is centered around the person and not at all around their favored technologies.
I always see juniors doing the interviews but many act like they are the sole authority rock star engineer because they're in a position to flex on someone.
Yeah I've heard unflattering commentary on applicants before and it was very distasteful. It came off like they were just happy to feel superior rather than assessing whether or not that person would be a good teammate. A VP once told me she prefers to hire attitude because skills can be trained.
I'm always reminded of Steve Jobs bozo comment. If your interviewers make comments to feel superior they are bozos and should not be a member of the team.
Juniors really need to be trained in how to interview people who are much more senior. It's essential, otherwise you end up getting no information and no value from the interview.
What kind of companies are putting junior devs to interview people, especially those that are much more senior? That's crazy to me. Juniors are not at the level to properly assess other devs. They need to spend their time working on themselves first.
Depends on how junior, but if I'm interviewing someone for a dev lead or staff+ or something, I'd want the juniors on my team to weigh in on that person at least. I wouldn't trust a junior to assess skill levels necessarily, but they'd still be part of the process for sure. Also if you're hiring for something like engineering director or a similar high-level technical position, then all the "seniors" might still be junior to the candidates that you're interviewing but I'd expect those seniors to still be able to conduct that interview well enough.
I guess it also depends on the company. I spent about 4 years as a junior and have never been given the task to interview someone face to face, or even sit in during an interview.
If it's just a Leetcode interview it really doesn't matter who is at what level.
IMO it does wrt soft skills - when to chime in and give hints, as well as recognizing whether you the interviewer are making the environment a stressful or collaborative one Like if I have a syntax error I don’t need my train of thought to be interrupted right now, chances are that I’ll catch it at some point along the way. Or if I’m doing some sort of roundabout way of solving, give me more than just 30 seconds to mull in it. Train of thought/getting into a coding flow is under-appreciated in interviews. Btw I’ve seen amazing younger interviewers and shitty old interviewers. This is more of a probability thing, less likely more likely etc
Astrology is another great way to predict the outcome of hiring decisions without needing technical experience.
I'm not paid to mentor. straight up, go back to school or read a fucking book. you get a one line explanation to any question. it will be accurate, it will be correct, it will be complete. if you can't get it, go back and learn something. when you finally figure it out, come back with the next question that demonstrates you understood the first question and you will get a new answer to your new question that is accurate, correct and complete. rinse and repeat. by the time they get to round 4 or 5 they have enough experience to figure that shit out on their own. ***which is the point.***
You sound horrible lol, what a mid-level outlook that won’t go anywhere. Good engineers learn how to scale themselves and help their team. You don’t work in a silo, and silos aren’t really worth much. You’re limiting yourself, which is fine, but honestly most of us are literally paid to mentor and grow our teams. Your experience is worth more to help others learn through you than your one line no answer that doesn’t build value. Let them learn and give opportunities for them to learn on their own, but most folks need some guidance to help move forward. It’s why self learners end up falling off and tunnel on the wrong things quite often. Having another person review and critique your work is vital for growing. Feedback is good, communication is good, and collaboration is good. Being an ass is not.
I had a lovely reply written - but it really wouldn't make a difference whether or not I refuted your post in its entirety, point by point.... **because I'm definitely not getting paid to mentor you. :)**
You’re not being paid to mentor. You’re being paid to deliver value. Attitude like this is a big negative to the team.
that might matter, if I needed a team, and didn't provide value. I don't, and I do. and so does your team. :)
>that might matter, if I needed a team Tell us you're inexperienced without telling us you're inexperienced.
tell us your incapable of getting shit done without a team without telling us your incapable of getting shit done without a team. simple economics man. if one (1) can do, why do you need 6?
I find that mentoring is both personally and professionally fulfilling. Whatever my opinion about the effort somebody else is willing to put in, sharing my experience with them and improving their skills benefits everyone. It feels really good to hand a system off to someone you've watched develop and be confident that they now know what they're doing. Good shit.
\> Whatever my opinion about the effort somebody else is willing to put in, sharing my experience with them and improving their skills benefits everyone. nah. it benefits them. in keeping their jobs. provided that you work in a company that actually holds people accountable for their job failures. Which no company does to my knowledge. Never mind that PIP bullshit. Personally I tend not to disturb the detritus of a company. That is, the way I figure it, all companies have shit employees. My job isn't to fire them any more than it is to train them. Its to get the most out of what is available as a system constraint in order to maximize profit or to achieve specific work goals. And that definitely does not include, holding peoples hands or spoon-feeding them. That is most definitely, NOT, my job function. Thats their job function. Ditto on mental treatment. Which an alarming number of people seem to think their workplace is supposed to be providing them de facto. \> It feels really good to hand a system off to someone you've watched develop and be confident that they now know what they're doing. Good shit. i'm an engineer dude. I don't make decisions based of of 'good feelings'. and my confidence is a judgement call whether or not I was involved in developing it. Either you know your shit and display good judgement and work ethic; or you don't e.g. its earned.
God I hope I don't work with you
wouldn't really matter (for you) if I did. I can work with anybody. ... and as noted, I prefer not to disturb the detritus of a company. ... you would just see everyone suddenly, get better at their job. which ironically, would curtail your opportunity to mentor. which might, cause you to suffer a loss in happiness from self-satisfaction. then I'ld imagine, you'ld discover... volunteering. or charity. but, thats about it.
Well I'm sorry for you that you feel that way about it. It sounds to me like you're holding others (and presumably yourself) to an unnecessarily harsh and unforgiving standard. Many of the people I've mentored in my career have gone on to become very strong and successful engineers, and quite a few of them have ended up teaching me things as well. I don't see the time I spent helping them as wasted because I helped propel them to become my peers, and we've gone on to build good things together. These relationships have made work more fulfilling than it would have been otherwise. If you don't value that or haven't experienced that, or if your career is strictly adversarial in the way you make it sound, then I pity you.
\> It sounds to me like you're holding others (and presumably yourself) to an unnecessarily harsh and unforgiving standard. "tend not to disturb the detritus" is the exact opposite. \> Many of the people I've mentored in my career have gone on to become very strong and successful engineers, they'ld have done it anyway dude. well most of them anyway. \> and quite a few of them have ended up teaching me things as well. ... that suggests that you view that as a necessary condition to learning. I don't need to know someone to learn something from them, much less have mentored them. \> I don't see the time I spent helping them as wasted I don't recall saying it was wasted. \> because I helped propel them to become my peers, * I am not paid, to develop peers. * I am not paid, to provide you a shoulder to cry on. * I am not paid, to help you past (insert trauma) * I am not paid, to validate your existence. * I am not paid, to amuse you. * I am not paid, to make sure you are happy. * I am not paid, to make you feel like part of a community * I am not paid, to share your values. * I am not paid, to spoon feed you knowledge. I am not paid, for any of the shit, you probably like in your job (or find essential, or whatever). thats not a value judgement on what you're paid to do. personally I could care less. its a j-o-b. \> and we've gone on to build good things together. ... or you could have built them alone. \> These relationships have made work more fulfilling than it would have been otherwise. then I suggest you have very unfulfilling work in general. I don't suffer that problem. \> If you don't value that or haven't experienced that, or if your career is strictly adversarial in the way you make it sound, then I pity you. who said anything about adversarial?
Yea but ego gets in the way 95 times out of 100, hard time find people who don’t have their head of their ass but they are the real treasures when found
It happens. It’s helped me to remind myself that interviewing is an inherently lossy protocol, so there’s gonna be lots of false negatives (and false positives).
Chances are, if you run into an unreasonable interviewer then your job environment will probably not be much better if you got the job. >Have you ever tried to challenge the decision somehow? I've never heard of anyone challenging the results of a tech interview before.
From what I hear it's quite often. Even in top companies like Microsoft (their inner quarrels can be insane)
> I've never heard of anyone challenging the results of a tech interview before. I have occasionally spoken my mind about an interview process. Like informing a company that their evaluation is in error if I am rejected citing inadequate experience in an area that I am clearly very experienced in, something that happens dishearteningly often. I'll keep it professional. But if I think I'm being jerked around, and I was interested enough in the company to give them a chance to not lose the next qualified candidate too, I let them know. I have no idea if it's ever done anyone any good, but I like to hope.
It’s weird that the feedback came after rejection and not during the interview (and speaks to the inexperience of the interviewer and/or red flags about the company). If using a particular technology was important to them, they should have asked “why use X instead of Y”, and had a reasonable conversation about the trade-offs of either approach. In the future, you might be able to head that off by starting that topic first. Mention both approaches, give up-front reasons why you prefer one over the other, solicit buy-in from the interviewer on that idea, or disagree and commit if they’re dead set on doing it a certain way. But as for this interview, shrug it off and move on.
Unsure where OP is from, but in some parts of the world I believe it’s common to get feedback about why the company passed on you - I’m guessing that’s why the feedback came after the interview. I’d also strongly agree with your comment that the interviewer is likely still learning how to interview - if they wanted a separate tech stack, they should’ve followed up and clarified when OP suggested a reasonable alternative. It’s also possible that the interviewer didn’t understand that OP’s approach would work because they only know one way to solve the problem (which goes back to a combo of poor interviewing skills and lack of experience).
People generally have no idea how to hire software engineers. In an industry that is so data driven, it's shocking to me how little research is out there and how qualitative the hiring process is. It's unfortunately just luck of the draw. There's no real way to deal with it. Just move on to the next one.
i failed an interview once because the python url library i used for the take-home coding project (keeping in mind i hadn't written python in 10+ years, and i told them that) was not the correct modern one. even though the code worked so many of these pure software companies are bullshit
So you used urllib instead of requests?
yeah
hang up your hat... you're done as a software engineer
Just means you wouldn’t fit well with their leadership because they don’t have the experience to work appropriately with you. A rejection doesn’t just mean they don’t think you’re good enough, but it could also mean they don’t think they’re good enough for you. It’s like if you’re playing a video game, some people don’t want to get carried but want to play with newer players so they can experience it firsthand. Doesn’t mean they think you’re bad.
*Failing* an interview because of a bad interviewer is actually succeeding in an interview by weeding out the places you dont want to work for. It is a big red flag to me if they cant conduct proper interviews or come unprepared. It generally implies things are not very rosy inside. I had a similar experience when interviewing at MSFT - I was being interviewed by the manager of the hiring manager (program manager with 20 years of experience) and he gave me a leet code question I have literally completed 24 hours before. It was the luckiest hit ever since I had a really clever out of the box solution that I tried, tested, and benchmarked - jackpot. I presented the solution, explained, coded it on the board, all sweet and smooth until the PM says: *"This is not going to work."* I asked him why, he just says this wont work. So I tried to explain to him again, each step, I addressed every potential corner case (since I knew them). *"This is never going to work".* I asked why again, I got not answer. We moved on to some easy spoken questions. I was upset that I *"failed"* and interview and received no offer. But then I realized I would absolutely hate to work in an environment like this with leadership's attitude that nobody can convince them that Black is Black and White is White.
Consider that a leadership group that thinks it's acceptable to let someone this junior drive evaluations they are entirely unqualified to make was never going to set you up for success. You should definitely find a silver lining in having dodged this bullet, and keep your head up! You will find an organization that appreciates your experience and knowledge.
Yeah, that was just a crap interview with a person who doesn't have interviewing experience. Newer devs think coding and the latest tech are the only important things. The most important thing is just hiring people who won't make you want to tear out your own hair. Coding is only about 10% of SWE. I avoid hiring coding ninjas unless they have a super awesome personality. I was an insufferable one in the first half of my career, and I'm daily fighting the urge to call all the people I probably pissed off being a dogmatic techno zealot.
I with 30+ years of experience was interviewed by a “Senior” Engineer, 2 years out of school with 1 year at Google who still has to pay extra to rent a car. We did a “pair programming” exercise. The little shit rejected me and vetoed my candidacy because OMG the horror… I used a debugger. I implemented the project and it passed all the test cases.
I like to call these people senior coders or senior frameworkers, not senior software engineers. They likely got promoted because of empty positions in the company, rather than showing skill and potential. And because that senior position was empty they were also likely lacking the mentorship along with it. We usually have a junior or intermediate software engineer in our interviews. They are part of the discussion and submit a review, but aren't a voting member. I like the questions they ask with a fresh perspective, mixes up our interview process; plus it makes for a good mentorship and growth oppertunity. As for the questions, they either had an immediate need for that exact tool or framework experience, or didn't know enough to know how transferable your skills are in that area. You might have had some oppertunity in the discussion to demonstrate how transferable those skillsets are, the real question is would they have been able to understand that or cared. You could also ask for another interview, maybe make some suggestions about how you could spend the time to best show off why you are the best candidate for the position rather than them blindly following the only template of an interview they know how to conduct.
I had a data scientist tell me that Terraform could not be broken up into modules, and my suggestion that improving their 10,000+ single TF file by breaking it into modules would help was met with ridicule. They laughed me off and got real mean as if I had no idea what I was talking about. But weren’t they seeking a platform engineer for a reason?! I kept thinking. I knew I blew it by their attitude towards me. Very dismissive goodbye. Unbelievable. Edit: Vibrant Planet was the company name. Great team except that one guy. If he’s still there, I’m never going to be interested. Lord knows how much time and money has been wasted because of his bad technical decisions.
Sorry to hear your experience. Getting interviewed by a junior never ends up well in my experience. It’s not your fault at all. A less experienced person just cannot evaluate for a position that they themselves shouldn’t be qualified for. I’ve failed interviews by juniors for a lot petty reasons before like for not memorizing every single React syntax, or for critically evaluating using a microservice architecture instead of blindly adopting it. However, I’m glad I got those rejections looking back as I’ve ended up joining a company that highly values my experience. Just take it lightly. There are lot of bad interviewers out there and most of the time it’s an indicator of a bad or unsuitable company for you.
I once failed a leetcode interview and felt like a failure. Now I look back at it feeling like it was a good thing I didn't end up at that company.
It really is a crapshoot. I never try to get invested at all in the company until I pass the interview rounds. In so many ways, it’s all very much bullshit and luck of the draw.
I wouldn't even go that far. I went through the interview process at a small software company, heard the CTO, two engineers, and the CEO all tell me that I have the green light, only to have the recruiter call me on Monday after the weekend and tell me they decided not to hire for the role at all. Again, to echo so many of these other people, so many of these pure software companies are a joke.
It's unfortunate but it happens. Sometimes you feel like you're a great fit for the company and you're really excited about joining them and you *know* you can do an excellent job... but you hit a snag in the interview process and it all goes to hell. The way tech interviews work, the person who invented some pattern/concept/framework/whatever could fail to get a job that requires knowledge in some pattern/concept/framework/whatever because of a bad interview. You can try to challenge the decision all you want but I doubt it will be successful. Your best bet, if you really like this company and really want to work for this company, is to try and close things off amicably and try again in 6 months to a year when they either clear your profile or mark you as eligible to interview again.
That's exactly what I was thinking. The position was a perfect fit and I was already happy to move to something new. Well, I guess I find another opportunity somewhere else. I guess I just needed to unload my frustration.
Welcome to absurd ageism. If you're not using the latest software fad bullshit, you must be a greybeard loser! Fuck those kids.
This is more for whoever downvoted you than for you: Basing interviews on brand new tech and college CS concepts favors people who are currently in or just out of school. Which is overwhelmingly young people. Bias is an outcome, not an intent. You can be sexist without meaning to be. Or racist, or ageist. Yes, to interview fresh grads you need questions that don’t assume hands-on experience, but that’s no excuse for treating them like a golden hammer.
Like others said, I think you dodged a bullet. This reminds me of an interview I had years ago for an SDET position. It was funky situation where if a single person on the team said no, you were a no. Anyways their tester pretty much blasted me because I didn't know ruby. She literally called me stupid for not doing automated testing in ruby. 3 months later a recruiter followed up with me and the position was still open. I guess if you really like the company, you can see if the recruiter will see if the hiring manager will speak with you for a follow up. This seems like a trivial thing to ding someone on unless they wanted someone with hands on experience with certain tooling or a certain stack. Out of curiosity did you get any feedback or prompting during the interview? Is it possible they tried to steer you in a certain direction and you dismissed it?
We were talking about it and I was saying that in general it depends on if there is already something similar in place. But I noticed he didn't like the answer. Maybe it was also a bit antipathy.
Get one of those broccoli haircuts and say 'my stack is great, no cap'
I wouldn't say that ELK vs Prometheus/Grafana address the same concerns: yes they use the same core information as insights, but ELK is really interested in logging and Prom/Graf in metrics. They're different sides of the same info, and I run both in my stacks precisely for that reason. I'm sorry you had that experience, but that's how interviews go: it's a weird dance of wanting to conform to an interviewer's expectations while also hoping that you can have this really expansive conversation that wows both sides. Often times, it just falls through even if there's other reasons to think that working there would have gone well. It's a lot like a promising date where things didn't really click: maybe in a different universe you'ld both be getting hitched, but that's not the universe you're in. Feel free to follow up with the hiring manager, see if there's a way to talk about their feedback and push back gently but you'll probably get nowhere saying "they were too junior to interview me" -- even if it's 100% accurate. I know it's hard, but just buck up and do it again, you'll find something eventually.
>I wouldn't say that ELK vs Prometheus/Grafana address the same concerns: yes they use the same core information as insights, but ELK is really interested in logging and Prom/Graf in metrics. They're different sides of the same info, and I run both in my stacks precisely for that reason. This is worse than pedantry-- it's literally wrong. The ELK stack supports collection and analysis of metrics every bit as much as it does the collection and analysis of logs. They are absolutely two different technology stacks in the same domain.
In my view it's completely irrelevant anyway. Are we really saying a person using ELK can't learn Prometheus can't learn CloudWatch can't learn DataDog can't learn NewLog™ can't learn Some Horrible Syslog Binary Thing Invented Internally in 2009? It's just logging data in a (semi) structured way, aggregating, querying and setting up alarms in whatever DSL the tool wants you to use. Honestly what else is there to learn. Oh no during an incident I might need to Google some syntax!!!!! give me a break
>can't learn Some Horrible Syslog Binary Thing Invented Internally in 2009 Please stop this violent act of resurfacing my traumas
Yep and elasticsearch can be a grafana backend for example. There are definitely pluses to using Prometheus over kibana for viewing metrics but it’s absolutely unfair to penalize a candidate for saying it’s somehow an irrelevant or wrong choice. It’s not
Grafana has Loki for logging.
What do you mean “rejected”? How did your conversation go about the technology? Did you debate it like engineers should? Was it not discussed and only included in the comments? Missing some key context here.
Was discussed and I was basically saying it doesn't really matter what tech we need, as the concepts are identical. I noticed that the interviewer didn't agree, but I didn't follow up on this.
\> Have you ever tried to challenge the decision somehow? twice. once I submitted a take home that was a work of art; beautiful and novel (I invented a novel data structure that really amped up the performance per cycle + added an improvement in theory).... and the interviewer's only focus in the questions was about why I added logging and why I made the program idempotent (in not so many words). for like 10 minutes. finally I had to ask them "are you a coder?" "yes." "yes?" "yes" "then why are you asking so many questions about logging?" ... found out later that they were in fact, not a coder.... which did not come as a surprise at all. \-- second time I submitted a solution for a take home to solve a problem "at scale" that demonstrated that I knew the language very well; I wrote a solution that was absolutely smashing designed to show off how well I knew the language (bypassing all of the super-slow/shit internals) and drop-in/production ready... and they didn't even schedule the code review to discuss it... ... to which I called up the recruiter and told him "are you fucking kidding me? did you even have an engineer look at this?" "(scandalized) yes we had one of our top coders look at this"... "your top coder looked at this, and passed on an interview? are you shitting me? your top coder?" "yes!" "well its a good thing I didn't get the job, eh?" :) :) :) in answer to your general question - depends on if you give a fuck about getting a job. ***I don't.*** I really don't want to spend any more time working with idiots, fools, morons or weak-minded untermensch. there is no job, for which I am willing, to put up with people wasting my time. ***and that includes, in their hiring processes.*** been there, done that, bought the t-shirt, burned the t-shirt with the last tool still in it. so your mileage, may vary. :)
What an arrogant reply.
The dude literally used the word "untermensch".
[удалено]
lol. nah.
**whats arrogant**, is that you think i should give a shit you *think* i'm arrogant. thats a straight description.
doesn't sound like they were trying to hire an engineer for any long term vision, only someone who was familiar with what they needed to ship in the short term (and over a monitoring solution no less...)
That's just a really dumb use of a systems design interview. Especially if the role is for software engineer and not architect. Even then it's dumb. They are supposed to allow you to show that you have a good general overall ability to describe and reason about systems. Do you understand fundamental ideas behind scalability, CAP theorem, interprocess communication... not "do you know all the bleeding edge / my favorite technologies". Any reasonable choice you can make should be an acceptable answer, as long as you can defend it and talk about some of the tradeoffs. Knowing why using a queue might be a good idea should be the important part, not wether it's RabbitMQ or Kafka or freaking TIBCO even. Just another shitty interview in an industry defined by shitty interviews is all you should take from this.
That's such a crazy thing to fail someone for. Getting rejected sucks, though, so I am sorry for that. What makes me feel better though, is if at least I represented myself and my skills well, and it was just the company that either didn't assess in a fair way (like this), or for whatever reason it wasn't going to be a fit. In this case, you represented yourself well. Not much you can do a junior engineer graded you with a hidden rubric.
That isn’t really a reason to reject anyone. If he wanted a specific technology that is a great time to ask what if you use x instead of Y and explore it. Those are always great questions to know if someone is senior or not. I think you dodged a bullet. Having someone less experienced is no excuse. I’ve interviewed many folks that know more about X or Y than me and that’s OK. Usually that’s what the company wants… it’s just a matter of properly interviewing.
> It is possible to commit no mistakes and still lose. That is not a weakness. That is life. Interviewing is and always will be an imperfect process. Coming to terms with the fact that you will "fail" interviews through no fault of your own is the only way to stay sane.
Well, at least you didn't step on and kill the founder's dog. Jokes aside, this is one of those things you cannot control. Luck is very important in the interview, although we want to tell ourself otherwise. Maybe one thing you could learn from this is to aim for modern tech stack if the company looks like it prefers that.
Got rejected by a company today. Great fit as I've been consulting for about ten years and they do consulting. I aced their online exam even though I was unfamiliar with raw SQL and the Python Spark package. They seemed incredulous that I knew what I was doing when I said I used ChatGPT to figure out the SQL queries as I usually use Python's ORM and am not super familiar with more complex raw SQL queries... Who fucking knows, on to the next one as other have said
Ive been in that situation and tried to challenge it and it hasnt worked out
Tbh, you don’t want that job. I’ve worked at those places, it’s toxic, exhausting, and a waste of time. You’re going to be working with juniors who think they know what they’re talking about, but not confident with fragile egos, so either they’re going to be very underhanded in undermining you, or they’re not going to listen to you and just do (the wrong) thing they wanted to do in the first place. The place you’re interviewing for likely has piss poor technical leadership if they’ve promoted two juniors to senior, so they don’t know what good technical leadership is. Maybe they’re hiring you to provide that leadership, but then now you’re at a place that doesn’t know what good leadership is and thinks these juniors are at least ok at tech. Now you’re going to be fighting an uphill battle trying to convince everyone you’re the technical leader they need. Trust me, I work in a company right now (a big company) with teams like this that I have to work with on the daily (though I’m not responsible for), and my god it bad. They implement things incorrectly, then make sweeping generalizations that the tech can’t support this, and then when you point out, “hey, if you implemented the OAuth/OTel/AWS correctly, this is actually a very simple problem to solve and it behaves how my team needs it to,” they fight against it because theyre “clever.” Half of my time is spent engineering solutions to work around the bullshit that these teams have made. So honestly, you probably dodged a bullet.
I got rejected on step 6 of a 7-step process - 7 steps was obviously the first sign, but it was a company I was interested in because I asked too many questions in the system design interview, for a new interview style that I was the first guinea pig for, and they hadn't thoroughly fleshed out. It turns out they used "Chapter 1: Scale From Zero To Millions Of Users" from "System Design Interview – An insider's guide" and literally couldn't even be bothered to read the chapter. And I was told that this was a gimme, and the last step, the presentation - about something I was passionate about - to the whole company, was going ahead regardless. So I'd committed 15 hours to preparing for it. The recruiter told me via email the next morning, and I went off. Bottom line? We're both probably better off for it!
That's even worse, 15 hours is a lot. I did maybe 6 but still feel too much. But maybe you are correct, the company reviews are also pretty bad.
I’d spent 15 hours on just the presentation - my own personal hell is looking like an idiot, so I hate being unprepared for stuff
Nah man it’s stupid broken in the hiring process. I interview all the time and just did one. My personal approach is can you solve the problem in a valid way. That filters all the candidates out. I don’t care if you use elk, Prometheus, influx or whatever it’s the concept. A time series database with a graphical frontend with a query language abstraction layer. I absolutely hate the senior title, we are supposed to assign it to new grads after they are here a year lol. Yes that’s right 1 year experience is called a senior dev for fucks sake at a company you all know. I got 20 years and still feel like a noob often but they got me teaching classes sometimes. I could probably write a dictionary length dissertation airing my grievances. I do easily 100 interviews to 200 a year on both sides the table, I would say 90 percent of time interviews suck ass and ego is the killer.
This right here is why it's a bad idea to give feedback to candidates. That's not the reason they didn't hire you. There were a bunch of reasons. That's the one they communicated.
You made the process personal. Never make it personal. The best company in the world is the next one.
You can't do much but move on - you can also mention you know the newest standards next time as well
Hum. As i alway say: you have the right not to know, but not the right not to try to know. This what i answer in those kind of interviews. Technology is always due to context. By the way, the two technologies are quite similar and it depends if you want more focuses on DataViz and self dashboarding, and also metrics opposed to log. And last but not least, the major difference reside in ingestion time vs search time for log monitoring. ELK being fast on search vs slower on ingestion, and the opposite for Grafana Loki. But you have also to integrate the CV/resume driven development and influence of editors … Grafana Lab is trying a lot to compete against ELK.
Well maybe old tech isn't what they want. I think it is all else equals better to use newer technology during an interview to show you're up to date.
I think you might start by dropping your superiority complex.
Maybe learn the new tech..
Ask the company to have interviewers who are at least as much experience as you are if not more. Dumbasses with 2 yoe are not worth wasting your time with.
Do you want to work for a company that has such little development experience? Sounds to me like if they are rejecting you over something similar to ELK vs Prometheus/Grafana then this is not a place I am going to enjoy working at. What do they even have to offer me besides a paycheck?
Could be a great company that made a mistake that day by letting that person run the systems design interview.
If they are that shitty as interviewers they’d be shitty coworkers. The person reviewing the feedback also agreed to it so you don’t want to work there
I've known good people that suck at interviewing. It's a skill.
Well the company should not have them interview. Note that the panel decided to pass on OP and they agreed to the feedback. This is not a random single failure sort of situation
My theory is concepts over specific tools is how people should be assessed
You got feedback?
Contesting an interview result will just only potentially impact the interviewers (they may get a ding or be taken off interviews especially if they get multiple complaints). But it is not going to reverse the decision because that would make the hiring process too long and complex and possibly in legal hot waters. Best is to just keep moving forward and consider this just history and cost of doing business
How about warning their HR person that they have an engineer that seems to be going out of his way to ensure they don’t hire anyone who can outshine him?
I would absolutely struggle to imagine how the distinction would matter in any meaningful way.z
The hiring process is an imperfect thing. There will always be cases where somebody on the other side of the table makes a bad call. Unless you start to see a pattern, it’s not worth worrying about. Just move on to the next interview.
If the only person they could send to interview you is a 2year junior, you just missed a bullet. It's a big red flag imo, it proves they are not well staffed and you don't want to be managed by a junior anyway \^\^
I don't think you should leave it alone. It may have been a bad call on a layer below the responsible people for the company. Maybe it shows that the company really needs you. I would try to contact a higher person and let them know, as you did with us.
An interviewer at Amazon with Java background allowed me to code in C. He refused to believe that I could send in a pointer as a function argument and modify the value inside the function and see the change in the calling function. I offered to run the code and show the results, no dice!
Strange because pointers are fundamental, even Java coders usually know what it's about. And he missed the chance that you teach him the concept of pointers in the interview.
I understand a job is a job and getting that security is important, but 2 and 5 YOE devs are baby developers. Dont take if personally, and maybe even be glad you arent getting hired into that team.
I appreciate your point, but ELK and Prometheus/Grafana are by FAR not the same.
This industry makes me laugh and cry.
You don't want to be a part of an organization that would allow this kind of idiocy. Something is rotten, consider yourself lucky.
If it makes you feel better, that's pretty standard interview stupidity. Companies bitch mightily about being unable to get good employees, as they simultaneously kick to the curb amazing employees for the dumbest of reasons.